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, which works out to roughly 200,000 transactions per second. 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 will separate the work of a blockchain into four decoupled stages: data dissemination, ordering, execution, and state attestation. Each stage will 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.
• A batch will be certified by a Proof of Availability (PoA) once f + 1 validators vote that they hold the data, which is enough to guarantee at least one honest holder.
• 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.
• The ordering vote will take 1.5 network round trips with pipelined slots, versus three full rounds for Tendermint, and validators will vote on compact certificates instead of downloading full blocks first.

Throughput will scale with the number of validators disseminating data instead of being capped by one leader’s connection; Sei Labs cites over 50 times Tendermint’s throughput, with standard BFT safety intact. The full protocol is in the consensus specification.

​

Asynchronous execution and state attestation

Giga will provide two distinct finality signals:

• Ordering finality: consensus has fixed the transaction order irrevocably. This is the sub-250 ms signal, and for most applications it will be the moment a transaction is final.
• State attestation finality: validators have executed the block, computed a compact divergence digest over its write log, and a 2/3 quorum has attested to that digest in a later block.

Execution will be deterministic, so every honest node that executes the same ordered transactions from the same state will compute the identical result, and ordering will continue while execution catches up. If fewer than 1/3 of validators diverge (a hardware fault or software bug), the chain will keep running while the fault is isolated; a divergence beyond the Byzantine threshold will halt the chain, exactly as in any BFT system. 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.

The Eidos upgrade is delivering this storage model to the live network, and its first production pieces (FlatKV with lattice hashing) already ship in sei-chain. 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: instead of waiting in a shared pending pool, a submitted transaction will route through Sedna, Giga’s private dissemination layer, into validator proposal lanes. Sedna will spread transaction fragments across lanes and reassemble them only after ordering, so no single validator will see the whole transaction before its position is fixed.

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 f + 1 validators acknowledge the batch, it will hold a Proof of Availability and the lane tip will advance.
4. The consensus leader will commit a cut of all lane tips in 1.5 round trips. Your transaction’s position will now be fixed. This is ordering finality; on the internal devnet it arrived in under 250 ms.
5. Every 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.
• Priority fees will be socialised. Fees from each epoch will be pooled and distributed to validators by stake and measured liveness, not paid to whichever proposer carried the transaction. Copying someone else’s high-tip transaction into your own lane will earn the copier nothing extra, and routing deals with specific proposers will have no protocol revenue to capture. Under this design, a tip pays for position in the order and nothing else.
• 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 will add pre-execution privacy. Transactions will travel through Sedna as coded fragments spread across lanes, so their contents will stay hidden until ordering is final — a design intended to leave no visible pending transaction to front-run.

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 July 2026: Parts of this are already in the sei-chain codebase. As of July 2026 the Giga execution engine ships in sei-chain and runs by default (with OCC) from the v6.6 release line, while Autobahn consensus and the FlatKV/lattice-hash storage stack ship in the same binary behind operator flags, disabled until their network activations. Node operators can review the Giga executor configuration and the Giga storage migration guide.

​

Measured performance

Each row carries its source and date: the devnet figures are Sei Labs’ internal measurements, the consensus multipliers are whitepaper claims, and the testnet figures are targets.

​

Learn more

Last updated July 2026