Skip to main content
Lumera mainnet is upgrading to full EVM compatibility. The upgrade changes how account keys derive, which means your existing address is replaced by a new one derived from the same recovery phrase. Migration moves everything you hold at the old address to the new one. It is free, it takes a few minutes, and there is a deadline.
The mainnet upgrade has been rescheduled. The new date is to be announced. It was planned for block 6,715,000. Mainnet passed that height on v1.12.0 without upgrading, and no upgrade plan is on chain yet. Once the upgrade activates, you have three calendar months to migrate. Network status and upgrades carries the current versions and the queries behind them.

Migrate in the Portal

Open the EVM Migration page in the Lumera Portal once the mainnet upgrade activates.

​
What happens if you do nothing

This is the part worth reading twice, because the two halves of your account behave differently. Your liquid balance is safe either way. It stays at your legacy address and cannot be lost. You can still recover it after the window closes. Your staking is not. Delegations, unbonding delegations, redelegations, and accrued rewards become permanently unrecoverable once the window expires. There is no recovery path and no exception process. If you have anything staked, migrating inside the window is not optional.

​
The four things to know

It is free

Zero gas. The migration transaction carries no fee, so you do not need a balance to migrate.

It is one way

Your legacy address is permanently blocked once migration completes. Always use the official flow.

It is atomic

Everything moves in a single transaction. There is no partial state to recover from.

You have three months

The window opens at the upgrade block and closes three calendar months later. Testnet has run the same window since 2 July 2026.

​
Why Lumera is doing this

Lumera is adding a native Ethereum execution layer alongside the existing Cosmos layer. Both environments run on the same chain, share the same state, and share the same security. In practice that means MetaMask compatible accounts, full Ethereum JSON-RPC, Solidity and Vyper contracts, and precompiles that let EVM contracts call Lumera staking and SuperNode logic directly. Developers deploy with Hardhat, Foundry, or Remix without learning a new SDK. Wallets, indexers, and explorers built for EVM chains integrate without custom work. The reason is reach. Lumera is infrastructure for permanent data and decentralized services, and that depends on developers being able to build on it. Ethereum has the largest pool of contract developers and the deepest tooling of any platform. Reaching them from a Cosmos chain previously meant bridges and wrappers, which add friction for everyone. This removes it. Nothing on the Cosmos side goes away. IBC, validators, SuperNodes, governance, and bech32 addresses all keep working exactly as they do today.

​
Do you need to migrate

Everyone holding a pre-upgrade account does. What differs is the path.

​
How to migrate

Most people should use the Portal wizard. It handles both signatures and shows you the result.
1

Add the EVM chain profile to Keplr

Keplr needs the coin type 60 profile alongside your existing one. You will end up with two Lumera profiles, the legacy one and the EVM one, and this is expected.
2

Open the EVM Migration page in the Portal

Connect with your legacy account. The page shows your legacy address, your new address, and everything currently held at the legacy address.
3

Check both addresses

Confirm the destination matches what your recovery phrase derives under coin type 60. Migration is irreversible, so this is the step to slow down on.
4

Sign twice and submit

The transaction carries two proofs, an ADR-036 signature from the legacy key and an EIP-191 signature from the new key. The wizard prompts for both. There is no fee.
5

Re-import in Keplr and verify

Re-import your account under the EVM profile. The state panel on the migration page confirms what moved. Your balance and delegations should appear at the new address.
Prefer the command line, or migrating in bulk? The migration guide covers the shell scripts and the raw lumerad path, including the offline four step ceremony for multisig accounts.

​
What moves

Migration transfers all on-chain state in one transaction.
  • Bank balances in every denomination
  • Staking delegations, unbonding delegations, and redelegations
  • Authz grants and feegrant allowances, as granter and as grantee
  • Action records and claim records
  • SuperNode registration, where applicable
  • Vesting schedules, where applicable
For validators it additionally re-keys the operator address, every delegation pointing at the validator, distribution state, and any bound SuperNode.

​
After you migrate

One account now works in both wallets. Keplr shows the bech32 form starting lumera1. MetaMask shows the hex form starting 0x. Both point at the same funds. To use MetaMask, add the Lumera network and import the migrated account. The MetaMask guide has the network values and the full walkthrough.

​
Questions

No. Nothing works differently until mainnet upgrades. If you want to rehearse, testnet has run the identical flow since 2 July 2026. The testnet window closes on 2 October 2026.
The upgrade records it on chain as the migration_end_time parameter, three calendar months after the upgrade block time. Governance can change it. Once your network has upgraded, check it with lumerad query evmigration params.
No. The same phrase now derives a second address under coin type 60. That new address is your EVM compatible account, and migration moves your state to it.
Your liquid balance stays recoverable at the legacy address. Staking, delegations, unbonding, and rewards do not. They are permanently lost once the window closes, three calendar months after the upgrade.
No. The migration transaction is fee-free by design, so an empty account can still migrate.
No. The legacy account is removed from the auth module once migration completes, and the mapping is permanent. Only ever migrate through the official Portal flow or the guides linked here.
No. Only your operator key changes, from secp256k1 to eth_secp256k1. Your priv_validator_key.json is untouched. Validators must use MsgMigrateValidator, which the chain requires instead of the standard claim message.
A K-of-N legacy multisig migrates to a K-of-N EVM multisig, same K and same N. The chain enforces this. The destination can do everything on the Cosmos side but cannot originate EVM transactions, so set up a separate single-key account if you need EVM DeFi access.
Yes, until the window closes. Migrating early costs nothing and removes the risk of forgetting, so there is no reason to wait.

​
Get help

Discord

Ask in the support channel. Fastest route to a human.

What changed in v1.20.0

The technical release record, new modules, and the developer view.