Skip to main content
Sei has full EVM compatibility, but Sei EVM and Ethereum differ in some ways:
  • Sei uses the Pectra (Prague and Electra) version of the EVM, without blob transactions. Ethereum has since upgraded to Fusaka (December 2025). Fusaka introduced PeerDAS to improve data availability.
  • Sei’s gas limit is 12.5 M, compared with 60 M on Ethereum. The Fusaka upgrade increased Ethereum’s limit from 45 M through EIP-7935. Sei also has a byte size limit of 21 MB.
  • Sei has instant finality. A transaction is final as soon as its block is committed (approximately 400 ms). As a result, the commitment levels typical for Ethereum (safe, latest, and justified) do not apply on Sei.
Deprecation noticeCosmos SDK and CosmWasm functionality is being deprecated in favor of EVM-only. For more details, see SIP-3 and Proposal 99.Proposal 115 also disables CosmWasm code uploads and contract instantiations chain-wide. As a result, you cannot deploy new CosmWasm contracts. Only execute and query against existing CosmWasm contracts remain available.
  • Sei is a dual-execution environment (EVM and Cosmos SDK). This means that:
    • Non-EVM transactions can update EVM-accessible state.
      • For example, both Cosmos transactions (bank send, wasm execute) and EVM send transactions can change an account’s SEI balance.
    • Sei assets can exist as EVM tokens (ERC-20, ERC-721, and ERC-1155) or as legacy CosmWasm tokens (CW20, CW721, and CW1155). They can also exist as “native” Bank Module assets (Sei). Under Proposal 115, you can no longer deploy CosmWasm tokens.
    • User accounts on Sei have two addresses derived from the same public key (Cosmos Bech32 and EVM-compatible 0x…).
    • Interoperability between EVM and Cosmos SDK modules works through precompiles and pointer contracts.

​
Sei EVM release

Sei EVM was first deployed at these block heights and versions:

​
Testnet

​
Mainnet

​
Opcode differences

​
PREVRANDAO

Proof of Stake (PoS) Ethereum uses pseudo‑randomness to determine the next validator. Sei does not rely on the same method, so it does not have the “randomness” artifact that can be set as PREVRANDAO’s return value. On Sei, PREVRANDAO returns a value derived from the current block time. If your contract logic needs strong randomness, use a verifiable randomness oracle. This is also the advice for Ethereum.

​
COINBASE

On Sei, the coinbase address is always the EVM address of the global fee collector.

​
State root

Sei uses an AVL tree instead of a Merkle Patricia Trie (MPT) for data storage. Because of this, Sei does not have a per-account state root. The global state root is the AVL-tree root. It is also not equivalent to Ethereum’s overall state root, which is an MPT root.

​
Block hash

Sei computes the block hash from the block header in Tendermint data format. As a result, it is different from Ethereum’s block hash.

​
Base fee & tips

Sei supports all non‑blob transaction types, including the Pectra SetCode transaction (EIP‑7702). However, for a legacy (non EIP‑1559) transaction, you must specify a gas price at or above Sei’s governance-set minimum gas price. The minimum is currently 50 gwei on Sei Mainnet. Query the live value with eth_gasPrice instead of hard-coding it. Also, excess “gas wanted/gas limit” beyond the actual “gas used” may not be refunded in full or in part. You can fetch the current EIP-1559 parameters with seid:

​
Non-EVM transactions

On Sei, non-EVM transactions may update state that EVM transactions can access. The simplest example is bank balances. Both native Cosmos bank send transactions and EVM send transactions may update them. As a result, an offchain application that parses only EVM transactions may find state changes that it cannot attribute to any EVM transaction.

​
EVM transaction envelope restrictions

On Sei, EVM transactions are carried inside a Cosmos transaction envelope. That envelope must not contain any Cosmos-specific fields. Tooling that builds raw transactions should know about these Sei-specific differences from a plain Ethereum transaction:

​
No Cosmos wrapper fields on EVM transactions

An EVM transaction must not populate any of the Cosmos wrapper fields. If any of these fields are set, Sei rejects the transaction:
  • memo
  • timeout_height
  • extension options (extension_options / non_critical_extension_options)
  • signer_infos
  • fee amount, fee payer, and fee granter
  • top-level signatures
The EVM transaction’s own signature (v, r, s) is inside the EVM payload itself, so the transaction does not need any of these Cosmos-level fields. Sei applies this check uniformly to all EVM transactions.

​
Whole-block rejection on transaction decode failure

During proposal processing, Sei decodes every transaction in a proposed block. If any transaction fails to decode or panics during decode, Sei rejects the entire block proposal. It does not silently skip the offending transaction (treat it as nil) and continue with the rest of the block. This also affects block gas accounting. A transaction that could not be decoded no longer contributes zero gas and gets skipped. Instead, its presence causes Sei to reject the block proposal outright.
Make sure that your signing and broadcast tooling submits only transactions that decode cleanly. This is a consensus-level behavior change. A single undecodable transaction now invalidates the whole proposal. Tooling that produces malformed or non-canonical transactions can no longer rely on Sei to drop them individually from an otherwise-valid block.

​
Rejection of bloated (non-canonical) transaction bodies

The transaction decoder rejects “bloated” transaction bodies. A bloated body has a raw protobuf wire encoding that is larger than the canonical re-marshal of the decoded body. The decoder rejects non-canonical encodings (for example, padded fields or an oversized Any.Value) with a decode error. This check has been enforced since v6.5.0.
Make sure that your transaction-signing tooling produces a minimal, canonical envelope with no Cosmos wrapper fields populated.

​
Finality

Sei has instant finality. A transaction is final as soon as its block is committed (approximately 400 ms). This means that Ethereum’s commitment levels “safe”, “latest”, “justified”, and “finalized” are all the same on Sei.

​
Pending state

On Ethereum, the block proposer executes its proposed block first and updates its local state. Then it broadcasts the proposal to others. The updated state is marked “pending” until the node is accepted by other nodes. However, on Sei, the block proposer broadcasts the proposal first. It executes the proposal only if the proposal is accepted. This means that every node executes the block at roughly the same time, so Sei does not have a window when a “pending state” exists.

​
Gas model & fees

Sei does not burn the base fee. All transaction fees go to validators. Fees are calculated as: Transaction Fee = Gas Used × Gas Price Practical implications
  • Fee handling is simpler: use gasPrice, and you can omit maxFeePerGas and maxPriorityFeePerGas.
  • Fees are more stable, because higher throughput reduces fee spikes during busy periods.
  • Costs are typically lower. Many workloads that are costly on Ethereum become economical on Sei.
  • Does Sei burn a base fee (EIP‑1559)? No.
  • Who receives fees? Validators.
  • Are Sei fees lower? Yes, because of higher throughput and parallel execution.

​
SSTORE gas cost

On Sei, the gas cost of the SSTORE opcode is a configurable on-chain parameter. A governance proposal can adjust it without a chain upgrade. This lets governance tune storage costs based on EVM state size and network conditions. The SSTORE gas cost is currently set to the non-standard value of 72,000 gas. This value is the same on Sei Mainnet and Sei Testnet. Governance Proposal #109 (“Update EVM SSTORE set gas to 72000”) set this value. The proposal changed the evm module parameter KeySeiSstoreSetGasEIP2200 to 72000. The values below are read live from the Sei EVM: To confirm the real cost yourself, make a live eth_estimateGas call against a Sei RPC. A Foundry forge test --gas-report --fork-url <sei rpc> report forks the chain state, but it applies revm’s standard EVM gas schedule. As a result, it reports the Ethereum cost (approximately 22,100) instead of the Sei cost. The report is useful for relative profiling of your own logic, but not for the absolute storage-write cost.
Because the SSTORE gas cost is a governance-controlled parameter, a governance proposal may change this value in the future.

​
ERC token standards compatibility

Sei EVM fully supports the common token standards:
  • ERC‑20 (fungible tokens)
  • ERC‑721 (NFTs)
  • ERC‑1155 (multi‑token)
Existing OpenZeppelin contracts and tools work unchanged.

​
Testing & migration checklist

  • Redeploy your Solidity code to Sei Testnet. Most contracts do not need changes.
  • If you used SELFDESTRUCT, refactor it to a soft‑close pattern.
  • Remove the EIP‑1559 fee complexity from your UI. Use a single gasPrice input in frontends.
  • If you rely on on‑chain “randomness,” integrate an oracle or VRF.
  • Size your gasLimit with a modest buffer. Parallel execution can make estimates vary slightly.