> ## Documentation Index
> Fetch the complete documentation index at: https://seilabs-docs-bridge-release-v6-6-3.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 = '#10b981';
  const prog = '#f59e0b';
  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-500 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-gold-25)';
  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-500 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-gold-25)';
  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-500 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-500 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 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.

<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 Pacific-1 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; 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 rather than total state size                                                                                                                   |
| Transaction ingress | No traditional public mempool; complete transactions route to validator lanes before Sedna, while 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; liveness requires network stabilization |
| Delivery            | Phased, in-place upgrades of the live Sei network, keeping the existing chain ID                                                                                                                                     |

## 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](https://blog.sei.io/announcements/giga/) 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](/learn/twin-turbo-consensus) already pushed the single-proposer model near its limits: \~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 rather than 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 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.

<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 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.

<GigaAsyncPipeline />

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](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, 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](#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](/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; 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, with coded-fragment ingress added by the later [Sedna](/learn/sei-giga-specs#sedna-private-dissemination) milestone |
| Fee model        | EIP-1559-style base fee + priority fee to the proposer                                     | Three-part fees: 1559-style execution fee, ordering fee, distribution fee; tips socialised across validators                                                                                       |
| Chain surface    | EVM + legacy Cosmos modules                                                                | Streamlined EVM-only stack (via [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, 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](/learn/sei-giga-developers#finality-on-giga-which-signal-to-wait-for).

## 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](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 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](/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.

The full mechanism is specified in [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; v6.6 shipped the first migration support, with node rollout and broader storage work continuing                                                              | In progress (first components shipped) |
| Ares upgrade       | Execution rebuild; first phase activated in v6.6 with per-transaction v2 fallback, with broader execution work continuing                                                     | In progress (first phase live)         |
| SIP-3              | Pre-Giga consolidation to a streamlined 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, targeting 200,000 TPS with 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 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](/node/node-operators#giga-storage-and-giga-executor) rather than infer settings from roadmap status.

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

## 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.

| 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; 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 apps: 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 (Marsh, Landers, Jog, 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 Giga will supersede.
  </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*