Skip to main content
This page specifies the Sei Giga protocol as defined in the Giga whitepaper v2.0 (Marsh, Landers, Jog, Ranchal-Pedrosa; June 2026), with implementation notes from the sei-chain v6.6 release and its Pacific-1 activation (August 2026). Please note: the specification below is forward-looking and subject to change until the corresponding upgrades activate on the Sei network. For a conceptual introduction, start with the Sei Giga overview; for practical guidance, see the developer guide.

​
Protocol at a glance

​
Network and security model

The equations in the whitepaper use a replica-count model with n = 3f + 1, of which at most f replicas are Byzantine. The sei-chain implementation applies stake-weighted voting thresholds, so do not interpret f as a raw validator count when reasoning about the live network. Under the whitepaper’s fault and cryptographic assumptions, even an extended network delay does not allow two conflicting proposals to receive valid commit certificates. The network may pause during a disruption and resume once message delays return within the protocol’s timing bounds.
  • Safety: no two conflicting proposals can both obtain a valid commit certificate in the same consensus slot. Attesting to two different divergence digests for the same finalized block will be slashable equivocation, because quorum intersection guarantees at least one honest validator would have to sign both.
  • Censorship resistance: once a proposal reaches the availability threshold (f + 1 replicas in the whitepaper model; stake-weighted in the implementation), at least one honest replica stores its data under the stated assumptions, and a correct leader must include it in a future cut. This is designed to limit censorship to a finite delay. Users will also be able to submit a transaction to multiple validators at once (deduplicated at merge, with a partial tip refund).
  • Execution divergence: divergence below one-third of voting power can be isolated. Divergence beyond the Byzantine threshold is designed to pause the chain.
  • Staking: validators will continue to bond SEI and can be slashed for malicious behavior. The complete slashing schedule, reward functions, and tokenomics for Giga are deferred to future work; today’s staking parameters are documented in Staking.

​
Consensus: Autobahn

Sei Giga will order transactions with Autobahn (Giridharan, Suri-Payer, Abraham, Alvisi, Crooks; 2024), a BFT protocol that decouples data dissemination from ordering. The paper positions it between view-based protocols (HotStuff, Tendermint), which can stall during network “blips,” and DAG-based protocols (Narwhal-style), which can add good-case latency. Under the paper’s evaluated conditions, Autobahn combines an asynchronous data layer with partially synchronous ordering and reports DAG-class throughput at roughly half the latency.

​
Data dissemination: lanes and Proofs of Availability

  • Every validator r will maintain its own lane: an append-only, hash-chained sequence of transaction batches (called cars). A proposal is the tuple Prop = ⟨pos, batch, parentRef⟩ signed by r, where pos is the lane sequence number and parentRef is the hash of the previous proposal in the same lane.
  • Validators that receive a proposal will verify it extends the lane correctly and return a signed vote over its digest. Once the proposer collects f + 1 matching votes, it will assemble a Proof of Availability (PoA), a certificate that the data is retrievable.
  • f + 1 is sufficient because any such quorum contains at least one correct replica that held the full data when it voted, and that replica serves it until all correct replicas have it. Giga’s design deliberately keeps the smaller quorum (rather than 2f + 1) because commitment itself triggers full replication along the execution path; a larger quorum would only add certification latency.
  • The latest proposal in a lane holding a PoA is the lane’s tip. Lanes are hash-chained, so certifying a tip implicitly attests the availability of every earlier proposal in that lane without re-certifying each prior entry.
All validators will disseminate batches in parallel without waiting for consensus. The design aims to move dissemination off the ordering critical path and use aggregate validator bandwidth rather than one leader’s uplink. Actual bottlenecks depend on workload, network conditions, and implementation limits.

​
Ordering: cuts of tips

Consensus will periodically fix a global order by committing a cut, a vector of every lane’s current certified tip:
  1. Prepare. The slot’s leader (chosen by stake-weighted selection, as in Tendermint) will bundle the latest certified tips into a cut proposal; replicas will validate the PoAs and broadcast prepare votes, forming a PrepareQC at n - f votes.
  2. Commit. Replicas will exchange commit votes over the PrepareQC. A CommitQC formed from n - f votes finalizes the cut in the whitepaper’s replica-count model.
  3. Pipelining. Slots will overlap: as soon as replicas see the Prepare message for slot s, they can begin slot s + 1, and the next leader may start proposing while the previous cut is still in its commit phase. With quadratic communication and pipelining, the design targets an effective steady-state cadence of one committed cut per 1.5 network round trips, versus three full rounds in Tendermint. This cadence is not a per-transaction finality guarantee.
Committing one cut will finalize every uncommitted proposal in every lane up to the referenced tips. A single consensus decision can therefore commit many blocks’ worth of data at once, which is why the whitepaper anticipates roughly 70 times higher block production than the single-proposer design (180 versus 2.5 blocks per second). Validators will vote on compact certificates only; a replica that is missing batch data will fetch it after commit, off the critical path.

​
Leader failure and recovery

If a leader fails to make progress, replicas will fall back to a standard view change: a timeout certificate will elect a new leader, and the protocol will resume. Lane dissemination is designed to continue during the view change, which isolates most of the disruption to ordering latency. The Autobahn paper calls this “seamless” recovery from blips and contrasts it with the post-asynchrony recovery cost of chained-HotStuff-style protocols. Two consensus upgrades beyond launch are already specified:
  • Ambulance (arXiv 2606.25099) replaces the timeout race with a “protocol-rigged race”: non-leader replicas do useful persistence work on candidate cuts built from the same certified tips in parallel, so when a leader is merely slow (I/O contention, garbage collection, routing trouble) the slot can finish from existing recovery state instead of paying a full timeout. Planned as a core part of a future upgrade.
  • Hermes, a next-generation consensus protocol on the official roadmap; its whitepaper has not been published yet.

​
Execution

​
Two finality notions

Giga will separate what consensus decides from what execution produces: Unless stated otherwise, latency claims in Giga materials refer to ordering finality. Under the protocol’s stated fault and cryptographic assumptions, ordering finality fixes the transaction sequence; state attestation finality adds a BFT-signed confirmation of the results of execution. Execution occurs between these two protocol signals. A receipt becomes available only after a node executes the ordered transaction; ordering finality alone does not provide an execution result.

​
Deterministic block transition

For each finalized block, the protocol specifies the canonical transition Apply(S_prev, context, block) → (S_new, receipts, gas, writeLog). Given the same pre-state, block context, ordered transactions, execution semantics, and serializable parallel schedule, conforming executors should derive byte-identical results without communicating. A transaction revert is itself an execution result and does not invalidate the rest of the block. This intended determinism allows execution to run off the consensus critical path. The execution client is deliberately narrow: it processes transactions and nothing else, with no tracing or log search on the hot path. Incoming blocks are pre-processed in parallel (parsing, sender recovery, signature verification), while exactly one block executes at a time. Receipt generation and indexing happen after execution, so block n + 1 can start while block n post-processes.

​
Parallel execution: Block-STM-style OCC

Within a block, transactions execute concurrently under optimistic concurrency control (the Block-STM approach):
  • A later transaction t_j depends on an earlier t_i when t_i’s write set overlaps t_j’s read or write set. The block’s total order keeps this dependency relation acyclic.
  • All transactions start executing in parallel, each buffering its writes privately. A validation phase checks, for each transaction, whether any earlier-ordered transaction committed a write into its read or write set after it began; conflicting transactions are rolled back and re-executed.
  • The committed result is provably identical to sequential execution in block order (a “valid parallel schedule”). When contention is low, most transactions commit on their first attempt; under sustained contention the engine may fall back to sequential execution with unchanged semantics. In sei-chain, the scheduler retries a transaction up to 10 times before reverting to the sequential path.
Sei Labs measured that 64.85% of historical Ethereum transactions could have been parallelized under this model. Contract-design guidance for maximizing parallelism is in the developer guide.

​
Transaction encoding

Giga will replace nested RLP with a flat, length-prefixed encoding designed for single-pass, zero-copy decoding: fields (type, chain ID, sender, recipient, value, nonce, gas limit, signature, access list) appear in a fixed order, variable-length fields carry a one-byte length prefix, contract creation is signaled by a marker byte, and all remaining bytes are the calldata. A parser reads each transaction in one pass with no allocation-heavy tree construction, which matters when decoding hundreds of thousands of transactions per second.

​
EVM compatibility

Sei Giga’s EVM will be mostly equivalent to mainnet Ethereum. Contracts will be written in standard Solidity or Vyper and deployed with standard tooling.

​
Fee model

​
Storage

Giga’s storage layer is designed for petabyte-per-year data production at full 5-gigagas load while keeping validator hardware practical.

​
Flat state, RAM-first

  • Every account, storage slot, and global variable will map directly to an entry in a log-structured merge (LSM) tree. Writes will skip per-write Merkle path updates entirely, so flushes stay batched and sequential and nothing is re-hashed on the write path.
  • Frequently accessed state will be held in RAM, and reads will be served from memory in the common case. All disk writes will be asynchronous and exist for durability only, protected by an append-only write-ahead log (WAL) that is replayed on crash recovery.
  • Storage will be tiered: recent and hot data will sit on local high-performance SSDs, while historical data will move to a distributed columnar store built for analytical queries and audit workloads.

​
Lattice-hash divergence digests

There will be no state root; Giga will instead commit to execution results with a homomorphic multiset hash (LtHash, by Lewi, Kim, Maykov, and Weis): LH(X) = Σ h(x) mod q. Its collision resistance rests on lattice assumptions (short integer solution style). For each block n:
  • The committed multiset X_n will contain one record per surviving write (after intra-block last-write-wins resolution), one record per transaction receipt (position-bound), and one gas-accounting record, each domain-separated by type tag and height.
  • The block digest is d_n = LH(X_n); validators will attest to the compact commitment D_n = H(enc(n, d_n)). The full vector d_n will be exchanged only during disputes.
  • Disputes will resolve by bisection. The key space partitions into ranges whose chunk digests sum to the write component of d_n by construction, so divergent executors will compare chunk digests, narrow down, and replay only the affected range to find the first divergent write, receipt, or gas discrepancy.
The homomorphism is what makes this practical: digests update incrementally as writes commit, in any order, and no tree walk is involved.

​
Block Update Digests (BUDs)

BUDs will restore externally verifiable state proofs (the role eth_getProof plays on Ethereum) at a cost proportional to per-block update volume rather than total state size:
  • Every state entry will carry an 8-byte last-modified height and a 1-byte serialization version. For each block n, the BUD U_n is the Merkle root over the lexicographically sorted leaves (key, newValue, n, prevHeight) of that block’s writes. Validators will attest U_n on the same delayed two-thirds voting-power schedule as the divergence digest.
  • A membership proof will be a Merkle path to an attested U_n, certifying that key held value immediately after block n and recording when it previously changed. Two proofs at heights a < b whose b-leaf records predecessor a will prove the key was unmodified throughout (a, b).
  • SuperBUDs will aggregate BUDs over exponentially growing aligned windows (branching base e and maximum level L_max, both governance parameters), so provers will cover long ranges with logarithmically many digests. The guaranteed proof window will be η = e^L_max blocks; older claims can be served by archive nodes but fall outside the protocol guarantee.
  • Touch transactions will rewrite only a key’s last-modified metadata, giving long-untouched keys a fresh proof anchor. Deletions will leave tombstones, garbage-collected after η, which anchor exclusion proofs.
  • At the activation height a one-time synthetic write log will bootstrap every existing key, and the system will reach steady state after η blocks. BUD trees deliberately use a classical hash: the short proof window keeps classical collision resistance sufficient, and the trees will fall under the same post-quantum migration schedule as the rest of the protocol.
Light clients, bridges, and any external verifier will consume BUD proofs against attested digests instead of Merkle-Patricia proofs against a state root.

​
Networking and transaction ingress

  • Nodes will communicate over direct, authenticated point-to-point connections rather than network-wide gossip. Consensus messages, lane proposals, votes, and certificates will stream over dedicated channels with per-channel rate and size limits.
  • There will be no traditional public mempool. Before Sedna activates, RPC nodes will route complete signed transactions into validator lanes. After the later Sedna milestone activates, ingress will distribute coded symbol bundles across selected lanes. In the current implementation, EVM senders map deterministically to a validator shard, and eth_sendRawTransaction plus pending-nonce queries are proxied to that shard’s owner.
  • Users will be able to submit the same transaction to multiple validators for censorship resistance. Admission will be rate-limited: each validator will include at most one copy of a given transaction per epoch, duplicates will be dropped deterministically at merge time, only one copy will execute, and unexecuted duplicates will earn a partial tip refund while paying the distribution fee.
  • Four node roles will exist: validators (consensus and execution), full nodes (RPC plus execution for the read path), light nodes (RPC only), and data nodes that serve recent data.

​
Sedna: private dissemination

Sedna is planned as Giga’s private dissemination layer, a later roadmap milestone after Autobahn mainnet. Senders would encode a committed transaction payload into verifiable rateless coded symbols and send addressed bundles to selected proposer lanes. Executors would reconstruct the payload after finalized symbols cross the decode threshold. The paper calls this “until-decode privacy”; its guarantees depend on the coding parameters and the number of colluding lanes. Compared with threshold-encrypted mempools, the Sedna paper argues that the design can provide similar pre-execution privacy without an extra decryption round, while reducing per-lane bandwidth. The companion incentive mechanism PIVOT-K would concentrate a sender-funded bounty on bundles that trigger decoding and ratchet away from lanes that withhold.

​
MEV and fee design

Multi-Proposer architectures remove the single block-builder’s private ordering monopoly but introduce their own MEV (maximal extractable value) channels, formalized in MEV in Multiple Concurrent Proposer Blockchains: same-tick duplicate stealing (copying a visible transaction into your own lane to win the merge), proposer-to-proposer orderflow deals, and timing races around PoA latency. Giga’s countermeasures will live at the protocol level.

​
Deterministic merge rule

For each committed cut, every node will derive the executable sequence with the same pure function:
  1. Take each lane’s newly committed transactions, meaning those not in any previous cut, in their intra-lane order.
  2. Sort lanes by the maximum priority fee among their new transactions, descending; break ties by replica index.
  3. Concatenate the lanes and deduplicate by transaction hash; only the first occurrence survives.
The merged order is designed to depend only on finalized lane contents, not on arrival timing, wall clocks, or a node’s post-consensus discretion. This is intended to reduce protocol-level post-consensus reordering opportunities.

​
Socialised tips

All priority fees collected in an epoch (net of duplicate refunds) will be pooled and distributed to validators pro rata by stake × liveness, where liveness will be the measured fraction of observable duties performed: consensus votes included in committed QCs, certified lane blocks produced, and signed state attestations, with duty weighting set by governance. Payouts will be shared with delegators in the same way as block rewards.
  • Under the proposed fee design, copying a high-tip transaction into another lane would not capture its fee. This is intended to reduce the duplicate-steal channel’s protocol-level revenue motive.
  • Validator revenue from the protocol would be independent of orderflow routing, reducing the protocol-level incentive to steer users to specific proposers.
  • Withholding or lazy participation will directly reduce a validator’s payout.
The whitepaper sums it up: the priority fee will buy ordering, not a relationship with a particular proposer. Side payments for intra-lane position are out of protocol scope for now and belong to the forthcoming fee-mechanism work.

​
Post-quantum migration

The proposed Giga architecture includes a survivability path for a sudden ECDSA break (“Q-day”) that is designed to avoid a chain-wide account reset:
  • Before a governance-set cutoff height, any account will be able to register a post-quantum verification key (scheme identifier, PQ public key, migration nonce, optional activation height), signed with its current classical key.
  • During the transition window, the chain would accept classical or dual classical+PQ signatures. After the cutoff, accounts that had not registered a post-quantum key would no longer be able to authorize transactions with their existing ECDSA key. The proposed path does not include public-key recovery or new classical EOAs after that point. Onboarding would continue through pre-registration, contract wallets, or a later native PQ account format.
  • The designated short-term scheme is ML-DSA (FIPS 204). The whitepaper is explicit that this is an emergency path and not fast enough for Giga’s throughput; post-quantum cryptography at Giga scale is open research.

​
Performance claims and targets

The whitepaper publishes no fixed block gas limit, block size, or validator hardware specification for Giga; the roadmap’s Autobahn testnet milestone includes the final consensus specification. Figures you may see for today’s network (block times, gas limits) describe the current architecture, not the anticipated architecture under Giga.

​
Implementation snapshot (Sei v6.6 activation, August 2026)

Giga is implemented in the open in sei-protocol/sei-chain; there is no separate Giga repository. The mandatory v6.6 release brought the first Ares and Eidos components to Pacific-1 at height 224201091 on August 4, 2026. Ares became the default execution path for upgraded nodes; Eidos migration remains phased and operator-controlled. Broader work continues, and later Giga components remain inactive: Node operators should follow the node configuration reference rather than this page for exact keys and defaults.

​
Glossary

​
References

Disclaimer: The roadmap is subject to change based on development progress, market feedback, and other factors. Actual timelines, figures, and outcomes may vary.
Last updated August 2026, based on the Giga whitepaper v2.0 (June 29, 2026), the sei-chain v6.6 release, and the Pacific-1 v6.6 activation.