Skip to main content
Key rotation replaces a validator’s consensus key in place: no unbonding, no downtime, and no change to the validator’s identity, power, or delegations. Rotation is a single operator-signed message on the x/staking and enterprise/poa modules, and realizes a design first proposed in 2019 as ADR-016.

​
Which keys rotate

A validator runs on three keys, each with a different owner and job:
  1. Operator key: an ordinary account key that the operator generates and custodies, often on a hardware wallet or behind a multisig. It owns the validator: it stakes, sets commission, edits the validator’s description, withdraws rewards, votes, and signs the rotation message itself. Like any account key, it has no in-place replacement; retiring one means creating a new account and moving funds.
  2. Consensus key: generated by the stack when a node initializes, stored in priv_validator_key.json or held by a remote signer. It is a raw keypair with no mnemonic behind it; the operator custodies the file, not a seed phrase. It signs the validator’s vote on every block, and a block proposal whenever the validator’s turn comes to propose. Evidence of misbehavior identifies the validator through this key’s consensus address. This is the only key a rotation touches.
  3. Node key: the node’s peer-to-peer identity. It exists so peers can address and authenticate each other: its public key hashes to the node ID used in peer addresses, and it secures the connection handshake between nodes. It carries no on-chain state and regenerates freely.
On chain, a validator is the pairing of an operator address with a consensus key. Rotation replaces the consensus half of that pairing and leaves everything the operator key controls alone. For the full survey of keys and algorithms, see Post-quantum keys.

​
How a rotation works

The operator submits MsgRotateConsPubKey, carrying the new consensus public key. Everything that defines the validator stays put: the operator address, voting power, delegations, and commission. Only the consensus key and its index change. The new key does not take effect immediately. The chain emits the power hand-off to CometBFT right away, setting the old key to zero and giving the new key the validator’s full power, and CometBFT’s validator update rule makes it effective two heights later, at the same height the chain swaps its stored key. Zero downtime rides on this: the operator runs a second node with the new key alongside the old one. Until the rotation takes effect, the second node follows the chain as a non-signing full node, because a CometBFT node whose key is outside the validator set produces no votes. The moment the new key enters the set, the second node starts signing, the old key holds no power, and the operator retires the old node. The step-by-step procedure is in Rotate a consensus key, Staking.

​
Safety rails

Three rules bound what a rotation can do:
  1. A rotation burns a flat fee, set by the KeyRotationFee staking param, to make rotation spam expensive.
  2. A validator can rotate once per unbonding period. Until the unbonding period ends, the previous key remains accountable, so the chain rejects a second rotation inside the window.
  3. A rotation cannot be undone. No cancel message exists, and the once-per-unbonding-period limit blocks an immediate rotation back, so an applied rotation stands until the window expires.
Slashing follows a validator’s history, not the key. The chain keeps a mapping from each historical consensus address to its validator for the length of the unbonding period, so evidence of a double sign under the old key still slashes the validator after rotation. Rotating away from a key does not allow a validator to escape slashing.

​
Exports and restarts

In-progress rotations survive a genesis export. A chain exported mid-rotation carries the pending rotation and its remaining history window into the new genesis, so restarting a chain does not lose slashing accountability or drop a queued key change.

​
Staking and PoA chains

Rotation ships in both validator models. On staked chains, it is the x/staking implementation described above; for the procedure, see Rotate a consensus key, Staking. Chains running enterprise/poa get the same rotation with two differences. The admin can rotate any validator’s key, not only the operator. And because PoA has no slashing or evidence handling, the safety rails above do not apply: no fee, no rate limit, no rotation history, and the state swap happens in the block the transaction lands. For the procedure, see Rotate a consensus key, PoA.

​
Next steps