Applies to: operators running a Lumera supernode against an EVM-enabled chain (post-EVM upgrade)
Prerequisite reading: EVM Migration User Guide for the chain-level mechanics of legacy → EVM account migration
When Lumera upgraded to an EVM-compatible chain, every supernode's legacy secp256k1 key (coin-type 118) stopped matching the chain's new address derivation (eth_secp256k1, coin-type 60). The supernode daemon performs the migration automatically on startup once you add a new EVM key to its config.
This is the common case for virtually every supernode operator. The rest of this document is the main walkthrough for that case.
<aside> ℹ️
If your supernode's on-chain operator account is a K-of-N multisig (rare, and only possible if you explicitly set one up), the daemon refuses to migrate and directs you to a manual lumerad CLI ceremony. See the Multisig supernode accounts section at the end.
</aside>
Migration is idempotent end-to-end: if anything fails mid-flight, restart the daemon and it resumes from whatever state the chain already has.
Both paths land in the same final state (new EVM key registered as supernode, legacy key deleted, config.yml updated). The operator steps are identical — what differs is whether the daemon initiates the on-chain migration or just finalizes one you already submitted.
evm_key_name to config.yml, and restart. The daemon detects the legacy key, dual-signs with both keys, and broadcasts MsgClaimLegacyAccount itself. This is the flow the rest of this guide documents in steps 1–4.config.yml, and restart. On startup the daemon sees the on-chain migration record, matches it against your configured evm_key_name, skips the broadcast, and performs only local cleanup.Path B is useful when you want to use Keplr's UX to see each step (the Portal shows balances, delegations, and a pre-migration checklist), when you need to migrate the account's balance urgently for non-supernode reasons, or when your node ops team and your wallet custody team are different people.
<aside> 💻
Terminal alternative for Path B. If you prefer to stay in a shell rather than use Keplr, you can drive the account-level migration with the bundled shell helper scripts instead of the Portal — the end state (on-chain migration record + matching local key) is identical, and the supernode daemon's alreadyMigrated branch activates the same way on restart. See the EVM Migration Helper Scripts Guide for the full walkthrough, including multisig rejection, pre-flight estimates, and exit codes. In short:
./scripts/migrate-account.sh legacy-key new-key \
--chain-id lumera-mainnet-1 --node tcp://rpc.lumera:26657
Then continue with Step B3 (recover the new EVM key into the supernode keyring) onward.
</aside>
Why both paths work deterministically: supernode keys recover derives keys at HD path m/44'/60'/0'/0/0 using eth_secp256k1. Keplr uses the identical derivation for Lumera's EVM chain definition. Import the chosen destination mnemonic into both tools so they produce the same destination address. That mnemonic may be the legacy mnemonic or a different one.
If you chose Path B, the steps below are the same but in Step 3 the logs will show a skipped broadcast (see the Path B log variant callout in that section).