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.

Prerequisites

• The chain lists ml_dsa_65 in its consensus params. Check with the commands in Enable ML-DSA keys. If the type is missing, follow the guide to add it.
• 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. Generate an ML-DSA consensus key

Generate a fresh ML-DSA keypair for the new node.

The new key must be freshly generated. Reusing existing key material on two nodes is a double sign, which tombstones the validator.

2. Rotate to the new key

The procedure is the standard rotation for your chain type. The only change is that the new node runs the ML-DSA key from step 1 instead of a key the rotation guide generates.

On a staking chain

Follow Rotate a consensus key, Staking with one change: Step 1 of that guide creates the second node with simd init, which generates an ed25519 key. Before starting that node, replace its priv_validator_key.json with the ML-DSA key file from step 1.

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:

1. Step 1 of that guide generates the new key with simd init. Before submitting, replace ~/.poa-newkey/config/priv_validator_key.json with the ML-DSA key file from step 1 of this guide.
2. The submit command passes the key type as an argument. Pass ml_dsa_65 instead of ed25519:

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)" --from val

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 shadow 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.
• 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.