Skip to main content
Every account on Sei has a unique public key. This public key can be used to generate multiple wallet addresses, but it is important to note that the two are functionally the same. They appear different, and depending on the app they may be used interchangeably, but they both point to the same destination - your account. The difference is like the difference between the numeral “2” and the word “two”. They both define the same value, but may be used in different contexts.
  • “hex” Address: Starts with 0x and is EVM-based.
  • “bech32” Address: Starts with sei1 and is used for Cosmos functions.
Address derivation Although these addresses appear different, they actually share the same underlying account. Once the two addresses are linked through association (described below), whatever action you take with one address also affects the other. Once associated, if you deposit funds into your EVM address you can access and use those same funds with your SEI address, and vice versa — they behave as one account, ensuring seamless integration between the EVM and SEI ecosystems. Until the addresses are associated, they are treated as separate accounts with separate balances (see Before Linking below). Both addresses for a single account are derived from the same public key, but the chain can only determine their association after the public key is known by the chain via association.

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

Each method ensures the public key is known to the chain, enabling automatic association between the EVM-compatible and Bech32 addresses. All four go through the on-chain addr precompile (0x0000000000000000000000000000000000001004) or the EVM ante handler and are available on every Sei EVM RPC.
A previous “gasless” association flow that used the 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.
Constants for the 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

Security Risk: High – Requires the private key to be directly available. Exposing the private key can compromise the wallet.
This method directly uses the private key to interact with the network.

Method 3: Associate via Signed Message

Security Risk: Medium – Requires signing a specific message using the private key.
This method involves signing a predefined message to prove ownership of the account.

Method 4: Associate via Public Key

Security Risk: Low – Involves using the public key, which is less sensitive than the private key.
This method compresses the public key and sends it for association.

Query Linked Addresses

Resolve either side of an existing association by calling the addr precompile at 0x0000000000000000000000000000000000001004 over a standard eth_call. The precompile is universally available on every Sei RPC.

Fetch Bech32 Address for an EVM Address

The selector 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

The precompile reverts if the address has never been associated; surface this as “not linked” rather than re-throwing.

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:
  1. Take the compressed secp256k1 public key (33 bytes; first byte 0x02 or 0x03).
  2. Hash it with SHA256.
  3. Hash the result with RIPEMD160 to get a 20-byte digest.
  4. Encode that digest in Bech32 format with the sei prefix.
Example implementation:

EVM Address Derivation

The EVM-compatible address is derived as follows:
  1. Take the uncompressed secp256k1 public key (65 bytes; first byte 0x04).
  2. Drop the leading 0x04 prefix byte so the input to the hash is the bare 64-byte (x, y) coordinate pair.
  3. Hash with keccak256.
  4. Take the last 20 bytes of the hash and format as 0x… hex.
Example implementation:

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 addr precompile (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-standard SHA256 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: