Prerequisites
- All prerequisites of the rotation procedure, including jq and curl: no rotation in the current unbonding period, and fee funds on the operator account. See Rotate a consensus key, Staking.
1. Confirm the chain allows ML-DSA
Validator key types are a consensus parameter. Check thatml_dsa_65 is in the list:
validator.pub_key_types does not include ml_dsa_65, the rotation is rejected. To add the type, see Enable ML-DSA keys.
2. Rotate to an ML-DSA key
On a staking chain
Follow Rotate a consensus key, Staking, replacing thesimd init command in its step 1 with one that adds the --consensus-key-algo flag:
simd comet show-validator on the second node’s home, which now prints the ML-DSA key, so the rotation message carries it automatically.
On a PoA chain
Follow Rotate a consensus key, PoA with two changes. Replace thesimd init command in its step 1 with:
ml_dsa_65 instead of ed25519 as the key type when submitting:
On a remote signer
If the validator’s consensus key lives in Cosmos-KMS rather than a local file, the second node gets its own signer and the public key derivation differs. See Rotate a consensus key held in Cosmos-KMS.3. Verify
Check the key type in the validator set:cometbft/PubKeyMlDsa65 instead of tendermint/PubKeyEd25519. The chain’s consensus is post-quantum secure once validators holding at least two thirds of voting power report a post-quantum type. For more information, see Post-quantum keys.
What can go wrong
- The rotation is rejected for an unsupported key type: the chain does not list
ml_dsa_65yet. See Enable ML-DSA keys. - The rotation is rejected with a rotation limit error: a rotation already happened this unbonding period. Wait out the window.
- Anything else follows the standard rotation failure modes. See Rotate a consensus key, Staking.
Next steps
- Track migration progress across the validator set with the allowed-vs-in-use commands. See Enable ML-DSA keys.
- Understand the storage and bandwidth costs the chain takes on as the set migrates. See Post-quantum keys.