What is Sei EVM? SIP-3 and the EVM Transition Explained

The short version

• Sei was originally a hybrid chain — Cosmos (CosmWasm) and Ethereum (EVM) smart contracts ran side by side.
• SIP-3 removes the Cosmos side, leaving only the EVM. The community approved this in May 2025; the changes are rolling out through 2026.
• Why: simplifying to one virtual machine lets Sei focus performance work on a single execution layer. The end goal is the Sei Giga upgrade — 200,000+ TPS while keeping sub-400ms finality.
• What you need to do: if you have SEI at a Cosmos legacy sei1 address, migrate to an EVM 0x address before the final cutover. If you're already on 0x, no action needed.

What "EVM" means in plain English

EVM stands for Ethereum Virtual Machine — the runtime that executes Ethereum smart contracts. When a chain is "EVM-compatible", it means smart contracts written for Ethereum work on that chain without rewriting. For users that means familiar 0x addresses, Ledger (Ethereum app) support, MetaMask/Rabby connections via custom RPC, and Solidity dApps redeployed with minimal changes. For developers that means lower switching cost — same Solidity, same workflow.

What Sei looked like before SIP-3

When Sei mainnet launched in August 2023, it was a Cosmos SDK chain with native Tendermint consensus. Smart contracts ran in CosmWasm (Cosmos's smart contract environment, which uses Rust). User wallets had sei1 addresses — the Cosmos bech32 format. In late 2023, Sei added EVM compatibility (Sei V2) through a parallelized execution layer. After Sei V2, both CosmWasm and EVM contracts ran on the same chain. Wallets started supporting both sei1 and 0x addresses.

This dual-VM design had benefits — Cosmos-native composability plus Ethereum tooling — but also costs. Maintaining two execution environments meant doubling testing surface area for every protocol upgrade. Wallet UX fragmented between two address formats. Developers had to choose which VM to target.

What SIP-3 changes

1. CosmWasm contracts are deprecated. Existing CosmWasm contracts continue to run during transition. New CosmWasm contracts cannot be deployed.
2. IBC bridging is being disabled. v6.4 (mid-April 2026) shipped the technical capability to disable inbound IBC. Activation requires a separate governance proposal — pending as of mid-2026.
3. Native Cosmos transactions become read-only. After the final cutover, all transactions must originate from EVM (0x) addresses.
4. The native oracle is being replaced by external providers (Chainlink, API3, Pyth) — already removed from the codebase in v6.5.

The rollout timeline

As of mid-2026, the transition is still in progress. v6.4 shipped the IBC-disable mechanism but the actual governance proposal has not yet been voted in. The final cutover date is targeted at mid-2026; the specific date will be announced via Sei governance channels. For the latest status, see sei.io/blog or docs.sei.io.

What does this mean for me?

If you only ever held SEI at a 0x address

You're fine. Your address format is the one that survives. No action required.

If you held SEI at a sei1 address before SIP-3

You need to migrate. Use a wallet that supports both formats (Sei Wallet, Keplr), generate a 0x address from the same seed, then use the address-association tool to link sei1 and 0x on-chain. Step-by-step: /migration and /learn/sei-addresses.

If you held IBC-bridged tokens on Sei

Bridge OUT before IBC is disabled (governance vote pending). USDC.n → convert to native USDC via Circle CCTP V2. ATOM → bridge back to Cosmos Hub via Skip:Go. Wormhole-bridged WETH/USDCet/USDCop → bridge back via Wormhole. Kava USDT → bridge or swap.

What stays the same

• The SEI token itself — same token, same supply, same staking, same governance.
• Validators — same set continues; staking keeps working through the v6.3 EVM-native staking module.
• Sub-400ms finality.
• EVM-side dApp continuity.