-
“hex” Address: Starts with
0xand is EVM-based. -
“bech32” Address: Starts with
sei1and is used for Cosmos functions.

Key Points
Before Linking
- The Bech32 (
sei...) and EVM (0x...) addresses are treated as separate accounts. - They will have separate balances until linked.
- Cosmos tokens received by the EVM address prior to association will be held in a temporary Cosmos Bech32 address, which will transfer to the associated address upon linking.
- Some types of transactions will not be possible (see table below).
After Linking
- Balances are reflected consistently across both addresses.
- Applications can query either address format seamlessly.
Wallet Association and Transfer Limitations
Certain actions are not possible before wallets are associated:- Transfers of CW-based tokens (e.g., CW20/721/1155) from a non-EVM wallet to an unassociated EVM address.
- Transfers of ERC-based tokens (e.g., ERC20/721/1155) from an EVM wallet to an unassociated Cosmos address.
Methods of Association
addr precompile (0x0000000000000000000000000000000000001004) or the EVM ante handler and are available on every Sei EVM RPC.sei_associate JSON-RPC method has been retired — the method is part of the deprecated sei_* namespace and is not in the default enabled_legacy_sei_apis allowlist, so it returns legacy_sei_deprecated on public RPCs. Method 3 covers the same wallet-signed-message UX without depending on a gated endpoint. Node operators who want to re-enable the legacy method on their own infrastructure can add sei_associate to enabled_legacy_sei_apis in app.toml — see Node Operators for the surrounding config.addr precompile can also be found in the repo
Sei-Chain/precompiles:
Method 1: Broadcast a Transaction
- When an account broadcasts a transaction (e.g., sending tokens), its public key is recorded on-chain.
- Once the public key is known, the EVM address and Bech32 address are linked automatically.
- This ensures balances and transactions are accessible across both address formats.
Method 2: Direct Private Key Association
Method 3: Associate via Signed Message
This method involves signing a predefined message to prove ownership of the account.Method 4: Associate via Public Key
Query Linked Addresses
Resolve either side of an existing association by calling theaddr precompile at 0x0000000000000000000000000000000000001004 over a standard eth_call. The precompile is universally available on every Sei RPC.
Fetch Bech32 Address for an EVM Address
0x0c3c20ed is getSeiAddr(address). The returned ABI-encoded string is the bech32 sei1… address, or the call reverts if the EVM address is not yet associated.
In TypeScript with viem:
Fetch EVM Address for a Sei Address
Deriving Addresses from the Public Key
Both address formats come from the same secp256k1 public key, but they use different hashing schemes: the bech32 (sei1…) side follows the standard
Cosmos derivation (SHA256 then RIPEMD160 of the compressed pubkey), and
the EVM (0x…) side follows the standard Ethereum derivation (keccak256 of
the uncompressed pubkey without its 0x04 prefix byte).
Sei Address Derivation
The Cosmos address is derived from the public key using the following steps:- Take the compressed secp256k1 public key (33 bytes; first byte
0x02or0x03). - Hash it with
SHA256. - Hash the result with
RIPEMD160to get a 20-byte digest. - Encode that digest in Bech32 format with the
seiprefix.
EVM Address Derivation
The EVM-compatible address is derived as follows:- Take the uncompressed secp256k1 public key (65 bytes; first byte
0x04). - Drop the leading
0x04prefix byte so the input to the hash is the bare 64-byte(x, y)coordinate pair. - Hash with
keccak256. - Take the last 20 bytes of the hash and format as
0x…hex.
Summary
- Sei Address:
bech32('sei', RIPEMD160(SHA256(compressedPubKey)))— 20 bytes, Cosmos-standard derivation. - EVM Address:
'0x' + keccak256(uncompressedPubKey[1:])[-20:]— last 20 bytes of the keccak256 hash, Ethereum-standard derivation. - The two formats share an account because the chain stores the public key itself on association; either format can be derived from it deterministically.
Why It Works
Both formats are deterministic, public-key-derived address schemes. Once the public key is on-chain (via any of the four association methods above, or implicitly via a first signed transaction), the chain can derive both formats itself and route any incoming reference to the same account.Recap
- Accounts are automatically linked when a transaction is broadcast, or can be
associated manually via the
addrprecompile (associate/associatePubKey). - Both address formats share the same public key.
- Linking enables dApps and tools to access balances consistently across both address formats.
HD Paths and Coin Types
When deriving a private key from a mnemonic phrase, the hierarchical deterministic (HD) path involves multiple parameters, including the coin type. The coin type determines the blockchain ecosystem for which the key is derived, making it crucial when dealing with different wallets and blockchains.Coin Type Parameter
The second parameter in the HD path specifies the coin type, which is defined by the BIP-44 standard. This parameter identifies the blockchain ecosystem associated with the derived keys.- Ethereum (Coin Type 60): Wallets like MetaMask use coin type 60. The HD
path for Ethereum typically looks like this:
m/44'/60'/0'/0/0. - Cosmos (Coin Type 118): Wallets for Cosmos-based chains, such as OKX,
use coin type 118. The HD path for Cosmos typically looks like this:
m/44'/118'/0'/0/0.
Implications
Due to the different coin types, a mnemonic phrase used to derive keys for Ethereum (coin type 60) cannot be directly used in a Cosmos wallet (coin type 118) to access the same accounts. This is because the HD path determines a different set of keys for each coin type, meaning the derived addresses will differ.Private Key Export
Users can export their private key from MetaMask (derived using coin type 60) and import it into any Cosmos wallet. This works because the private key, once derived, can be used across different blockchain ecosystems, provided the receiving wallet supports the import function. This allows users to manage their assets across various blockchains using the same underlying cryptographic key.Example HD Paths
- Traditional Cosmos Path:
m/44'/118'/0'/0/0 - Traditional EVM Path:
m/44'/60'/0'/0/0
Generating Wallets
Deriving bech32 and hex addresses from pubkey
Sei derives both the Cosmos/Tendermint style bech32 address and the Ethereum-style hex address from the same public key, but each format uses its own hashing scheme: the bech32 address uses the Cosmos-standardSHA256 then
RIPEMD160, while the hex address uses the keccak256 method common in EVM
networks. These extensively commented snippets demonstrate the ‘proper’ method
of deriving both bech32 and hex addresses from a given ECDSA SECP256k1 key:
Python - from pubkey
Python - from pubkey
Typescript - from pubkey
Typescript - from pubkey
Typescript - Full Derivation from Private Key
Typescript - Full Derivation from Private Key