Skip to main content
Every account on Sei has a unique public key. You can use this public key to generate multiple wallet addresses, and these addresses are functionally the same. They look different, but they both point to the same destination: your account. Depending on the dApp, they may be used interchangeably. The difference is like the difference between the numeral “2” and the word “two”. They both define the same value, but they 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 look different, they share the same underlying account. After the two addresses are linked through association (described below), any action that you take with one address also affects the other. After association, if you deposit funds into your EVM address, you can access and use the same funds with your Sei address. The reverse is also true. The two addresses behave as one account. Until the addresses are associated, they are treated as separate accounts with separate balances (see Before linking below). Both addresses of an account are derived from the same public key. The chain can recognize the link between them only after it knows the public key. The chain learns the public key through association.

Key points

Before linking

  • The Bech32 (sei...) and EVM (0x...) addresses are treated as separate accounts.
  • They have separate balances until they are linked.
  • If the EVM address receives Cosmos tokens before association, a temporary Cosmos Bech32 address holds them. The tokens transfer to the associated address when the addresses are linked.
  • Some types of transactions are not possible (see the table below).

After linking

  • Both addresses show the same balance.
  • Applications can query either address format.

Wallet association and transfer limitations

Some actions are not possible before the wallets are associated:
  • Transfers of CW-based tokens (for example, CW20, CW721, and CW1155) from a non-EVM wallet to an unassociated EVM address.
  • Transfers of ERC-based tokens (for example, ERC-20, ERC-721, and ERC-1155) from an EVM wallet to an unassociated Cosmos address.

Methods of association

Each method makes the public key known to the chain. The chain then associates the EVM-compatible and Bech32 addresses automatically. All four methods go through the on-chain addr precompile (0x0000000000000000000000000000000000001004) or the EVM ante handler. They are available on every Sei EVM RPC.
The legacy sei_associate JSON-RPC method is no longer available. Method 3 offers the same wallet-signed-message flow through the addr precompile.
You can also find constants for the addr precompile in the Sei-Chain/precompiles repository.

Method 1: Broadcast a transaction

  • When an account broadcasts a transaction, such as a token transfer, its public key is recorded on-chain.
  • After the public key is known, the EVM address and the Bech32 address are linked automatically.
  • As a result, balances and transactions are accessible from both address formats.

Method 2: Direct private key association

Security risk: High. This method requires direct access to the private key. An exposed private key can compromise the wallet.
This method uses the private key directly to interact with the network.

Method 3: Associate via signed message

Security risk: Medium. This method requires you to sign a specific message with the private key.
In this method, you sign a predefined message to prove that you own the account.

Method 4: Associate via public key

Security risk: Low. This method uses 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

To resolve either side of an existing association, call the addr precompile at 0x0000000000000000000000000000000000001004 with a standard eth_call. The precompile is available on every Sei RPC.

Fetch Bech32 address for an EVM address

The selector 0x0c3c20ed is getSeiAddr(address). The call returns the bech32 sei1… address as an ABI-encoded string. If the EVM address is not associated yet, the call reverts. In TypeScript with viem:

Fetch EVM address for a Sei address

If the address has never been associated, the precompile reverts. Handle the revert as a “not linked” result instead of re-throwing it.

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 public key). The EVM (0x…) side follows the standard Ethereum derivation (keccak256 of the uncompressed public key without its 0x04 prefix byte).

Sei address derivation

The Cosmos address is derived from the public key in these steps:
  1. Take the compressed secp256k1 public key (33 bytes, with a first byte of 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 in these steps:
  1. Take the uncompressed secp256k1 public key (65 bytes, with a first byte of 0x04).
  2. Drop the leading 0x04 prefix byte, so that the input to the hash is the bare 64-byte (x, y) coordinate pair.
  3. Hash these bytes with keccak256.
  4. Take the last 20 bytes of the hash and format them 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:] (the 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 deterministically from the public key.

Why it works

Both formats are deterministic address schemes derived from the public key. The public key is recorded on-chain through any of the four association methods above, or implicitly through a first signed transaction. After that, the chain can derive both formats itself and route any incoming reference to the same account.

Recap

  • Accounts are linked automatically when a transaction is broadcast. You can also associate them manually through the addr precompile (associate or associatePubKey).
  • Both address formats share the same public key.
  • After linking, dApps and tools can access balances consistently across both address formats.

HD paths and coin types

When you derive a private key from a mnemonic phrase, the hierarchical deterministic (HD) path has multiple parameters, including the coin type. The coin type determines the blockchain ecosystem that the key is derived for. This matters when you work with different wallets and blockchains.

Coin type parameter

The second parameter in the HD path specifies the coin type, which the BIP-44 standard defines. This parameter identifies the blockchain ecosystem of the derived keys.
  • Ethereum (coin type 60): Wallets such as MetaMask use coin type 60. The typical HD path for Ethereum is m/44'/60'/0'/0/0.
  • Cosmos (coin type 118): Wallets for Cosmos-based chains, such as OKX, use coin type 118. The typical HD path for Cosmos is m/44'/118'/0'/0/0.

Implications

You cannot use an Ethereum mnemonic phrase (coin type 60) directly in a Cosmos wallet (coin type 118) to access the same accounts. The HD path determines a different set of keys for each coin type, so the derived addresses differ.

Private key export

You can export your private key from MetaMask (derived with coin type 60) and import it into any Cosmos wallet. This works because a derived private key can be used across different blockchain ecosystems, if the receiving wallet supports the import function. You can then manage your assets across various blockchains with 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 a bech32 address (Cosmos and Tendermint style) and a hex address (Ethereum style) from the same public key. Each format uses its own hashing scheme. The bech32 address uses the Cosmos-standard SHA256 then RIPEMD160. The hex address uses the keccak256 method, which is common in EVM networks. These snippets have detailed comments. They show the correct method to derive both bech32 and hex addresses from a given ECDSA secp256k1 key: