Keplr chain configuration remains coin-type 118 after successful EVM migration

[Josmar-J]

Summary

The EVM migration completed successfully and generated a new EVM-compatible address.

However, the migration page still reports:

• Portal profile: lumera-testnet-evm / coin type 60 ✅
• Keplr chain config: coin type 118 ❌
• Keplr account key: legacy key / coin type 118 ❌

As a result, Keplr continues deriving the legacy address instead of the migrated EVM address.

---

Environment

• Wallet: Keplr Extension
• Keplr Version: 0.13.39
• Browser: Google Chrome
• Operating System: Windows 10

---

Steps to reproduce

1. Successfully complete the official EVM migration.
2. Disable the legacy Lumera chain in Keplr.
3. Disconnect and reconnect through the official EVM migration portal.
4. Import the same recovery phrase into a newly created Keplr wallet profile (as described in the migration guide).
5. Connect the wallet again.

---

Expected behavior

Keplr should:

• update the chain configuration to coin type 60;
• derive the migrated EVM-compatible address;
• report both Keplr chain config and Keplr account key as coin type 60.

---

Actual behavior

Keplr continues deriving the legacy address.

Migration page reports:

• Keplr chain config: coin type 118
• Keplr account key: legacy key / coin type 118

even after importing the same mnemonic into a newly created Keplr wallet profile.

---

Legacy address

lumera1upum3lml2v9kc0z6r65kchdh3lt80h8w4ekex5

Migrated address

lumera1w3phqunwpcy5wqnrxzau0ga3cahkc6vdw0ncj2

---

Migration transaction

40EF86E1FCEF0BED100EB2B1410C20116786CB0EEEEF6BD73708B856F3A4204A

---

Additional observation

The migration itself appears to have completed successfully.

The issue seems to be that the Keplr chain configuration never switches from coin type 118 to coin type 60, preventing the wallet from deriving the migrated address.

Could this be:

• a known issue,
• an incomplete chain configuration update,
• or is an additional migration step currently required?

---

Attachments

Attached screenshots show:

1. Successful migration.
2. Migration status page (Portal = coin type 60, Keplr = coin type 118).
3. Keplr wallet behavior.

[j19165708-stack]

@Josmar-J have you been able to resolve this issue?

[Josmar-J]

Hi!

No, I have not been able to solve it yet.

The migration completed successfully, but the problem still persists.

Current migration status:

• Portal profile: lumera-testnet-evm / coin type 60
• Keplr chain config: coin type 118
• Keplr account key: legacy key / coin type 118

I also:

• disabled the legacy Lumera chain;
• reconnected through the EVM portal;
• imported the same recovery phrase into a newly created Keplr wallet profile.

The wallet still derives the legacy address instead of the migrated address.

If there is an additional required step, I'd be happy to test it.

[Josmar-J]

Thank you for your suggestion.

However, I will not use third-party support pages or external live chat services.

This issue concerns the official Lumera EVM migration implementation and should be handled through this GitHub issue or other official Lumera communication channels.

The problem has already been technically isolated:

• ✅ Migration transaction completed successfully.
• ✅ Portal profile correctly reports lumera-testnet-evm / coin type 60.
• ❌ Keplr chain configuration remains coin type 118.
• ❌ Keplr account key remains a legacy key (coin type 118).
• ❌ Re-importing the same mnemonic into a newly created Keplr profile still derives the legacy address.

Based on these observations, the issue appears to be one of the following:

• an incomplete chain configuration update;
• a Keplr integration issue;
• or an undocumented migration step.

If you are a Lumera maintainer or contributor, please provide a technical explanation, documentation reference, or implementation details related to the migration process.

Otherwise, I will wait for guidance from the official Lumera development team within this repository.

[astrostake]

Additional Insights & Resolution

I encountered the exact same issue where Keplr persisted in deriving the legacy address via coin type 118 instead of switching to the migrated coin type 60 configuration.

The key is that simply disabling the legacy chain within the Keplr extension is insufficient, as the extension retains the old chain configuration cache.

To fix this and force Keplr to correctly derive the migrated address, you must completely remove the legacy custom chain from the extension instead of just turning it off.

Resolution Steps:

1. Open the Keplr extension and navigate to Settings.
2. Under the Chains and Assets section, select Remove Custom Chains.

3. Click the X button next to Lumera Testnet to completely delete the legacy configuration.

4. Reconnect your wallet to the lumera-testnet-evm. This will trigger a fresh chain suggestion prompting Keplr to accept the new lumera-testnet-evm chain configuration with the correct coin type 60.

5. Once the new chain configuration is suggested and approved, re-import your recovery phrase into a new Keplr wallet profile if needed to correctly derive the new EVM-compatible address.

[Josmar-J]

Additional investigation

After removing the legacy custom chain and adding lumera-testnet-evm again, Keplr is no longer using the legacy address.

However, it still does not derive the migrated address reported by the migration tool.

Current addresses:

Legacy:

lumera1upum3lml2v9kc0z6r65kchdh3lt80h8w4ekex5

Migrated (reported by the Portal):

lumera1w3phqunwpcy5wqnrxzau0ga3cahkc6vdw0ncj2

Current Keplr-derived address:

lumera1f0ggx78sv464ztgpgt2jg8a2r6njkr3yzz9r62

The current Keplr-derived address is an empty account.

This suggests that Keplr is deriving a different HD account than the one used by the migration tool.

Could you please confirm:

• which derivation path should be used?
• which account index the migration tool expects?
• whether the migration targets a non-default HD account?

[astrostake]

@Josmar-J Have you re-imported the recovery phrase?

A Keplr wallet profile derives its keys from the mnemonic at creation time using the chain's then-current bip44.coinType. Existing profiles aren't re-derived when the chain config later changes. Importing the same mnemonic into a new profile, after the chain registry is on coin-type 60, makes Keplr derive the EVM-compatible (P_60) key.

[j19165708-stack]

@Josmar-J For quick review and assistance, contact the support agent on the live chat page to report your issue via Web Support page
You will see chat button once you click the Web support, create issue ticket while the active support interact with you immediately,do you see green chat icon below the web support then create chat then they join you instantly

[Josmar-J]

@Josmar-JVocê reimportou a frase de recuperação?

Um perfil de carteira Keplr deriva suas chaves do mnemônico no momento da_ criação_ usando o . atual da cadeiabip44.coinType. Os perfis existentes não são derivados novamente quando a configuração da cadeia é alterada posteriormente. Importar o mesmo mnemônico para um novo perfil, depois que o registro da cadeia estiver ativadocoin-type 60, faz com que o Keplr derive a chave compatível com EVM (P_60).

Hi @astrostake,

Yes, I did.

After completely removing the legacy custom chain, I accepted the new lumera-testnet-evm chain suggestion and then imported the same recovery phrase into a newly created Keplr profile.

The result is that Keplr now derives a different address, which indicates it is no longer using the legacy coin-type 118.

However, the derived address is still not the migrated address reported by the migration tool.

Current situation:

Legacy address:

lumera1upum3lml2v9kc0z6r65kchdh3lt80h8w4ekex5

Migrated address reported by the Portal:

lumera1w3phqunwpcy5wqnrxzau0ga3cahkc6vdw0ncj2

Address currently derived by the newly imported Keplr profile:

lumera1f0ggx78sv464ztgpgt2jg8a2r6njkr3yzz9r62

The newly derived address is an empty account.

So it appears that the coin-type is no longer the issue. The remaining question is why the Keplr-derived address still does not match the migrated address generated by the migration tool.

Could this be related to a different HD account index or derivation path?

[j19165708-stack]

@Josmar-J kindly create chat with the active support above i sent to you Web Support page