> ## Documentation Index
> Fetch the complete documentation index at: https://seilabs-docs-evm-cookbook.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 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. On an internal 40-node devnet it finalized transaction ordering in under 250 ms and sustained more than 5 gigagas per second. It will roll out as in-place upgrades to the live Sei network.

export const GigaRoadmapTrack = () => {
  const ink = 'currentColor';
  const done = 'var(--sei-diagram-ok, #1a7a00)';
  const prog = 'var(--sei-diagram-warning, #b45309)';
  const items = [{
    l: 'WP v1',
    s: 'done'
  }, {
    l: 'Devnet',
    s: 'done'
  }, {
    l: 'WP v2',
    s: 'done'
  }, {
    l: 'Eidos',
    s: 'prog'
  }, {
    l: 'Ares',
    s: 'prog'
  }, {
    l: 'SIP-3',
    s: 'prog'
  }, {
    l: 'Autobahn testnet',
    s: 'next'
  }, {
    l: 'Autobahn mainnet',
    s: 'next'
  }, {
    l: 'Sedna',
    s: 'next'
  }, {
    l: 'Hermes testnet',
    s: 'next'
  }, {
    l: 'Hermes mainnet',
    s: 'next'
  }];
  return <div className="not-prose w-full my-5">
      <div className="overflow-x-auto rounded-xl border border-neutral-200 dark:border-neutral-800 bg-white/60 dark:bg-neutral-900/40 p-4 text-neutral-800 dark:text-neutral-200">
        <svg viewBox="0 0 920 178" role="img" aria-label="Giga roadmap progress track" style={{
    width: '100%',
    minWidth: 680,
    height: 'auto',
    display: 'block'
  }}>
          <line x1={50} y1={92} x2={230} y2={92} stroke={done} strokeWidth="2.5" />
          <line x1={230} y1={92} x2={470} y2={92} stroke={prog} strokeWidth="2.5" strokeDasharray="6 4" />
          <line x1={470} y1={92} x2={890} y2={92} stroke={ink} strokeOpacity="0.25" strokeWidth="2" strokeDasharray="2 5" />
          {items.map((it, i) => {
    const x = 70 + i * 80;
    const above = i % 2 === 0;
    const c = it.s === 'done' ? done : it.s === 'prog' ? prog : ink;
    return <g key={it.l}>
                <circle cx={x} cy={92} r={9} fill={it.s === 'next' ? 'none' : c} fillOpacity={it.s === 'done' ? 0.95 : it.s === 'prog' ? 0.25 : 0} stroke={c} strokeOpacity={it.s === 'next' ? 0.45 : 1} strokeWidth="1.6" />
                {it.s === 'done' ? <path d={`M ${x - 4} 92 l 3 3.4 l 5.4 -6.4`} fill="none" stroke="#fff" strokeWidth="1.8" strokeLinecap="round" strokeLinejoin="round" /> : null}
                {it.s === 'prog' ? <circle cx={x} cy={92} r={3.4} fill={prog} /> : null}
                <line x1={x} y1={above ? 82 : 102} x2={x} y2={above ? 68 : 116} stroke={ink} strokeOpacity="0.25" strokeWidth="1" />
                <text x={x} y={above ? 58 : 132} fontSize="10.5" textAnchor="middle" fill={ink} fillOpacity="0.85">{it.l}</text>
              </g>;
  })}
          <rect x={296} y={140} width={9} height={9} rx={2} fill={done} />
          <text x={311} y={148.5} fontSize="10" fill={ink} fillOpacity="0.7">complete</text>
          <rect x={386} y={140} width={9} height={9} rx={2} fill={prog} fillOpacity="0.9" />
          <text x={401} y={148.5} fontSize="10" fill={ink} fillOpacity="0.7">in progress (August 2026)</text>
          <rect x={536} y={140} width={9} height={9} rx={2} fill="none" stroke={ink} strokeOpacity="0.5" />
          <text x={551} y={148.5} fontSize="10" fill={ink} fillOpacity="0.7">coming soon</text>
        </svg>
      </div>
      <div className="mt-2 text-xs text-neutral-600 dark:text-neutral-400">The eleven roadmap milestones from giga.seilabs.io. Ares is the default execution path on upgraded v6.6 nodes, Eidos migration remains phased, and the Autobahn testnet is next.</div>
    </div>;
};

export const GigaTxJourney = () => {
  const ink = 'currentColor';
  const accent = 'var(--sei-maroon-50)';
  const gold = 'var(--sei-diagram-gold, var(--sei-gold-100))';
  const steps = [{
    t: 'submit',
    s: 'to any RPC node'
  }, {
    t: 'lane',
    s: 'validator includes it'
  }, {
    t: 'PoA',
    s: 'availability threshold'
  }, {
    t: 'ordered',
    s: 'cut committed'
  }, {
    t: 'executed',
    s: 'merged, run in parallel'
  }, {
    t: 'attested',
    s: '2/3 voting-power digest'
  }];
  return <div className="not-prose w-full my-5">
      <div className="overflow-x-auto rounded-xl border border-neutral-200 dark:border-neutral-800 bg-white/60 dark:bg-neutral-900/40 p-4 text-neutral-800 dark:text-neutral-200">
        <svg viewBox="0 0 900 168" role="img" aria-label="Transaction journey from submission to attestation" style={{
    width: '100%',
    minWidth: 640,
    height: 'auto',
    display: 'block'
  }}>
          <defs>
            <marker id="gtj-a" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse">
              <path d="M 0 1 L 9 5 L 0 9 z" fill={ink} fillOpacity="0.6" />
            </marker>
          </defs>
          {steps.map((st, i) => {
    const x = 76 + i * 150;
    const strong = i === 3 || i === 5;
    return <g key={st.t}>
                {i < steps.length - 1 ? <line x1={x + 22} y1={84} x2={x + 128} y2={84} stroke={ink} strokeOpacity="0.4" strokeWidth="1.2" markerEnd="url(#gtj-a)" /> : null}
                <circle cx={x} cy={84} r={19} fill={strong ? accent : ink} fillOpacity={strong ? 0.9 : 0.07} stroke={strong ? accent : ink} strokeOpacity={strong ? 1 : 0.45} strokeWidth="1.2" />
                <text x={x} y={88.5} fontSize="12" textAnchor="middle" fontWeight="600" fill={strong ? '#fff' : ink}>{i + 1}</text>
                <text x={x} y={124} fontSize="11.5" textAnchor="middle" fontWeight="600" fill={ink}>{st.t}</text>
                <text x={x} y={140} fontSize="9.5" textAnchor="middle" fill={ink} fillOpacity="0.6">{st.s}</text>
              </g>;
  })}
          <text x={526} y={40} fontSize="10" textAnchor="middle" fill={accent} fontWeight="600">ordering finality</text>
          <line x1={526} y1={46} x2={526} y2={62} stroke={accent} strokeWidth="1.2" strokeDasharray="3 3" />
          <text x={826} y={40} fontSize="10" textAnchor="middle" fill={ink} fillOpacity="0.85" fontWeight="600">state attestation finality</text>
          <line x1={826} y1={46} x2={826} y2={62} stroke={gold} strokeWidth="1.6" strokeDasharray="3 3" />
        </svg>
      </div>
      <div className="mt-2 text-xs text-neutral-600 dark:text-neutral-400">The initial Autobahn transaction flow before Sedna. An RPC node routes the complete signed transaction to a lane, consensus fixes its order, execution produces the receipt, and attestation follows.</div>
    </div>;
};

export const GigaAsyncPipeline = () => {
  const ink = 'currentColor';
  const accent = 'var(--sei-maroon-50)';
  const gold = 'var(--sei-diagram-gold, var(--sei-gold-100))';
  const rows = [{
    y: 62,
    label: 'Ordering'
  }, {
    y: 116,
    label: 'Execution'
  }, {
    y: 170,
    label: 'Attestation'
  }];
  return <div className="not-prose w-full my-5">
      <div className="overflow-x-auto rounded-xl border border-neutral-200 dark:border-neutral-800 bg-white/60 dark:bg-neutral-900/40 p-4 text-neutral-800 dark:text-neutral-200">
        <svg viewBox="0 0 860 250" role="img" aria-label="Ordering, execution, and attestation run as a pipeline" style={{
    width: '100%',
    minWidth: 620,
    height: 'auto',
    display: 'block'
  }}>
          <defs>
            <marker id="gap-a" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse">
              <path d="M 0 1 L 9 5 L 0 9 z" fill={ink} fillOpacity="0.6" />
            </marker>
          </defs>
          {rows.map(r => <g key={r.label}>
              <text x={104} y={r.y + 17} fontSize="11.5" textAnchor="end" fill={ink} fillOpacity="0.75">{r.label}</text>
              <line x1={116} y1={r.y + 13} x2={836} y2={r.y + 13} stroke={ink} strokeOpacity="0.1" strokeWidth="1" />
            </g>)}
          {[0, 1, 2, 3].map(i => <g key={'o' + i}>
              <rect x={126 + i * 168} y={62} width={118} height={26} rx={5} fill={accent} fillOpacity={0.14} stroke={accent} strokeWidth="1" />
              <text x={185 + i * 168} y={79} fontSize="10.5" textAnchor="middle" fill={ink}>order n{i > 0 ? '+' + i : ''}</text>
            </g>)}
          {[0, 1, 2].map(i => <g key={'e' + i}>
              <rect x={294 + i * 168} y={116} width={128} height={26} rx={5} fill={ink} fillOpacity="0.06" stroke={ink} strokeOpacity="0.4" strokeWidth="1" />
              <text x={358 + i * 168} y={133} fontSize="10.5" textAnchor="middle" fill={ink} fillOpacity="0.85">execute n{i > 0 ? '+' + i : ''}</text>
            </g>)}
          <rect x={630} y={170} width={186} height={26} rx={5} fill={gold} fillOpacity="0.2" stroke={gold} strokeWidth="1" />
          <text x={723} y={187} fontSize="10.5" textAnchor="middle" fill={ink}>attest n: 2/3 voting power signs D_n</text>

          <line x1={244} y1={54} x2={244} y2={204} stroke={accent} strokeWidth="1.4" strokeDasharray="4 3" />
          <text x={244} y={46} fontSize="10" textAnchor="middle" fill={accent} fontWeight="600">ordering finality for n</text>
          <line x1={244} y1={204} x2={626} y2={204} stroke={ink} strokeOpacity="0.4" strokeWidth="1" strokeDasharray="3 3" markerEnd="url(#gap-a)" />
          <text x={437} y={198} fontSize="9.5" textAnchor="middle" fill={ink} fillOpacity="0.65">attestation for n lags by x blocks</text>
          <line x1={816} y1={162} x2={816} y2={204} stroke={gold} strokeWidth="1.4" strokeDasharray="4 3" />
          <text x={744} y={216} fontSize="10" textAnchor="middle" fill={ink} fillOpacity="0.85" fontWeight="600">state attestation finality for n</text>

          <line x1={116} y1={228} x2={836} y2={228} stroke={ink} strokeOpacity="0.4" strokeWidth="1" markerEnd="url(#gap-a)" />
          <text x={126} y={243} fontSize="9.5" fill={ink} fillOpacity="0.55">time</text>
        </svg>
      </div>
      <div className="mt-2 text-xs text-neutral-600 dark:text-neutral-400">Consensus will keep ordering new blocks while earlier blocks execute and their divergence digests are attested. Ordering finality will be the fast signal. State attestation will follow a bounded number of blocks later.</div>
    </div>;
};

export const GigaProposerComparison = () => {
  const ink = 'currentColor';
  const accent = 'var(--sei-maroon-50)';
  const box = {
    fill: ink,
    fillOpacity: 0.05,
    stroke: ink,
    strokeOpacity: 0.35,
    strokeWidth: 1
  };
  const lanes = [0, 1, 2, 3];
  return <div className="not-prose w-full my-5">
      <div className="overflow-x-auto rounded-xl border border-neutral-200 dark:border-neutral-800 bg-white/60 dark:bg-neutral-900/40 p-4 text-neutral-800 dark:text-neutral-200">
        <svg viewBox="0 0 860 300" role="img" aria-label="Single proposer versus Multi-Proposer architecture" style={{
    width: '100%',
    minWidth: 620,
    height: 'auto',
    display: 'block'
  }}>
          <defs>
            <marker id="gpc-a" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse">
              <path d="M 0 1 L 9 5 L 0 9 z" fill={ink} fillOpacity="0.6" />
            </marker>
            <marker id="gpc-b" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse">
              <path d="M 0 1 L 9 5 L 0 9 z" fill={accent} />
            </marker>
          </defs>

          <text x={110} y={30} fontSize="13" fontWeight="600" fill={ink}>Single proposer (Tendermint-style)</text>
          {lanes.map(i => <g key={'l' + i}>
              <circle cx={90} cy={80 + i * 52} r={15} fill={i === 1 ? accent : ink} fillOpacity={i === 1 ? 0.9 : 0.12} stroke={i === 1 ? accent : ink} strokeOpacity={i === 1 ? 1 : 0.4} />
              <text x={90} y={84 + i * 52} fontSize="10.5" textAnchor="middle" fill={i === 1 ? '#fff' : ink} fillOpacity={i === 1 ? 1 : 0.8}>V{i + 1}</text>
            </g>)}
          <text x={62} y={136} fontSize="10" textAnchor="end" fill={accent}>leader</text>
          {[0, 2, 3].map(i => <path key={'v' + i} d={`M 108 ${80 + i * 52} Q 150 ${80 + i * 52} 168 ${138 - (i === 0 ? 6 : 0)}`} fill="none" stroke={ink} strokeOpacity="0.35" strokeWidth="1" strokeDasharray="3 3" markerEnd="url(#gpc-a)" />)}
          <text x={148} y={100} fontSize="9.5" fill={ink} fillOpacity="0.55">votes</text>
          <line x1={108} y1={132} x2={170} y2={132} stroke={accent} strokeWidth="1.6" markerEnd="url(#gpc-b)" />
          <rect x={174} y={110} width={120} height={44} rx={7} {...box} stroke={accent} strokeOpacity="0.9" />
          <text x={234} y={129} fontSize="11" textAnchor="middle" fill={ink}>block h</text>
          <text x={234} y={144} fontSize="9.5" textAnchor="middle" fill={ink} fillOpacity="0.6">one block per round</text>
          <line x1={234} y1={154} x2={234} y2={212} stroke={ink} strokeOpacity="0.4" strokeWidth="1" markerEnd="url(#gpc-a)" />
          {[0, 1, 2].map(i => <g key={'c' + i}>
              <rect x={160 + i * 54} y={216} width={46} height={28} rx={5} {...box} />
              <text x={183 + i * 54} y={234} fontSize="9.5" textAnchor="middle" fill={ink} fillOpacity="0.7">{['h-2', 'h-1', 'h'][i]}</text>
            </g>)}
          <text x={200} y={278} fontSize="10.5" fill={ink} fillOpacity="0.6" textAnchor="middle">throughput capped by one leader's bandwidth</text>

          <line x1={425} y1={20} x2={425} y2={285} stroke={ink} strokeOpacity="0.15" strokeWidth="1" />

          <text x={560} y={30} fontSize="13" fontWeight="600" fill={ink}>Multi-Proposer (Sei Giga)</text>
          {lanes.map(i => <g key={'r' + i}>
              <circle cx={480} cy={78 + i * 46} r={13} fill={accent} fillOpacity="0.85" />
              <text x={480} y={82 + i * 46} fontSize="10" textAnchor="middle" fill="#fff">V{i + 1}</text>
              {[0, 1, 2].map(j => <g key={'rb' + i + j}>
                  <rect x={510 + j * 56} y={64 + i * 46} width={44} height={28} rx={5} {...box} stroke={j === 2 ? accent : ink} strokeOpacity={j === 2 ? 0.9 : 0.35} />
                  {j < 2 ? <line x1={554 + j * 56} y1={78 + i * 46} x2={564 + j * 56} y2={78 + i * 46} stroke={ink} strokeOpacity="0.45" strokeWidth="1" markerEnd="url(#gpc-a)" /> : null}
                </g>)}
            </g>)}
          <text x={510} y={50} fontSize="9.5" fill={ink} fillOpacity="0.55">every validator streams its own lane</text>
          <text x={646} y={250} fontSize="9.5" textAnchor="middle" fill={accent}>tips</text>
          <line x1={646} y1={58} x2={646} y2={240} stroke={accent} strokeWidth="1.4" strokeDasharray="5 4" />
          <line x1={652} y1={148} x2={696} y2={148} stroke={accent} strokeWidth="1.6" markerEnd="url(#gpc-b)" />
          <rect x={700} y={106} width={130} height={84} rx={8} fill={accent} fillOpacity="0.09" stroke={accent} strokeWidth="1.2" />
          <text x={765} y={138} fontSize="11" textAnchor="middle" fill={ink}>cut of tips</text>
          <text x={765} y={155} fontSize="9.5" textAnchor="middle" fill={ink} fillOpacity="0.65">one consensus slot</text>
          <text x={765} y={169} fontSize="9.5" textAnchor="middle" fill={ink} fillOpacity="0.65">commits all lanes</text>
          <text x={655} y={278} fontSize="10.5" fill={ink} fillOpacity="0.6" textAnchor="middle">designed to use aggregate validator bandwidth</text>
        </svg>
      </div>
      <div className="mt-2 text-xs text-neutral-600 dark:text-neutral-400">One leader per height versus every validator proposing concurrently. In Giga, consensus will commit a cut of all lane tips, so a single decision will finalize many blocks of data.</div>
    </div>;
};

Sei Giga will be the next generation of the Sei protocol after the Giga Upgrade. It is 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. Execution and state attestation will happen after that, 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). At that throughput, ordering finality was 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, not as a new chain.

<Info>
  **Status (August 2026):** The [Giga whitepaper v2.0](https://arxiv.org/abs/2505.14914) was published in June 2026. The mandatory [Sei v6.6 release](https://github.com/sei-protocol/sei-chain/releases/tag/v6.6.0) brought the first execution (Ares) and storage (Eidos) components to Sei Mainnet on August 4. Ares became the default execution path for upgraded nodes. Eidos storage migration remains phased and operator-controlled. Broader Eidos and Ares work continues, and the Autobahn consensus testnet is the next milestone on the [official roadmap](https://giga.seilabs.io). Functionality not yet activated remains forward-looking and subject to change.
</Info>

## Sei Giga at a glance

| Property | Sei Giga |
| - | - |
| Architecture | Multi-Proposer (MCP) EVM Layer 1: every validator will propose concurrently |
| Consensus | Autobahn BFT: per-validator data lanes with periodic cut-of-tips ordering |
| Consensus cadence | Effective steady-state cadence of one committed cut per 1.5 network round trips under pipelining, not submission-to-finality latency |
| Finality | Sub-250 ms ordering finality, measured on an internal devnet (whitepaper v2.0, June 2026) |
| Throughput | More than 5 gigagas/s sustained on an internal devnet, and a separate roadmap target of 200,000 TPS for the Autobahn testnet |
| Execution | Asynchronous, after ordering finality. Block-STM-style parallel EVM with optimistic concurrency control |
| State commitment | Lattice-hash divergence digests over each block's write log (no Merkle state root on the hot path) |
| State proofs | Block Update Digests (BUDs). Proof cost scales with per-block updates, not total state size |
| Transaction ingress | No traditional public mempool. Before Sedna, complete transactions route to validator lanes. The later [Sedna](/learn/sei-giga-specs#sedna-private-dissemination) milestone introduces coded symbol bundles |
| EVM compatibility | Will be equivalent to Ethereum mainnet except EIP-4844 blobs, `PREVRANDAO`, the state root, the block gas limit, and the fee mechanism |
| Security model | Whitepaper model: BFT with `n = 3f + 1` replicas. Live implementation thresholds are stake-weighted. Under the stated assumptions, safety does not depend on network timing, and liveness requires network stabilization |
| Delivery | Phased, in-place upgrades of the live Sei network that keep the existing chain ID |

## Why does Sei Giga exist?

Giga's design goal is efficient, fast, and fair on-chain trading. This workload needs high throughput, low latency, and bounded censorship and MEV (maximal extractable value) risk. Sei Labs' [Giga announcement](https://blog.sei.io/announcements/giga/) describes the gap: Ethereum mainnet processes on the order of 100 TPS. 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](/learn/twin-turbo-consensus) already pushed the single-proposer model near its limits: approximately 400 ms blocks, [optimistic parallel execution](/learn/parallelization-engine), and [SeiDB](/learn/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 instead of blocking the next.

### Autobahn consensus

Giga will order transactions with [Autobahn](https://arxiv.org/abs/2401.10369), 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 Proof of Availability (PoA) will certify a batch after `f + 1` replica votes. Under the stated assumptions, this guarantees at least one honest holder. 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. One consensus decision can therefore 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, not a submission-to-finality guarantee. Validators will vote on compact certificates instead of downloading full blocks first.

<GigaProposerComparison />

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](/learn/sei-giga-specs#consensus-autobahn).

### Asynchronous execution and state attestation

Giga will have 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. Execution follows it, so a receipt or execution result is not available at this stage.
* State attestation finality: validators have executed the block and computed a compact divergence digest over its write log. A two-thirds voting-power quorum has also 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.

<GigaAsyncPipeline />

Execution is designed to be deterministic. Nodes that apply the same ordered transactions to the same starting state should compute the same result. Ordering continues while 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

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

* All transactions in a block will start to execute in parallel, and each will buffer its writes privately.
* A validation phase will detect conflicts (a transaction read or wrote state that an earlier-ordered transaction wrote). It will then re-execute only the conflicting transactions.
* The committed result will be identical to sequential execution in block order. 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](https://blog.sei.io/research-64-85-of-ethereum-transactions-can-be-parallelized/) this way. Contract-level guidance for maximizing parallelism is in the [developer guide](/learn/sei-giga-developers#writing-parallel-friendly-contracts).

### 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. There will be 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. Disputes will be resolved by bisecting chunked digests to find the first divergent write.
* Block Update Digests (BUDs): Merkle proofs over per-block updates will replace global state proofs. Proof cost will then scale with how much a block changed, not with the total size of the state. 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](#how-will-sei-giga-ship) 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](/learn/sei-giga-specs#storage).

## What will change from today's Sei?

| Layer | Sei today (v2) | Sei Giga |
| - | - | - |
| Block proposal | One proposer per height | Every validator will propose concurrently in its own lane |
| Consensus | [Twin Turbo Consensus](/learn/twin-turbo-consensus) (optimized Tendermint), \~400 ms | Autobahn: PoA-certified lanes with cut-of-tips ordering, effective 1.5-round-trip steady-state cadence, sub-250 ms measured ordering finality |
| Execution | Interleaved with consensus, optimistically parallel ([OCC](/learn/parallelization-engine)) | Fully asynchronous after ordering finality, with Block-STM-style OCC |
| State commitment | Merkle app hash ([SeiDB](/learn/seidb): memiavl) | Lattice-hash divergence digests attested after execution, with no Merkle root on the hot path |
| State proofs | IAVL/Merkle proofs | Block Update Digests (BUDs) with a governance-set proof window |
| Mempool | Gossiped mempool | No public gossiped mempool. Complete transactions route to lanes before Sedna. The later [Sedna](/learn/sei-giga-specs#sedna-private-dissemination) milestone adds coded-fragment ingress |
| Fee model | EIP-1559-style base fee + priority fee to the proposer | Three-part fees (1559-style execution fee, ordering fee, distribution fee), with tips socialised across validators |
| Chain surface | EVM + legacy Cosmos modules | EVM-only stack (through [SIP-3](/learn/sip-03-migration)) |

## 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](/learn/sei-giga-specs#sedna-private-dissemination) 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.

<GigaTxJourney />

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. For censorship resistance, you will be able to submit the same transaction to several validators.
2. The validator will append the transaction to its next batch and chain that batch into its lane.
3. When the batch reaches the availability threshold, it will hold a Proof of Availability, and the lane tip will advance. The threshold is `f + 1` replicas in the whitepaper model and stake-weighted in the implementation.
4. Pipelined consensus will commit a cut of all lane tips. Your transaction's position will then 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 with the deterministic tip-priority rule. It will 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.

The [developer guide](/learn/sei-giga-developers#finality-on-giga-which-signal-to-wait-for) explains which finality signal to use for each use case.

## How will Giga handle MEV and fees?

Multi-Proposer chains remove the single sequencer's private block-building monopoly. However, 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](https://arxiv.org/abs/2511.13080). 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 have no effect on the order.
* Under the proposed design, priority fees from each epoch will be pooled and distributed to validators by stake and measured liveness. They will not be paid directly to the carrying proposer. Copying a high-tip transaction into another lane would not earn an extra protocol fee. 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 on duplicate submissions. Duplicates will be dropped at merge time, and only one copy will execute. The other copies will receive a partial tip refund.
* Sedna is intended to add pre-execution privacy. Transactions will travel through [Sedna](/learn/sei-giga-specs#sedna-private-dissemination) as coded symbol bundles spread across selected lanes. The privacy guarantee will depend on the coding parameters and the number of colluding lanes.

For the full mechanism, see [MEV and fee design](/learn/sei-giga-specs#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](https://blog.sei.io/the-giga-whitepaper-2/)). The canonical tracker is [giga.seilabs.io](https://giga.seilabs.io). Status as of August 2026:

<GigaRoadmapTrack />

| Milestone | Scope | Status |
| - | - | - |
| Giga whitepaper v1 | Initial specification ([arXiv 2505.14914](https://arxiv.org/abs/2505.14914)), MEV formalization ([arXiv 2511.13080](https://arxiv.org/abs/2511.13080)) | Complete |
| Internal devnet | Geo-distributed devnet sustaining [5 gigagas/s with Autobahn](https://seiresearch.io/articles/sei-giga-achieving-5-gigagas-with-autobahn-consensus) | Complete |
| Giga whitepaper v2 | Revised spec (June 2026): sub-250 ms finality, Sedna, BUDs, fee model, post-quantum path | Complete |
| Eidos upgrade | Storage rebuild. Sei v6.6 shipped the first migration support, and node rollout and broader storage work continue | In progress (first components shipped) |
| Ares upgrade | Execution rebuild. The first phase activated in v6.6 with per-transaction v2 fallback, and broader execution work continues | In progress (first phase live) |
| SIP-3 | Pre-Giga consolidation to an EVM-only stack (see the [migration guide](/learn/sip-03-migration)) | In progress |
| Autobahn testnet | Multi-Proposer, order-first consensus with asynchronous state on a public testnet, with a target of 200,000 TPS and 400 ms finality. A final consensus whitepaper will accompany it | Coming soon |
| Autobahn mainnet | The live Sei network will upgrade to Autobahn consensus | Coming soon |
| Sedna upgrade | Private transaction dissemination (the "private mempool" milestone): transaction fragments will spread across lanes and be reassembled only after ordering | Coming soon |
| Hermes testnet | Next-generation consensus beyond Autobahn (whitepaper forthcoming) | Coming soon |
| Hermes mainnet | Hermes will merge into Sei Mainnet | Coming soon |

Sei v6.6 brought the first Ares and Eidos components to Sei Mainnet 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 and lattice-hash state commitment, and Sedna remain separate milestones or operator-gated work. Node operators should follow the [release-specific configuration reference](/node/node-operators#giga-storage-and-giga-executor) and not infer settings from roadmap status.

<Warning>
  There is no public Giga testnet yet (as of August 2026). There is therefore no separate Giga chain ID, RPC endpoint, or faucet. Anything that claims otherwise is not official. Current network endpoints remain those of [Sei Mainnet and Sei Testnet](/learn/dev-chains).
</Warning>

## Performance claims and targets

Each row gives its source and date. Devnet figures are Sei Labs' internal measurements. Consensus comparisons are whitepaper claims. Testnet figures are targets, not measurements.

| Metric | Value | Context | Source (date) |
| - | - | - | - |
| Throughput | >5 gigagas/s sustained | Internal devnet, 40 nodes across 20 regions | [Whitepaper v2.0](https://arxiv.org/abs/2505.14914) (June 2026) |
| Ordering finality | \<250 ms | Same devnet (v1 reported \<400 ms, and the Feb 2025 devnet \~700 ms across 4 regions) | Whitepaper v2.0 (June 2026) |
| Consensus cadence | 1.5 round trips (vs 3 in Tendermint) | Effective steady-state cadence under Autobahn pipelining, not per-transaction latency | Whitepaper §1.1 and §3.4 (2026) |
| Throughput vs Tendermint | >50× | Autobahn vs single-proposer Tendermint | Whitepaper §1.1 (2026). See also the [Autobahn explainer](https://blog.sei.io/autobahn-sei-gigas-multi-proposer-approach-to-blockchain-consensus) (Apr 2025) |
| Block production | \~70× (180 blocks vs 2.5) | Multi-Proposer lanes vs single proposer | Whitepaper §1.1 (2026) |
| Parallelizable EVM workload | 64.85% | Historical Ethereum transactions | [Sei research](https://blog.sei.io/research-64-85-of-ethereum-transactions-can-be-parallelized/) (2024) |
| Autobahn testnet target | 200,000 TPS, 400 ms finality | Public testnet milestone | [giga.seilabs.io](https://giga.seilabs.io) (May 2026) |

## Learn more

<CardGroup cols={2}>
  <Card horizontal title="Technical specification" icon="file-lines" href="/learn/sei-giga-specs">
    The full protocol spec: Autobahn, asynchronous execution, storage, MEV and fee design, security model, and glossary.
  </Card>

  <Card horizontal title="Developer guide" icon="code" href="/learn/sei-giga-developers">
    What will change for contracts and dApps: finality semantics, fees, proofs, and parallel-friendly patterns.
  </Card>

  <Card horizontal title="Giga whitepaper v2.0" icon="scroll" href="https://arxiv.org/abs/2505.14914">
    The canonical specification on arXiv, by Marsh, Landers, Jog, and Ranchal-Pedrosa (June 2026).
  </Card>

  <Card horizontal title="Official roadmap" icon="map" href="https://giga.seilabs.io">
    Live milestone tracker for the Giga upgrade.
  </Card>

  <Card horizontal title="SIP-3 migration" icon="arrow-right-arrow-left" href="/learn/sip-03-migration">
    The EVM-only consolidation that clears the path to Giga.
  </Card>

  <Card horizontal title="Today's architecture" icon="clock-rotate-left" href="/learn/twin-turbo-consensus">
    Twin Turbo Consensus, the parallelization engine, and SeiDB: the system that Giga will replace.
  </Card>
</CardGroup>

<Warning>
  **Disclaimer:** The roadmap is subject to change based on development progress, market feedback, and other factors. Actual timelines, figures, and outcomes may vary.
</Warning>

*Last updated August 2026*


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.