Migrate a validator to ML-DSA

Move a validator’s consensus key to the post-quantum ml_dsa_65 algorithm through an ordinary key rotation.

Migrating a validator to post-quantum signing is an ordinary key rotation with an ML-DSA target key. This guide adds the ML-DSA-specific steps around the standard procedure in Rotate a consensus key, Staking. For more information on ML-DSA, see Post-quantum keys.

Key rotation can introduce security implications for your chain. Read the Key rotation overview in its entirety before proceeding.

Before rotating any validator to ML-DSA, confirm every counterparty chain that verifies this chain over IBC runs CometBFT v0.40 or later. An older 07-tendermint light client cannot verify ML-DSA consensus signatures. See IBC considerations for more information.

Prerequisites

• All prerequisites of the rotation procedure: jq and curl, no rotation in the current unbonding period, and fee funds on the operator account. See Rotate a consensus key, Staking.
• The chain’s binary; the examples use simd. To build it and run a node, see Run a node.

1. Confirm the chain allows ML-DSA

Validator key types are a consensus parameter. Check that ml_dsa_65 is in the list:

simd query consensus params

If 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 the simd init command in its step 1 with one that adds --consensus-key-algo ml_dsa_65 to create an ML-DSA key:

simd init rotation-node --chain-id my-chain-1 --consensus-key-algo ml_dsa_65 --home ~/.rotation-node

Everything else runs as written. The guide’s rotation command derives the public key with 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 the simd init command in its step 1 with:

simd init poa-newkey --chain-id my-chain-1 --consensus-key-algo ml_dsa_65 --home ~/.poa-newkey

And pass ml_dsa_65 instead of ed25519 as the key type when submitting. The ML-DSA public key may be large enough that the default gas limit runs out, so add --gas auto:

simd tx poa rotate-cons-pub-key "$(simd comet show-validator --home ~/.poa-newkey | jq -r .key)" ml_dsa_65 --operator-address "$(simd keys show val -a --home ~/.node)" --from val --home ~/.node --gas auto --gas-adjustment 1.5

The cutover timing is unchanged: keep the node on the old key until the validator set switches, then swap the key file in place, exactly as the guide’s steps 3 and 4 describe.

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:

curl -s localhost:26657/validators | jq -r '.result.validators[].pub_key.type'

A migrated validator reports 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_65 yet. See Enable ML-DSA keys.
• Anything else follows the standard rotation failure modes. See Rotate a consensus key, Staking.

The consensus key this rotation installs is a raw keypair with no mnemonic behind it. Custody the key file, not a seed phrase.

Next steps

• Check which key types the chain allows and which the validator set is running. See Enable ML-DSA keys.
• Understand the storage and bandwidth costs the chain takes on as the set migrates. See Post-quantum keys.