Sei EVM vs Ethereum: Key Differences

A comparison of Sei EVM and Ethereum, highlighting Sei’s advantages in blocktime, throughput, finality, and execution environment, as well as technical differences in opcodes, state storage, and other features.

While Sei features full EVM compatibility, there are some distinctions between Sei’s EVM and Ethereum itself:

Feature	Sei EVM	Ethereum
Blocktime	400 ms	12 s
Gas per Second	~ 100 MegaGas/s	~ 5 MegaGas/s
Finality	Instant (~400 ms)	Various commitment levels (safe, latest, justified, finalized)
Parallelized Execution	Yes	No
EVM Tooling Compatibility	100%	100%
EVM Version	Pectra (w/o blobs)	Fusaka
Gas Limit	12.5 M (block cap)	60 M (block); ~16.7 M per-tx (EIP-7825)
Per-Tx Gas Cap	12.5 M (block limit)	~16.7 M (EIP-7825)
Byte Size Limit	21 MB	No byte-denominated limits
Execution Environment	EVM and Cosmos-SDK	EVM
Address Space	Dual ECDSA-derived addresses; Cosmos Bech32 (sei…) + EVM-compatible address (0x…)	ECDSA-derived address (0x…)
State Storage	AVL-tree (global root)	Merkle Patricia Trie (MPT)
SSTORE Gas Cost	72k (on-chain param, governance-adjustable)	20k (fixed)

• Sei uses the Pectra (Prague + Electra) version of EVM, excluding blob transactions. Ethereum has since upgraded to Fusaka (December 2025), which introduced PeerDAS for enhanced data availability.
• Sei’s gas limit is 12.5 M as opposed to Ethereum’s 60 M (increased from 45 M in the Fusaka upgrade via EIP-7935). Sei also has a byte size limit of 21MB.
• Sei has instant finality — a transaction is final as soon as its block is committed (~400 ms). This means the various commitment levels typical for Ethereum (i.e., safe, latest, justified) do not apply on Sei.

Deprecation Notice

Cosmos SDK and CosmWasm functionality is being deprecated in favor of EVM-only. For more details, see SIP-3 and Proposal 99.

Proposal 115 further disables CosmWasm code uploads and contract instantiations chain-wide — no new CosmWasm contracts can be deployed. Only execute and query against pre-existing CosmWasm contracts remain available.

• Sei is a dual-execution environment (EVM and Cosmos-SDK). This means:
  • Non-EVM transactions can update EVM-accessible state.
    • For example, an account’s SEI balance can be affected by both Cosmos (bank send, wasm execute) transactions as well as EVM send transactions
  • Sei assets can exist as EVM tokens (ERC20/721/1155), as legacy CosmWasm tokens (CW20/CW721/CW1155, no longer deployable per Prop 115), or as “native” Bank Module assets (Sei).
  • 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 is governed and navigated via precompiles and pointer contracts

Sei EVM Release

Sei EVM was originally deployed at the following block heights and versions:

Testnet

• Name: v5.5.1
• Height: 90526031
• Changelog: https://github.com/sei-protocol/sei-chain/blob/main/CHANGELOG.md#v5.5.1

Mainnet

• Name: v5.5.2
• Height: 79123881
• Changelog: https://github.com/sei-protocol/sei-chain/blob/main/CHANGELOG.md#v552

Opcode Differences

Opcode	Sei EVM	Ethereum	Notes
PREVRANDAO	Returns a value derived from the current block time	Returns the RANDAO mix (EIP‑4399)	Not a randomness source; use an oracle/VRF. DIFFICULTY aliases to this.
COINBASE	Always the global fee collector address	Block proposer (miner) address	Do not assume it is the validator address.
BASEFEE	Returns current base fee; no burn	Returns current base fee; a portion is burned (EIP‑1559)	Legacy tx must meet Sei’s governance-set minimum gas price (currently 50 gwei); query eth_gasPrice for the live value.
BLOCKHASH	Hash of the Tendermint header; different encoding	Keccak of the Ethereum block header	Usable for recent blocks only; values are not interchangeable across chains.
GASLIMIT	= 12,500,000 per block	= 60,000,000 per block	Represents block gas limit in both chains.
TIMESTAMP	Tendermint block time	Proposer-chosen block time	Same semantics; do not use as randomness.
DIFFICULTY	Alias of PREVRANDAO	Alias of PREVRANDAO (EIP‑4399)	Returns the same value as PREVRANDAO.
Blob‑related opcodes	Not supported (Pectra without blobs)	Supported post‑Cancun (EIP‑4844)	Blob transactions are not enabled on Sei.

PREVRANDAO

Since Sei doesn’t rely on the same pseudo‑randomness way of determining the next validator like Proof of Stake (PoS) Ethereum does, it doesn’t 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. For strong randomness needs in contract logic, use a verifiable randomness oracle (as is advised on Ethereum itself).

COINBASE

Coinbase address on Sei is always set to (the EVM address of) the global fee collector.

State Root

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

Block Hash

The block hash on Sei is computed based on the block header in Tendermint data format, and is different from Ethereum’s block Hash as a result.

Base Fee & Tips

Sei supports all non‑blob transaction types, including the Pectra SetCode transaction (EIP‑7702). However for a legacy (non EIP‑1559) type transaction, you must specify a gas price at or above Sei’s governance-set minimum gas price (currently 50 gwei on mainnet). Query the live value with eth_gasPrice rather than hard-coding it. In addition to this, excess “gas wanted/gas limit” beyond the actual “gas used” may not be refunded in full or in part.

Current EIP1559 parameters can be fetched from the seid SDK tool:

seid q params subspace evm KeyTargetGasUsedPerBlock

key: KeyTargetGasUsedPerBlock
subspace: evm
value: '"850000"'

seid q params subspace evm KeyMaxDynamicBaseFeeUpwardAdjustment

key: KeyMaxDynamicBaseFeeUpwardAdjustment
subspace: evm
value: '"0.007500000000000000"'

Non-EVM Transactions

On Sei there exists non-EVM transactions which may update states accessible by EVM transactions. The simplest example would be bank balances, which may be updated by both native Cosmos bank send transactions and EVM send transactions. As a result, if certain offchain applications only parse EVM transactions, they may find certain state changes unattributable to any EVM transaction.

EVM Transaction Envelope Restrictions

On Sei, EVM transactions are carried inside a Cosmos transaction envelope, but that envelope must remain empty of Cosmos-specific fields. This introduces the following Sei-specific divergences from a plain Ethereum transaction that tooling constructing raw transactions should be aware of:

No Cosmos wrapper fields on EVM transactions

An EVM transaction must not populate any of the Cosmos wrapper fields. If any of the following are set, the transaction is rejected:

• 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) lives inside the EVM payload itself, so none of these Cosmos-level fields are needed. This check is applied 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 — the entire block proposal is rejected rather than the offending transaction being silently skipped (treated as nil) while the rest of the block proceeds.

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 the block proposal to be rejected outright.

This is a consensus-level behavior change. Tooling that produces malformed or non-canonical transactions can no longer rely on such transactions being individually dropped from an otherwise-valid block — a single undecodable transaction now invalidates the whole proposal. Ensure your signing and broadcast tooling only submits transactions that decode cleanly.

Rejection of bloated (non-canonical) transaction bodies

The transaction decoder rejects “bloated” transaction bodies — those whose raw protobuf wire encoding is larger than the canonical re-marshal of the decoded body. Non-canonical encodings (for example, padded fields or an oversized Any.Value) are rejected on decode with a decode error. This check has been enforced since v6.5.0.

Ensure 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 (~400 ms) — meaning that commitment levels of “safe”, “latest”, “justified”, and “finalized” on Ethereum are all the same thing on Sei.

Pending State

On Ethereum the block proposer would execute its proposed block first (and update its local state) before broadcasting the proposal to others (the updated state would be marked “pending” until the node is accepted by other nodes).

However, on Sei, the block proposer would broadcast first and only execute the proposal if it’s accepted (i.e. every node would execute the block at roughly the same time), so Sei does not have a window when “pending state” exists.

Gas Model & Fees

Sei does not implement base‑fee burning. There is no base‑fee burn; all transaction fees accrue to validators. Fees are calculated as:

Transaction Fee = Gas Used × Gas Price

Practical implications

• Simpler fee handling: Use gasPrice (you can omit maxFeePerGas / maxPriorityFeePerGas).
• More stable fees: Higher throughput reduces fee spikes during busy periods.
• Typically lower cost: Many workloads that are costly on Ethereum become economical on Sei.

Useful Infos

• Does Sei burn a base fee (EIP‑1559)? No.
• Who receives fees? Validators.
• Are Sei fees lower? Yes, due to higher throughput and parallel execution.

SSTORE Gas Cost

On Sei, the SSTORE opcode gas cost is configurable as an on-chain parameter, meaning it can be adjusted via governance proposal without requiring a chain upgrade. This provides flexibility to tune storage costs based on EVM state size and network conditions.

Currently, the SSTORE gas cost is set to the non-standard value of 72,000 gas. This value is the same on both mainnet (pacific-1) and testnet (atlantic-2). It was set by governance Proposal #109 (“Update EVM SSTORE set gas to 72000”), which changed the evm module parameter KeySeiSstoreSetGasEIP2200 to 72000.

The values below are read live from the Sei EVM:

To confirm the real cost yourself, use a live eth_estimateGas call against a Sei RPC. Note that a Foundry forge test --gas-report --fork-url <sei rpc> report forks chain state but applies revm’s standard EVM gas schedule, so it reports the Ethereum cost (~22,100) rather than Sei’s — it is useful for relative profiling of your own logic, not for the absolute storage-write cost.

Since SSTORE is a governance-controlled parameter, this value may change in the future through a governance proposal.

ERC Token Standards Compatibility

Sei’s 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

• ✅ Re‑deploy your Solidity code to Sei testnet; most contracts need no changes.
• ✅ If you used SELFDESTRUCT, refactor to a soft‑close pattern.
• ✅ Remove EIP‑1559 fee UI complexity; use a single gasPrice input in frontends.
• ✅ If you rely on on‑chain “randomness,” integrate an oracle/VRF.
• ✅ Size your gasLimit with a modest buffer (parallel execution can slightly vary estimates).