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.
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.
You only need two commands to generate the registration metadata json file:
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.
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?
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.
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.
{
"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.
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.
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.
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.