Sei v2 - The First Parallelized EVM Blockchain

Last Updated 09/09/2025.

An additional technical note exploring further detail can be found here on the Sei Docs

In this post, Sei Labs introduced and proposed an upgrade to Sei: v2 - the first parallelized EVM.

Sei v2 took the proven advantages of Sei and made them accessible to a global base of EVM developers. This allows Sei to get the best of Solana and Ethereum - a hyper optimized execution layer that benefits from the tooling and mindshare around the EVM.

Nontechnical summary

Sei previously allowed for Cosmwasm smart contracts, which were written in Rust. As Sei continues to garner more developer interest, the biggest request from developers has been additional flexibility in the execution environments that Sei supports. In particular, EVM support is top of mind for many developers. 

As a result, we proposed Sei V2: Sei’s first major upgrade to become the first fully parallelized EVM. This upgrade resulted in Sei having the following functionality:

• Backwards compatibility of EVM smart contracts - allowing developers to deploy audited smart contracts from EVM compatible blockchains with no code changes 
• Reusability of familiar and widely used applications and tooling such as Metamask
• Optimistic parallelization - allowing the chain to support parallelization without requiring developers to define any dependencies
• SeiDB - improvements to the storage layer to prevent state bloat, improve state read/write performance, and make it easier for new nodes to state sync and catch up
• Interoperability with the existing chain, allowing for seamless composability between EVM and any other execution environments supported on Sei.

From a performance perspective, Sei V2 offers up to 100 megagas per second of throughput, with 400 ms block times and instant finality. This allows Sei to support many more users and far more interactive experiences than existing blockchains, while offering far cheaper per-transaction costs.

Sei V2 went live in May 2024, and has experienced explosive growth: Sei V2 daily active users skyrocketed to over 1 million on Aug 9th, 2025;  transaction volume surged to 32.49M daily on June 24, 2025; and TVL grew from $100M to a recent peak of $687M on Aug 17th, 2025. 

How it works

Sei is composed of different software components that all work with each other to support the blockchain. Some of these components are tied to the consensus layer, and others are tied to the execution layer. 

Sei V2 changed the way the execution layer works to support optimistic parallelization and optimized state storage. Additionally, it also creates a new component to support EVM smart contracts. These EVM smart contracts will benefit from all of the changes made to consensus and parallelization, and also be able to interact with existing Cosmwasm smart contracts.

Backwards compatibility

Rather than requiring developers to completely rewrite their smart contracts to deploy on Sei, Sei V2 is built with backwards compatibility in mind. This means that every major contract that exists on Ethereum can seamlessly be redeployed on Sei with no code changes required [2]  

From a technical perspective, as part of the Sei chain binary, Sei nodes automatically import Geth, a Go implementation of the Ethereum Virtual Machine. Geth is used to process ethereum transactions, and any resulting updates (state updates, or invocations of non-EVM related contracts) are made with a special interface that Sei has created for the EVM. 

This approach allows for full bytecode compatibility, allowing for anything that can run with Geth to be processed easily by Sei. Additionally, since the RPC interface will be identical for Sei as EVM, existing tooling from Ethereum can be seamlessly reused. For example, users can use Metamask by just switching the RPC they’re connected to, and developers can use tooling such as Foundry, Remix, and Hardhat.

Optimistic parallelization

Sei V2 removes the need for developers to define state access themselves. Instead, the chain optimistically runs all transactions in parallel. Whenever there are conflicts (transactions touching the same state), the chain tracks what parts of storage each transaction is touching. Transactions touching different parts of storage are rerun in parallel, and transactions touching the same state are rerun sequentially. This recursively continues until there are no more conflicts that are unaccounted for. Since the transactions are ordered in a block, this is a deterministic process that eases the developer workflow while maintaining parallelization at the chain level.

Optimistic parallelization applies to all transactions that are run on Sei, including Sei native transactions, Cosmwasm transactions, and EVM transactions. More details about the technical implementation can be found here. 

SeiDB

Previously, Sei used a vanilla database layer which is composed of an IAVL tree data structure. This data structure was less efficient from both a storage and latency perspective because of its schema and additional metadata, leading to greater write amplification and slower disk access.

Sei has re-architectured the storage interface to optimize for different use cases. Sei has done this by breaking the single IAVL tree into 2 components - state store and state commitment (motivation). The state store layer provides low latency direct access to raw key-value pairs which helps RPC nodes better serve queries. Storing historical data as raw key-value pairs removes the overhead of redundant metadata and helps reduce the disk usage by orders of magnitude. The state store also uses a write-ahead log to help with recovery in the event of a crash. The state commitment layer uses a highly optimized in-memory IAVL tree that is responsible for committing data which helps validators reach consensus even faster since the amount of disk access is reduced.

In addition to this change, rigorous benchmarking was done on various industry leading databases, and Sei V2 moved towards using PebbleDB instead of GoLevelDB, which results in substantially improved read/write performance for multi-threaded access. 

More details about the technical implementation can be found here. 

Interoperability

Because Sei is an integrated chain, all transactions going to different components of Sei (Cosmwasm, EVM, bank, staking) are able to communicate with each other. Although these transactions serve different purposes, they ultimately have many similar features such as gas, sender, and transaction body. When the chain receives these transactions, they are processed as Sei native transactions and are forwarded to appropriate sections of storage (i.e. CosmWasm transactions are sent to the wasm module and executed). This leads to a more seamless developer experience - EVM developers can easily access native tokens and other chain features such as staking. 

Performance metrics

Initial performance numbers for SeiDB and optimistic parallelization are indicating the following performance:

These tests were performed in a twenty node cluster that was equally split across Ohio, California, Frankfurt, and Ireland. Each node was an AWS 8xlarge, with 32 cores and 64GB RAM.

Conclusion

This proposal outlined a route for Sei to support and supercharge multiple virtual machines, starting with the first parallelized EVM.

Applications currently built on any EVM chain are now able to deploy on Sei to support many more users and far more ‘web-2’ like interactive experiences than on existing blockchains.

Furthermore they can offer far cheaper per-transaction costs, higher throughput and suffer from none of the centralization tradeoffs, complexity or the overhead of operating an Ethereum L2 rollup.

Sei is making the EVM simple again.

An additional technical note exploring further detail can be found here on the Sei docs - contributions, questions and thoughts are welcomed.

Footnotes

[1] This figure represents activity, and not the maximum threshold of transactions that Sei can handle.

[2] The biggest difference between Ethereum L1 and Sei V2 is way that state is stored - Ethereum uses a Patricia Merkle Tree, whereas Sei uses an IAVL tree, so anything that requires a state proof will need to be rewritten.