SPO Scripts Light-Mode
SPO Scripts 17-12-2023
🔥 New Feature - LIGHT-Mode, running the SPO Scripts without a local node 🔥
This is an exciting new feature in the SPO Scripts. Before we had two operational modes, Online-Mode and Offline-Mode. Now we have an additional one, the Light-Mode.
So whats this Light-Mode? If you switch the scripts into Light-Mode - see below how easy it is to do so - you have the advantage of being online with your machine, but you don't
need a running synced cardano-node. You can switch between Networks Mainnet, PreProd and PreView within seconds.
This comes is handy if you just don't want to install and run a cardano-node, if you don't have the space for the database or if you just don't have the time to wait for a resync.
All transactions are of course generated and signed locally, but the queries and the transmit is done via online APIs like Koios.
How do you switch between Online-, Light- and Offline-Mode?
Thats simple, you just change a single entry in the 00_common.sh, common.inc or $HOME/.common.inc config-file:
workMode="online"
: Scripts are working in Online-Mode aka Full-Mode. A locally running and synced cardano-node is needed.workMode="light"
: Scripts are working in Light-Mode. No cardano-node needed.workMode="offline"
: Scripts are working in isolation and completely offline. No cardano-node needed.
Here is a simple example of a transaction in Light-Mode:
Notice the new mode is indicated via the Mode: online(light)
in the header.
And we can of course check that the amount arrived, this has all been done in Light-Mode. There is no Mainnet Cardano-Node running on that machine 😄
You can do ALL OPERATIONS in Light-Mode now! 💙 Currently supported Chains are Mainnet, PreProd and PreView. You can switch between chains in seconds, and if you put a
different common.inc
file into your folders, you can run them all in parallel too. I also wanna thank Holger from Cardano24, because i am hosting
the Online-Version of the Protocol-Parameters JSON
files on his distributed Server-Platform uptime.live, thank you! The JSON files are updates every 10 mins to make them available in Light-Mode.
If you have an Online/Offline Workflow, you can use the Online machine in Light-Mode, and your Offline machine is still offline of course.
🔥 New Feature - $Sub-Handle & $Virtual-Handle support for $Adahandles 🔥
Complete support for the upcoming Sub-Handle and Virtual-Handle release. All scripts than can use Adahandles for queries and destinations are upgraded to support these additional formats.
As always, the scripts doing a second lookup if the Handles are really on the UTXOs that the APIs report. For the Virtual-Handles the Scripts are doing an extra Koios request to checkout the Inline-Datum
content of the UTXO holding the Virtual-Handle. Virtual-Handles store the destination address within the Inline-Datum.
As you can see this address also holds the Virtual-Handle $virtual@hndl
which points to another address, we can query that too like below.
Also there has been an Update to show all the different types of Adahandles in the Query, like ADA Handle
for the original CIP-25 one, Ada Handle(Own)
for the new CIP68 ones. Ada Handle(Ref)
and Ada Handle(Virt)
for the newest formats.
Improvements to the Online-Mode (aka Full-Mode)
- Critical queries now always do a check if the local node is 100% synced with the chain before continuation.
Improvements to the Offline-Mode
- In Offline-Mode the header on each Script Call now shows your local machine time. This is really important if you are doing things like an OpCert-Update to generate the right KES period.
So now you can do an easy check if the time on your Offline-Machine is correct - NativeAsset Token-Registry Information also in Offline-Mode. To get the UTXO data of an address you wanna use in Offline-Mode you are using the command
./01_workOffline.sh add <walletname>
.
This query - if enabled in the config - now also stores the Token-Registry information about NativeAssets on this address within theofflineTransfer.json
file.
General updates
-
The SPO Scripts are now fully Conway-Era compatible! 🔥
-
01_claimRewards.sh, 01_queryAddress.sh
are now showing if the Stake-Address is delegated to a pool. If so it tries to show additional pool-informations like the Ticker, Description and the current Pool-Status
-
03a_genStakingPaymentAddr.sh
: The generation of the Stake-Address registration certificate has been moved to be done within03b_regStakingAddrCert.sh
. This is a change for conway-era, because we now have to check
the StakeAdress-Registration Deposit-Fee also for the deregistration. The Deposit-Fee can change after a registration has been done, so with conway-era the used amount is now stored within the certificate itself.
If the StakeAddress is already registered on chain, the Script will tell you that and if also delegated to a Pool, it wil try to show you additional informations.
Already registered:
New registration in conway-era:
-
03c_checkStakingAddrOnChain.sh
now also shows the used Deposit-Fee of a registered Stake-Address. If delegated to a pool, it tries to show additional Informations.
-
04d_genNodeOpCert.sh
now directly ready out theonDisKOpCertCount
from the via an own new CBOR-Decode function to provide checking information in Light-Mode. -
04e_checkNodeOpCert.sh
now ready out theonDiscOpCertCount
and theonDiskKESSStart
values for checking in Online- and Light-Mode -
05a_genStakepoolCert.sh
now shows the set poolPledge also in ADA and not only in lovecase. Shows minPoolCost now also in ADA and not only in lovelaces. Shows the poolMargin now in percentage and not as decimal value. -
05c_regStakepoolCert.sh
now shows the set poolPledge also in ADA and not only in lovecase. Shows minPoolCost now also in ADA and not only in lovelaces. Shows the poolMargin now in percentage and not as decimal value.
A pool update/registration/retirement of course now also works in Light-Mode:
If there are external Witnesses (MultiOwnerPool) and the registration is done with an attached Metadata-JSON/CBOR, that information is now also stored to be represented in the external witness file. -
05e_checkPoolOnChain.sh
now gives you detailed informations about the current pool-status. You can of course also use a pool-id in bech or hex to query this information with this script.
Registered:
Retired:
Was never registered on the chain:
-
06_regDelegationCert.sh
now checks the pool status you wanna send the delegation before continue with the transaction. If a pool is retired or was not registered on the chain(yet), such a transaction would let to an error.
This precheck avoids this issue. In addition there is now a check that the Stake-Address is already registered on chain. Also, it now shows information about a current delegation and the planned delegation. The script directly reads out the delegation destination pool-id from the delegation certificate to show
this information.
Pool to delegate to not registered on chain(yet):
Showing the old delegation and the new delegation:
-
08a_genStakingAddrRetireCert.sh
now checks if the Stake-Address is even registered before generating the Retirement-Certificate. Also now important, it checks the Deposit-Fee that was used to register the Stake-Address
in first place. Because we need to use the exact Fee again to retire the Stake-Address. There is now also a check if the Stake-Address you wanna retire still holds rewards. If the Stake-Address still hold rewards, it will
show you the amount and refuse to generate a Retirement certificate. In that case please first claim all your rewards via01_claimRewards.sh
and after that retire the Stake-Address.
Stake-Address not registered, so no need to deregister it:
Stake-Address still holds rewards, we cannot retire it now:
Ok, Stake-Address was registered with a Deposit-Fee of 2000000 lovelaces, generate the Retirement-Certificate:
-
08b_deregStakingAddrCert.sh
now again checks the current Stake-Address status on chain and a possible active delegation. Just to make sure you're retireing the right Stake-Address. It also now directly reads out the used
Stake-Address Deposit-Fee to calculate the balance return correctly.
-
Many additional updates here and there for better request handling via curl, better error checks, etc ...