Divergence from Ethereum
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 | ~ 3 MegaGas/s |
Finality | Instant | Various commitment levels (safe, latest, justified, finalized) |
Parallelized Execution | Yes | No |
EVM Tooling Compatibility | 100% | 100% |
EVM Version | Cancun (w/o blobs) | Cancun |
Gas Limit | 10 M | 45 M |
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) |
-
Sei uses the Cancun version of EVM, excluding the blob transactions.
-
Sei’s gas limit is 10 M as opposed to Ethereum’s 45 M. Sei also has a byte size limit of 21MB.
-
Sei has instant finality. This means the various commitment levels typical for Ethereum (i.e., safe, latest, justified) do not apply on Sei.
-
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 not only exist as EVM (i.e., ERC20/721/1155), but also as CW (i.e., CW20, CW721) or as “native” (Sei, IBC, Tokenfactory).
- User accounts on Sei have two addresses derived from the same public key (Cosmos Bech32 and EVM-compatible 0x…)
- Non-EVM transactions can update EVM-accessible state.
Interoperability between EVM and Cosmos-SDK modules is governed and navigated via precompiles and pointer contracts
Sei EVM Deployment
Sei EVM was 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 dynamic base fee; no burn | Returns current base fee; a portion is burned (EIP‑1559) | Legacy tx must specify ≥ 1 gwei base fee on Sei. |
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 | = 10,000,000 per block | ≈ 45,000,000 | 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 (Cancun 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 really 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 transaction types. However for a legacy (non EIP1559) type transaction, you must specify a base fee of 1gwei. 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"'
root@ip-172-31-4-247:/home/ubuntu# 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.
Finality
Sei has instant finality, 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 really 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 omitmaxFeePerGas
/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.
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).