Skip to main content
Rotating the consensus key is a high-risk operation. Done incorrectly, it can result in permanent tombstoning from double-signing. Follow these steps precisely and only perform a key rotation during a scheduled maintenance window.
Never run two nodes with the same consensus key simultaneously. If both nodes sign the same block, the validator is permanently tombstoned and cannot be recovered.

​
When to rotate keys

  • Suspected compromise of priv_validator_key.json
  • Migrating to a new host with a remote signer (tmkms)
  • Hardware failure requiring a new consensus key

​
Preparation

  1. Ensure your operator key and Sovereign license are unaffected — key rotation only changes the consensus key
  2. Have a maintenance window scheduled
  3. Notify delegators if possible

​
Rotation procedure

1

Generate a new consensus key on the new/target setup

On the new host or remote signer:
Note the new public key value.
2

Stop signing on the old key

Stop the validator or remote signer that holds the old consensus key:
Verify the node has stopped completely before proceeding.
3

Submit MsgEditValidator with the new public key

4

Copy the new consensus key to the validator host

5

Reset priv_validator_state.json

The state file must be reset for a fresh key — do NOT copy an old state file for a new key:
6

Start the node

Verify the node starts signing blocks with the new key.

​
Verify the new key is active

The returned public key should match the new priv_validator_key.json public key.

​
Remote signer migration (tmkms)

If migrating to tmkms, follow the tmkms documentation for key import and signer configuration. The overall flow is the same: stop signing on the old key, update the validator with the new public key, start the new signer.