Validator Operator EVM Migration Guide

Applies to: validator operators running a Lumera validator against an EVM-enabled chain (post-EVM upgrade)

Prerequisite reading: EVM Migration User Guide for the chain-level mechanics of legacy → EVM account migration

Overview

When Lumera upgraded to an EVM-compatible chain, every validator's legacy secp256k1 operator key (coin-type 118) stopped matching the chain's new address derivation (eth_secp256k1, coin-type 60). This guide walks you through migrating that operator key.

<aside> 🔑

The validator consensus key (priv_validator_key.json) is not affected by this migration. It stays on the ed25519 algorithm and uses a separate HD path. Do not touch priv_validator_key.json; only the operator key (the one that signs MsgCreateValidator, withdraws commission, etc.) needs migration.

</aside>

Validators must use MsgMigrateValidator (not MsgClaimLegacyAccount). The chain explicitly rejects claim-legacy-account for validator operator addresses. MsgMigrateValidator is a superset — it re-keys the validator record, every delegation pointing to the validator, distribution state, supernode registration (if any), and action references in a single atomic transaction.

This guide's main flow covers the common single-sig validator operator key case. If your validator operator key is a K-of-N multisig (rare), see the Multisig validator operator keys section at the end.

<aside> 🖥️

Note on systemctl commands. This guide uses systemctl stop/start lumerad (and systemctl restart supernode) as examples. Many validators don't run the node under systemd — Docker/Kubernetes, cosmovisor, runit/s6, or a bare lumerad start under a process supervisor are all common. Substitute whatever supervises your node (e.g. docker stop <container>, your cosmovisor service unit, or pkill -f "lumerad start"). The only invariant that matters: lumerad must not be producing blocks when you broadcast the migration.

</aside>

What gets re-keyed

In addition to everything covered by a regular account migration (balances, authz, feegrants, claims, vesting), MsgMigrateValidator atomically handles:

• Validator record — operator address updated in both the primary record and power indices.
• All delegations — every delegator's active delegation to this validator is re-keyed to the new valoper.
• Unbonding delegations — all pending unbonds from this validator.
• Redelegations — where the validator is source or destination.
• Distribution state — current rewards, accumulated commission, outstanding rewards, historical rewards, slash events.
• Supernode record — if the validator runs a supernode on the same account, both the validator address and the supernode's SupernodeAccount field are updated. See the If you also run a supernode section below.
• Action records — any x/action module records referencing this validator.