Sei Explained: Parallel EVM, Upgrade Dates and Performance Claims - Blockchain808

Sei makes a useful case study in parallel execution: which transactions can run together, what happens when they compete for the same state, and how should a reader interpret the resulting performance claims?

Intermediate · reviewed 24 October 2026. Follow the short explanation first. The optional sections add a calculation and a method for reading network statistics.

Why bring the EVM to a faster execution design?

Sei is a Layer 1 blockchain. Its v2 work brought Ethereum-compatible execution and familiar developer tools into a system designed to process more work concurrently. The engineering question is how to improve execution while retaining a consistent result when transactions depend on each other.

The v2 design account describes optimistic parallelization: attempt concurrent execution, detect conflicting state access, and rerun affected work according to the block's order. It also describes SeiDB storage changes. Faster execution and faster state access address different parts of the workload; neither alone determines the whole user's waiting time.

The development sequence

1. November 2023 — design proposal. The v2 announcement set out EVM support, parallel execution and storage changes. Its page was subsequently updated, so the publication date does not date every statement on it.
2. May–July 2024 — staged rollout. The rollout account separates governance, the upgrade/infrastructure phase and readiness. The 9 July announcement made the Parallel EVM mainnet beta available to everyone.
3. May 2025–June 2026 — Giga research revisions. The Giga paper's version history records its initial submission and the third revision dated 29 June 2026. Research publication, benchmark results and public-network deployment are separate milestones.

Read this sequence as an evolution of design and rollout, not as a price narrative. A 2025 activity chart, for example, comes after the 2024 EVM opening. Explaining later adoption requires evidence about applications, users and conditions during that later period.

One ticket, two buyers: a conflict you can follow

Imagine a contract selling its last ticket. Mina and Jae each submit a purchase. A third transaction moves tokens between two unrelated accounts. The block orders Mina's purchase before Jae's.

1. Both purchase attempts may initially read “one ticket remaining” during speculative work.
2. Mina's successful purchase changes the inventory to zero.
3. Jae's result cannot be accepted on the stale assumption that one ticket remains. His transaction must be evaluated against the state required by the agreed order; in this example it fails the sold-out check.
4. The unrelated transfer may offer useful parallel work if it has no conflicting reads or writes.

This is an author-created illustration of a dependency, not a reproduced Sei trace. Parallel execution must not sell two tickets from one item of inventory. The speed benefit depends on how much work is independent and how much must be revisited. A busy shared pool can therefore behave differently from many unrelated transfers.

Go deeper: count useful work, not attempted work

Suppose a benchmark submits 12,000 requests over 30 seconds, but only 9,000 successfully commit in that interval. The submission rate is 400 requests/second; successful committed throughput is 300 transactions/second. The difference needs an explanation: pending work, rejected requests or execution failures are not interchangeable. This is an invented measurement exercise, not a Sei performance result.

Record latency as well as throughput. A high total can coexist with a long wait for a particular transaction, especially if contention creates retries.

What the Giga result says—and what to measure next

The authors' June 2026 v3 abstract reports more than five gigagas per second and sub-250-millisecond finality on an internal testnet. It describes separating data availability and consensus, with asynchronous execution and state agreement. This is a version-specific, author-reported research result; this article does not certify its public-mainnet deployment or reproduce the benchmark.

Gas measures work under a gas schedule; TPS counts transactions. For a purely arithmetic illustration, 5,000,000,000 gas/second divided by 100,000 gas/transaction is 50,000 transactions/second. At 500,000 gas/transaction it is 10,000. Neither conversion is a measured TPS claim: workload, hardware and execution overhead also matter.

A useful follow-up measurement would fix the software version and hardware, compare independent transfers with a shared-state workload, and report successful throughput plus the distribution of completion times. That would reveal more about an application's experience than a single maximum.

What EVM compatibility gives a reader

Compatibility makes existing Solidity knowledge and EVM tooling relevant. It does not mean a deployment uses Ethereum's validator set, shares all other apps' liquidity or has identical state-proof behavior. Contract logic, deployment configuration and the destination chain still need to be understood.

For learners, the useful connection is to other concurrency designs: compare this ticket example with Aptos and Block-STM, then ask what each system does when two operations depend on the same state.

Optional: interpret activity without confusing it with adoption

• Addresses: count active addresses over a named period, but do not assume each is a distinct person.
• Transactions: distinguish submissions, successful transactions and repeated automated actions.
• Fees: specify currency, period and which network or application receives them.
• TVL: separate asset-price changes from deposits and withdrawals.
• Applications: distinguish an announced integration from a deployed product with returning users.

Combining these measures can test an adoption hypothesis. None by itself establishes token-holder returns.

Check your understanding

Two purchases both initially see one ticket. Does parallel execution mean both should succeed? Does the date of a Giga paper revision prove when that design became active on mainnet?

Show the answer

No to both. The final result must respect the ordered state changes, and a research revision dates the document. Deployment needs separate evidence such as an activated upgrade and the relevant network/software version.

Continue learning: Compare Aptos's execution approach · Compare Cardano's eUTXO state model.

Revision history and scope

Updated 19 October 2026. Corrected the EVM rollout date and separated published design claims from measured network activity. Earlier price, fee-ranking and adoption figures without reproducible sources have been removed.

24 October 2026: Moved the earlier correction note below the lesson and added a reader-focused introduction. This is a presentation edit; the earlier factual review date is unchanged.

Earlier corrections retained: the unsupported GameStop origin story, universal shared-liquidity assertion, and undated price, fee-leadership, ecosystem-fund and wallet-growth claims were withdrawn. EVM public availability belongs to the 2024 rollout, not a first launch in 2025. The previous Giga discussion referred to an older paper result; the body now identifies v3 explicitly.

24 October 2026 — substantive update: Reorganized the body around development history and a worked transaction-conflict example. Consolidated correction commentary here. Updated the Giga citation to the June 2026 v3 paper and its author-reported internal-testnet result; this is not a mainnet benchmark.