What Is Sei Giga?

Sei Giga will be the next generation of the Sei protocol following the Giga Upgrade, designed to be the first Multi-Proposer EVM Layer 1. Every validator will propose transactions at the same time, consensus will finalize only the order of those transactions, and execution and state attestation will happen afterwards, off the critical path. On an internal devnet of 40 nodes across 20 regions, Giga sustained more than 5 gigagas per second (5 billion gas per second) with ordering finality under 250 ms. The separate public-testnet roadmap target is 200,000 TPS. Giga will ship as a series of in-place upgrades to the live Sei network rather than as a new chain.

​

Sei Giga at a glance

​

Why does Sei Giga exist?

Giga’s design goal is efficient, fast, and fair on-chain trading, a workload that needs very high throughput, low latency, and bounded censorship and MEV (maximal extractable value) risk. Sei Labs’ Giga announcement frames the gap: Ethereum mainnet processes on the order of 100 TPS, while comparable web2 systems handle around 100,000 complex transactions per second. Closing that gap on a single decentralized EVM chain means removing three bottlenecks that all single-proposer blockchains share:

1. One leader per block. In Tendermint-style consensus, a single proposer’s bandwidth and connectivity cap the whole network’s throughput each round. Giga will make every validator a proposer with its own data lane.
2. Consensus waits for execution. Traditional chains execute transactions and agree on the resulting state root inside the consensus loop, so heavy blocks slow finality. Giga will reach consensus on ordering only and execute asynchronously.
3. Merkle write amplification. Per-write Merkle tree updates multiply disk I/O as state grows. Giga will replace the hot-path Merkle tree with a flat key-value store and homomorphic lattice hashes.

Sei’s current architecture already pushed the single-proposer model near its limits: ~400 ms blocks, optimistic parallel execution, and SeiDB. Giga will replace the model instead of tuning it further.

​

How will Sei Giga work?

Giga is designed to separate the work of a blockchain into four decoupled stages: data dissemination, ordering, execution, and state attestation. Each stage is designed to run concurrently rather than blocking the next.

​

Autobahn consensus

Giga will order transactions with Autobahn, a Byzantine Fault Tolerant consensus protocol that separates data dissemination from ordering:

• Each validator will continuously stream batches of transactions (“cars”) into its own hash-chained lane, in parallel with every other validator.
• In the whitepaper’s replica-count model, a batch will be certified by a Proof of Availability (PoA) after f + 1 replica votes, which guarantees at least one honest holder under the stated assumptions. The implementation applies stake-weighted thresholds.
• Consensus will periodically commit a cut: a snapshot of the latest certified tip of every lane. Lanes are hash-chained, so committing a tip implicitly commits everything behind it, and one consensus decision can finalize many blocks of data at once.
• Pipelined slots are designed for an effective steady-state cadence of one committed cut per 1.5 network round trips, versus three full rounds for Tendermint. This is a throughput cadence rather than a submission-to-finality guarantee. Validators will vote on compact certificates instead of downloading full blocks first.

The whitepaper’s design goal is for dissemination throughput to scale with participating validator bandwidth instead of one leader’s connection. It reports more than 50 times Tendermint’s throughput in its evaluated setup while retaining the stated BFT assumptions. The full protocol and assumptions are in the consensus specification.

​

Asynchronous execution and state attestation

Giga will provide two distinct finality signals:

• Ordering finality: under the protocol’s stated fault and cryptographic assumptions, consensus has fixed the transaction order. This is the sub-250 ms signal, but execution follows it, so a receipt or execution result is not available at this stage.
• State attestation finality: validators have executed the block, computed a compact divergence digest over its write log, and a two-thirds voting-power quorum has attested to that digest in a later block.

Applications can inspect the execution result after a node produces the receipt. Whether receipt-level confirmation is sufficient depends on the application’s risk policy. High-value or cross-chain flows should wait for state attestation finality. Execution is designed to be deterministic: nodes that apply the same ordered transactions to the same starting state should compute the same result, while ordering continues as execution catches up. Divergence below one-third of voting power can be isolated; divergence beyond the Byzantine threshold is designed to pause the chain. Signing two different digests for the same block will be slashable equivocation.

​

Parallel execution

Once ordering is final, each block will execute across all CPU cores using optimistic concurrency control:

• All transactions in a block will start executing in parallel, buffering their writes privately.
• A validation phase will detect conflicts (a transaction read or wrote state that an earlier-ordered transaction wrote) and re-execute only the conflicting transactions.
• The committed result will be identical to sequential execution in block order, and under sustained contention the engine will fall back to sequential execution with unchanged semantics.

Sei Labs’ research found that 64.85% of historical Ethereum transactions could have been parallelized this way. Contract-level guidance for maximizing parallelism is in the developer guide.

​

Flat storage and lattice hashes

Giga’s storage layer is designed for a network that will produce petabytes of new data per year at full load:

• Flat key-value store: every account and storage slot will map directly to an entry in a log-structured merge (LSM) tree, with no per-write Merkle path updates. Hot state will be served from RAM; disk writes will be asynchronous, with a write-ahead log for crash recovery.
• Lattice-hash commitments: instead of a state root, each block’s write log will be committed with a homomorphic multiset hash (LtHash). Validators will attest to this digest, and disputes will be resolved by bisecting chunked digests to pinpoint the first divergent write.
• Block Update Digests (BUDs): Merkle proofs over per-block updates will replace global state proofs, so proof cost will scale with how much a block changed rather than how large total state is. Light clients and bridges will consume these attested digests.
• Tiered storage: recent, hot data will live on local high-performance SSDs; historical data will move to a distributed columnar store for analytics and audit workloads.

Sei v6.6 shipped the first Eidos support for separating EVM history into dedicated storage. Node migration remains phased and operator-controlled. The FlatKV and lattice-hash state-commitment model described above remains a later phase; its code is operator-gated and off by default. Details are in the storage specification.

​

What will change from today’s Sei?

​

What will happen to a transaction on Sei Giga?

Giga will have no traditional public mempool. The initial Autobahn flow and the later Sedna flow differ:

• Before Sedna activates, an RPC node will route the complete signed transaction to a validator proposal lane.
• After the Sedna milestone activates, ingress will distribute coded symbol bundles across selected lanes. Executors will reconstruct the transaction after the finalized symbols cross the decode threshold. The resulting privacy depends on the coding parameters and adversary assumptions described in the Sedna paper.

The diagram and steps below describe the initial Autobahn flow before Sedna:

1. You will send a signed transaction to an RPC node, which will route it toward a validator. Allocation will be stake-weighted, and you will be able to submit the same transaction to several validators for censorship resistance.
2. The validator will append the transaction to its next batch and chain that batch into its lane.
3. Once the batch reaches the availability threshold (f + 1 replicas in the whitepaper model; stake-weighted in the implementation), it will hold a Proof of Availability and the lane tip will advance.
4. Pipelined consensus will commit a cut of all lane tips. Your transaction’s position will now be fixed. This is ordering finality; on the internal devnet it arrived in under 250 ms.
5. Each executing validator or full node will merge the cut into one sequence using the deterministic tip-priority rule, drop duplicates by hash, and execute the result in parallel. Duplicate copies will not execute and will not pay execution costs twice.
6. Validators will attest to the block’s divergence digest in a later block. This is state attestation finality.

Guidance on which finality signal to use for what is in the developer guide.

​

How will Giga handle MEV and fees?

Multi-Proposer chains eliminate the single sequencer’s private block-building monopoly, but they create new MEV channels of their own: same-tick duplicate stealing, proposer-to-proposer orderflow deals, and races around PoA latency. Sei Labs formalized these in a dedicated MEV paper. Giga will address them at the protocol level:

• The merge rule will be deterministic. The order of transactions within a committed cut will be a pure function of lane contents: lanes will sort by their highest included tip, intra-lane order will be preserved, and duplicates will be dropped. Arrival timing and proposer discretion will play no part.
• Under the proposed design, priority fees from each epoch will be pooled and distributed to validators by stake and measured liveness rather than paid directly to the carrying proposer. Copying a high-tip transaction into another lane would not earn an additional protocol fee, and routing through a specific proposer would not receive a direct protocol payment. Side payments remain outside the current specification. A tip determines position under the protocol’s merge rule.
• Fees will come in three parts: an EIP-1559-style execution fee, a strictly enforced ordering fee (the priority fee), and a distribution fee that will price duplicate submissions. Duplicates will be deduplicated at merge time, and only one copy will execute; the rest will be refunded part of their tip.
• Sedna is intended to add pre-execution privacy. Transactions will travel through Sedna as coded symbol bundles spread across selected lanes. The privacy guarantee will depend on the coding parameters and the number of colluding lanes.

The full mechanism is specified in MEV and fee design.

​

How will Sei Giga ship?

Giga will arrive as a sequence of named upgrades to the live Sei network (Sei Labs, July 2026). The canonical tracker is giga.seilabs.io. Status as of August 2026: Sei v6.6 brought the first Ares and Eidos components to Pacific-1 at upgrade height 224201091 on August 4, 2026. Ares became the default execution path for upgraded nodes. Eidos migration remains phased and operator-controlled. Autobahn consensus, FlatKV/lattice-hash state commitment, and Sedna remain separate milestones or operator-gated work. Node operators should follow the release-specific configuration reference rather than infer settings from roadmap status.

​

Performance claims and targets

Each row carries its source and date. Devnet figures are Sei Labs’ internal measurements, consensus comparisons are whitepaper claims, and testnet figures are targets rather than measurements.

​

Learn more

Last updated August 2026