Tags · gitmachtl/scripts

Light-Mode

New release: Light-Mode, Sub-Handle and Virtual-Handle, Conway-Era

Rendered Release-Notes: https://github.com/gitmachtl/scripts/releases/tag/Light-Mode

## 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: image

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.

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.

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 the offlineTransfer.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 within 03b_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.
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. image

04d_genNodeOpCert.sh now directly ready out the onDisKOpCertCount from the via an own new CBOR-Decode function to provide checking information in Light-Mode.

04e_checkNodeOpCert.sh now ready out the onDiscOpCertCount and the onDiskKESSStart 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: image 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.

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.

08a_genStakingAddrRetireCert.shnow 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 via 01_claimRewards.sh and after that retire the Stake-Address.

08b_deregStakingAddrCert.shnow 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 ...

Please enjoy this huge update and especially the new Light-Mode!!

Dec 17, 2023
5562496
zip
tar.gz
Notes

04-10-2023

New features - Mnemonic wallet, Messages, Metadata

Generating Base/Staking-Keys with/from Mnemonics has been added to the script:

- 03a_genStakingPaymentAddr.sh

So you can now generate a set of Base(Payment)- and Staking-Keys derived from 24-Word Mnemonics. If Mnemonics are provided they are used, otherwise new ones are created. This makes it easier to use keys across the CLI and other wallets like Daedalus, Eternl, Typhoon, ...

---

Sending transaction messages including the option to encrypt the messages (CIP-0083) has been added to the following scripts:

- 03b_regStakingAddrCert.sh
- 05c_regStakepoolCert.sh
- 05d_poolWitness.sh
- 06_regDelegationCert.sh
- 07b_deregStakepoolCert.sh
- 08b_deregStakingAddrCert.sh

---

Attaching transaction metadata as *.json and *.cbor file has been added to the following scripts:

- 03b_regStakingAddrCert.sh
- 05c_regStakepoolCert.sh
- 05d_poolWitness.sh
- 06_regDelegationCert.sh
- 07b_deregStakepoolCert.sh
- 08b_deregStakingAddrCert.sh

So you can now add a comment or an encrypted message or metadata to every transaction that is possible via the StakepoolOperatorScripts.

Oct 4, 2023
97bdc70
zip
tar.gz

04-10-2023(M1+M2)

New features - Mnemonic wallet, Messages, Metadata

Generating Base/Staking-Keys with/from Mnemonics has been added to the script:

- 03a_genStakingPaymentAddr.sh

So you can now generate a set of Base(Payment)- and Staking-Keys derived from 24-Word Mnemonics. If Mnemonics are provided they are used, otherwise new ones are created. This makes it easier to use keys across the CLI and other wallets like Daedalus, Eternl, Typhoon, ...

---

Sending transaction messages including the option to encrypt the messages (CIP-0083) has been added to the following scripts:

- 03b_regStakingAddrCert.sh
- 05c_regStakepoolCert.sh
- 05d_poolWitness.sh
- 06_regDelegationCert.sh
- 07b_deregStakepoolCert.sh
- 08b_deregStakingAddrCert.sh

---

Attaching transaction metadata as *.json and *.cbor file has been added to the following scripts:

- 03b_regStakingAddrCert.sh
- 05c_regStakepoolCert.sh
- 05d_poolWitness.sh
- 06_regDelegationCert.sh
- 07b_deregStakepoolCert.sh
- 08b_deregStakingAddrCert.sh

So you can now add a comment or an encrypted message or metadata to every transaction that is possible via the StakepoolOperatorScripts.

Oct 4, 2023
46040b7
zip
tar.gz
Notes

15-08-2023

Adding new feature - Catalyst VotingPower query

09a_catalystVote.sh / 09a_vatalystVoteF10.sh:

Added a query feature so you can now verify your registered Voting-Power. This works on MainNet and on TestNet, because its a combined API at the moment.

The result is the currently registered total Voting-Power, and all the Delegators/Delegations that are done to that Voting-Key.

Queries can be done by providing the name of the Voting-Key file, by providing a bech encoded Voting-Key or by directly providing a hex encoded Voting-Key like:

- 09a_catalystVoteF10.sh query myvote-test

- 09a_catalystVoteF10.sh query cvote_vk1lca8dhe30dtmuk4yq3c9f20af0jk7ne9vhzhemheczjtpy3dq85qcdzn3e

- 09a_catalystVoteF10.sh query fe3a76df317b57be5aa4047054a9fd4be56f4f2565c57ceef9c0a4b0922d01e8

Aug 15, 2023
c5b959b
zip
tar.gz
Notes

06-05-2023

New Scripts 13a & 13b for the SPO Poll

May 6, 2023
e1a1cb3
zip
tar.gz
Notes

29-04-2023

Update SPO_Pledge_Catalyst_Registration.md

- Outdated version, set a link to the new one

Apr 29, 2023
9cbccae
zip
tar.gz
Notes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

9.1.0-mainnet

9.0.0-mainnet

9.0.0-testnet