Skip to main content
This guide is for exchanges, custodians, and other service providers that currently support SEI token deposits and withdrawals with native (sei1...) addresses. It explains what SIP-03 changes, the options to migrate customer holdings to EVM (0x...) addresses, and the date by which the migration must be complete.
IBC is already disabled in both directions. Proposals #116 and #120 disabled inbound IBC, and #121 disabled outbound IBC on July 31, 2026. No asset can be bridged into or out of Sei over IBC. As a result, IBC is not available as a route to move customer funds off Sei. IBC-bridged assets held on Sei can no longer be redeemed on their origin chain. See IBC is disabled.The migration options below move funds between the native and EVM sides of Sei. They are intra-chain, and the IBC parameters do not affect them.

​
What SIP-03 changes

SIP-03 has a practical implication for exchanges. Any integration that treats “Sei” (native) and “Sei EVM” as two separate chains needs to be merged into one integration before the Cosmos shutdown. Every native address (sei1...) on Sei has a corresponding EVM address (0x...) on the same chain. Native and EVM are not two distinct chains or wallets. They are two ways to interact with one chain.

​
Migration options

An exchange or custodian can migrate customer holdings to EVM in four ways.

​
1) Combine native and EVM access points

The exchange directly shows the customer the EVM (0x...) address that corresponds to each existing native (sei1...) wallet. Each sei1... address has exactly one corresponding 0x... address. The public key that both addresses are derived from determines the pair. The addresses cannot be paired freely, and association does not create the pairing. It only registers the pairing on-chain. Because the pairing already exists at the keypair level, no funds need to move. This is the cleanest path, and the customer does not need to take any action. It does require the exchange to:
  • Derive or look up the EVM address for each native wallet under management.
  • Make sure that the native and EVM addresses are associated on-chain (see Address association below).
  • Update internal accounting and customer-facing UI to present the EVM address as the canonical Sei address.

​
2) Automated forwarding contract

The exchange uses a FundsForwarder smart contract to move customer funds programmatically from the native side to the customer’s EVM wallet on the exchange. The exchange deploys and triggers the contract. The customer does not take any action and sees the funds arrive at the new address. This option is appropriate if both of these conditions are true:
  • The exchange cannot, or does not want to, expose EVM addresses for existing native wallets directly.
  • The exchange is willing to operate the migration itself.

​
3) User-directed forwarding contract

The exchange notifies customers of the change and directs them to the FundsForwarder contract address. Customers start the transfer themselves. This action triggers the contract, which forwards the funds automatically to the appropriate EVM wallet on the exchange. This option is functionally similar to option 2, but the customer performs the trigger action. It is appropriate when the exchange cannot operate the contract directly but wants to offer an automated destination.

​
4) Fully manual transfer

The exchange notifies customers of the change and asks them to move their funds manually. Customers withdraw the funds to a self-custodial wallet and then redeposit them to the EVM address that the exchange gives them.

​
Address association

The first two options require the exchange’s native and EVM addresses to be associated on-chain. Association is the explicit on-chain link between a sei1... address and its corresponding 0x... address. Without it, the chain cannot recognize that the two addresses belong to the same account. After support for CosmWasm is deprecated, funds held under the native address will not be accessible through EVM.
Complete address association before deprecation. After that point, there is no mechanism to associate addresses.
For details on how to query association status and how to associate addresses, see Accounts.

​
FundsForwarder contract

The FundsForwarder is a one-way smart contract. It accepts deposits at a native (sei1...) address and forwards the full balance to a pre-configured EVM (0x...) destination address. It is the underlying mechanism for options 2 and 3 above. Key properties:
  • The destination address is fixed at deployment and cannot be changed. Funds can be forwarded only to that address.
  • The contract accepts deposits through native sei1... transfers and forwards the full balance to the configured 0x... destination.
  • OtterSec audited the FundsForwarder.

​
Migration milestone

Proposals #116, #120, and #121 have already disabled IBC in both directions. Address association must still be completed before the remaining Cosmos and CosmWasm functionality is deprecated. The deprecation is scheduled for June 15, 2026. After deprecation:
  • Exchanges and their users will not be able to access or transfer funds.
  • Cosmos-native transaction interfaces will no longer be available. Exchanges will not be able to broadcast Cosmos-format transactions or sign with Cosmos key derivations against the live chain. They also will not be able to interact with the chain through Cosmos RPC endpoints.
  • Address associations can no longer be created through a Cosmos wallet.
  • The FundsForwarder pattern will no longer work for new deposits.

​
Support

For technical questions about exchange migration, contact the Sei Labs team through the Sei Tech Chat or Discord.