You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is an ongoing significant issue with the way wallets are derived for Sei / Sei-EVM. There are some important considerations to make in how exactly this issue is resolved.
Problem
As a dual-execution layer network, not having the same account as the signer for both the Cosmos and EVM environments creates major issues:
Completely breaks interoperability.
Significantly harms the functionality of the network overall.
Simplest Solution (Not Ideal)
One solution is to simply enforce the same cointype across both the Sei and Sei-EVM environments within Keplr wallet. This would:
Provide the "correct" wallet address (same underlying signer / key) for both environments.
Ensure full functionality for applications and protocols, both on-chain and interchain.
This solution is not ideal because:
Older wallets are derived using cointype 118.
Recently onboarded wallets are derived using cointype 60.
Arbitrarily forcing one cointype over the other significantly harms (UX).
Cointype Considerations
To my knowledge:
Cointype is arbitrary and has no direct impact on wallet/account functionality.
Problems arise only when the cointype (or any part of the derivation path) is inconsistent across interoperable accounts within an environment.
Recommended Solution
Rather than enforcing a single cointype, the recommended approach is to provide users with the flexibility to select their preferred cointype. Specifically:
Allow users to select either cointype 118or60 for both Sei and Sei-EVM wallets.
This approach preserves interoperability, ensures consistency, and avoids the UX issues caused by forcing a single cointype.
Broader Impact
This issue is a blocker for several recently launched IBC networks collaborating with Sei. For example:
A user engaging with EVM DeFi applications on Sei will face significant difficulties moving tokens to other IBC-enabled chains.
This creates a UX comparable to having different wallets for every single chain within Keplr. Such a poor experience would discourage users from using the chain more than once and is a major blocker for external teams integrating with this network.
Summary
To maintain interoperability, improve user experience, and support developers building in the interchain ecosystem, it is crucial to allow users to select their preferred cointype (118 or 60) for both Sei and Sei-EVM wallets.
The text was updated successfully, but these errors were encountered:
Issue: Wallet Derivation for Sei / Sei-EVM
There is an ongoing significant issue with the way wallets are derived for Sei / Sei-EVM. There are some important considerations to make in how exactly this issue is resolved.
Problem
As a dual-execution layer network, not having the same account as the signer for both the Cosmos and EVM environments creates major issues:
Simplest Solution (Not Ideal)
One solution is to simply enforce the same cointype across both the
Sei
andSei-EVM
environments within Keplr wallet. This would:This solution is not ideal because:
Arbitrarily forcing one cointype over the other significantly harms (UX).
Cointype Considerations
To my knowledge:
Recommended Solution
Rather than enforcing a single cointype, the recommended approach is to provide users with the flexibility to select their preferred cointype. Specifically:
118
or60
for bothSei
andSei-EVM
wallets.This approach preserves interoperability, ensures consistency, and avoids the UX issues caused by forcing a single cointype.
Broader Impact
This issue is a blocker for several recently launched IBC networks collaborating with Sei. For example:
Summary
To maintain interoperability, improve user experience, and support developers building in the interchain ecosystem, it is crucial to allow users to select their preferred cointype (
118
or60
) for both Sei and Sei-EVM wallets.The text was updated successfully, but these errors were encountered: