New Calidus Pool-Key for SPOs and Services interacting with Pools

There is a new method now to authenticate/login/vote/sign as a PoolOperator

:point_right: The Calidus Pool-Key

What is this Calidus Pool-Key ?

The Calidus Pool-Key is used to identify/authorize pool ownership for public/private services without the need to go thru a VRF-Secret-Key signing process. This was only possible on the CLI and SPOs don’t like to touch there secret keys that often.

The Calidus Pool-Key can be used on the cli AND with LightWallets directly in the Browser for Identification/Login/Authorization/etc.

If you wanna update to a new Calidus Key, just generate a new one and register it for the pool.

You only need to sign the registration metadata once with your Stakepool Cold-Key, after that you can use the Calidus Key for various services on a daily base. No need to use the Stakepool Cold-Key or the VRF Secret-Key anymore.

The signing/verification is done on the CIP8/30 messageSign protocol and is therefore also compatible with Stakepool Cold Keys on the Hardware-Wallet.

Its a standard ed25519 signing/verification in the end, so there are plenty of libs available for the integration in own services/dApps.

Services/Tools already available:

Services/Tools planning to use it:

  • CN-Tools implementation already done in alpha release
  • Sentinel Indexer update to support it within next weeks
  • Explorers like Cardanoscan, AdaStat and Cexplorer are looking into it
  • APIs like Blockfrost are looking into it
  • Projects like Atrium Labs are looking into it
  • Japan SPO Guild will use it in there Discord Bot
  • more will be announced soon …

Possible usecases:

  • authenticate yourself as an SPO of a specific pool
  • login on a website that provides services for SPOs
  • participate on a voting for SPOs
  • use the Calidus-Key to sign your Governance-Action rational
  • generate vouchers for delegators and other users that can be redeemed at another service
  • and much more …

How is the registration metadata constructed

Here is a simplified schema on how the registration metadata is contructed. It conains a versionInfo, a payloadPart and a witnessPart.

5 Likes

How can i participate already?

The tooling is already there, you can use cardano-signer to generate the needed registration-metadata.json file.

The registration on MainNet is live, but please if you wanna do some testing, help us by registering your Calidus Pool-Key on Preview-Testnet for your Preview-Stakepool too!

SPOs on the Preview-Testnet, please help us to test out this new key and submit your registration metadata for your PreView pool on the tesnet. :folded_hands:

You only need two commands to generate the registration metadata json file:

Generate your new Calidus Key-Pair

cardano-signer keygen --path calidus \
  --out-skey my.calidus.skey \
  --out-vkey my.calidus.vkey \
  --json-extended

Remember the given Mnemonics in the JSON for later import in a LightWallet of your choice.

Generate the registration metadata signed by your pool key

cardano-signer sign --cip88 \
  --calidus-public-key my.calidus.vkey \
  --secret-key my.pool.skey \
  --json \
  --out-file calidus-registration-metadata.json

You can than use this metadata.json file in a transaction on the cli or simply copy it into eternl-wallet as a custom metadata and submit it in a transaction on the preview testnet.

More details on the generation can be found here.

Registration on the Preview-Testnet can already be checked via the koios api:

curl -s "https://preview.koios.rest/api/v1/pool_calidus_keys"

you can use filtering like

curl -s "https://preview.koios.rest/api/v1/pool_calidus_keys?pool_status=eq.registered"

or

curl -s "https://preview.koios.rest/api/v1/pool_calidus_keys?pool_id_bech32=eq.pool1w83ux7vrwafrsuz044knxl9xxtr38q5jj2l3p28fl3g26faqqwg"

Feel free to ask questions in this thread.

Thank you very much!

Best regards, Martin

9 Likes

It would be awesome to have a way to generate a new pool key which can be protected and managed by a hardware wallet. I currently use an air-gapped raspberry pi to manage the use of my pool cold key which is a right pain in the arse. It is much more secure and convenient to use a hardware wallet such as Keystone to protect Cardano private keys while using them.

However, it is my understanding that for a hardware wallet to manage the key it needs to be a root extended private key generated from a seed phrase + passphrase and this method seems to be generating another single key just like my existing pool cold key.

Is there some way that this new key can be loaded into a hardware wallet for protection during use?

2 Likes

hey @Terminada ,

this is a bit offtopic. but in short, no you cannot go the other way around and “injecting” an existing pool key generated on the cli back into a hardware wallet.

i made tools to get out a “cli” pool key back from a hardware wallet via the correct derivation path, but that would only be needed for a desaster recovery or so.

so in short, no, not possible. for that you would need to generate new pool keys on the hardware wallet (which is supported on ledger and keystone), and register a new pool.

there are thoughts to maybe somehow change out keys for a pool, but this might take a long time to get into the ledger and not really a high priority.

but please open up a new thread for this.

best regards, martin

3 Likes

I guess the point is that if we are going to create these new “calidus” pool keys then it would be better to create an extended private key from seed phrase + passphrase and derive the 1852H/1815H/0H/0/0 key from that for use as the “calidus” pool key. Then that key can be protected by a hardware wallet while being used.

These new keys are hot/warm keys and replaceable. They provide an option for SPOs to do stuff like authentication, login, voting, signing on services.

You can of course derive it from the standard payment path on a HW-Wallet or on the CLI.

The command above

cardano-signer keygen --path calidus\
  --out-skey my.calidus.skey \
  --out-vkey my.calidus.vkey \
  --json-extended
{
  "workMode": "keygen",
  "derivationPath": "1852H/1815H/0H/0/0",
  "derivationType": "icarus",
  "mnemonics": "ill vivid tiny someone address stuff busy provide venture state luxury regular include bounce lawn crash pattern cricket mandate income bridge artefact allow world",
...

outputs a json, where you can also find the used mnemonics to import them into a LightWallet like eternl for simple online use in the browser. You can of course keep it on a HW-Wallet.

2 Likes

I hadn’t realised that the --json-extended output had all that in it. That is fantastic. I wish the original tutorials on generating pool cold keys had done something similar.

2 Likes

Isn’t it recommended yet to generate one from mainnet?

If I understand correctly, the Calidus key is just a normal key like a payment key? So you could also one on a HW wallet because you just need to include the pub key and sign with cold key?

Is there a suggested specific derivation path for it like we have for other key types, so an already existed wallet can be used for it (instead of the first payment address)?

Are there already services that use this or are planning to?

You can already send a registration on mainnet too, we are seeing first pools.

Yes its a standard ed25519 key. It can be a pure CLI key, a “LightWallet” key with mnemonics or on a Hardware Wallet. Most likely you want it as a CLI key generated from mnemonics (like the example command above) and also imported in a Lightwallet. So you can use it on the CLI and also in the browser.

Currently we set it to be the standard payment path, to make it easy also for LightWallets.
If we see there is a need to change the path in the future, we can do so easily.

Just remember, this is not ment to be a super secure cold key. Its a warm/hot key to be used on a daily base with various upcoming services. If you feel you need a new one, just generate a new one and register it.

I know that Blockfrost, Cardanoscan, Cexplorer, Adastat is also looking into it.

Markus is working on a very very cool thing for SPOs, but i don’t wanna spoil it here. :slight_smile:

5 Likes

For those with technical feedback: the machinery of this scheme has now been confirmed as candidate CIP-0151 :party_popper: …

2 Likes

And we have a logo now :fire:

Reach out for an Icon-Only logo / svg / transparent …

2 Likes

What about the T-shirt? :star_struck:

that one? :rolling_on_the_floor_laughing:

lets see how fast the adoption goes, so maybe we have something for a giveaway on the next cardano summit

1 Like

UPDATE: Added the Calidus ID generation into the flowchart.

New cardano-signer release which brings more Calidus Key updates

1.24.0

Calidus Pool-Key updates

  • A new path shortcut --path calidus was added to the keygen function

  • Using the new calidus path also switches the output description of skey/vkey files to be Calidus Pool Signing Key and Calidus Pool Verification Key

  • Using the new calidus path also outputs the new Calidus-ID in hex and bech format with the --json-extended flag

  • The sign --cip88 function to generate Calidus Key registration data now also outputs the new Calidus-ID in hex and bech format. In addition it also outputs the Pool-ID in bech format.

  • The verify --cip88 function to verify Calidus Key registration data now also outputs the new Calidus-ID in hex and bech format. In addition it also outputs the Pool-ID in bech format.

1 Like

A new koios query endpoint was added for Sancho-Net
:slight_smile:

This can be accessed at the url:

curl -s "https://sancho.koios.rest/api/v1/pool_calidus_keys" | jq .

A new koios query beta endpoint was added for Mainnet :collision:

This can be accessed at the url:

curl -s "https://api.koios.rest/api/beta/pool_calidus_keys" | jq .
1 Like

Here is a super short (CLI) demonstration on a server/application side workflow using a tiny bash script

You can find the little demo script here:

Updates on koios

  • We have now a full Integration (no beta anymore) on Preview-Network
curl -s "https://preview.koios.rest/api/v1/pool_calidus_keys" | jq .
2 Likes