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

# Sei Giga Technical Specification

> The Sei Giga protocol specification: Autobahn consensus with per-validator lanes and whitepaper f+1 Proofs of Availability, asynchronous execution, Block-STM parallel EVM, flat lattice-hashed storage, BUD state proofs, fee design, and the security model.

export const GigaMergeRule = () => {
  const ink = 'currentColor';
  const accent = 'var(--sei-maroon-50)';
  const lanesIn = [{
    v: 'V1',
    max: 12,
    txs: [{
      n: 'a',
      t: 12
    }, {
      n: 'e',
      t: 8,
      dup: true
    }]
  }, {
    v: 'V2',
    max: 40,
    txs: [{
      n: 'c',
      t: 40
    }, {
      n: 'd',
      t: 9
    }]
  }, {
    v: 'V3',
    max: 20,
    txs: [{
      n: 'f',
      t: 20
    }, {
      n: 'e',
      t: 8
    }]
  }];
  const sorted = [1, 2, 0];
  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 880 300" role="img" aria-label="Tip-priority merge rule: sort lanes by highest tip, keep intra-lane order, deduplicate" style={{
    width: '100%',
    minWidth: 640,
    height: 'auto',
    display: 'block'
  }}>
          <defs>
            <marker id="gmr-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>
          <text x={60} y={34} fontSize="11" fontWeight="600" fill={ink}>new transactions per lane</text>
          {lanesIn.map((ln, i) => <g key={ln.v}>
              <text x={74} y={72 + i * 56} fontSize="10.5" textAnchor="middle" fill={ink} fillOpacity="0.8">{ln.v}</text>
              <text x={74} y={86 + i * 56} fontSize="8.5" textAnchor="middle" fill={ink} fillOpacity="0.5">max {ln.max}</text>
              {ln.txs.map((tx, j) => <g key={ln.v + tx.n}>
                  <rect x={100 + j * 92} y={54 + i * 56} width={80} height={30} rx={6} fill={ink} fillOpacity="0.05" stroke={ink} strokeOpacity="0.45" />
                  <text x={140 + j * 92} y={73 + i * 56} fontSize="10" textAnchor="middle" fill={ink}>{tx.n} · tip {tx.t}</text>
                </g>)}
            </g>)}
          <line x1={300} y1={122} x2={352} y2={122} stroke={ink} strokeOpacity="0.5" strokeWidth="1.2" markerEnd="url(#gmr-a)" />
          <text x={326} y={110} fontSize="9.5" textAnchor="middle" fill={ink} fillOpacity="0.7">1. sort lanes</text>
          <text x={326} y={136} fontSize="9.5" textAnchor="middle" fill={ink} fillOpacity="0.7">by max tip</text>

          <text x={366} y={34} fontSize="11" fontWeight="600" fill={ink}>lane order: V2, V3, V1</text>
          {sorted.map((li, i) => <g key={'s' + li}>
              <text x={382} y={72 + i * 56} fontSize="10.5" textAnchor="middle" fill={accent} fontWeight="600">{i + 1}</text>
              {lanesIn[li].txs.map((tx, j) => <g key={'s' + li + tx.n}>
                  <rect x={404 + j * 92} y={54 + i * 56} width={80} height={30} rx={6} fill={accent} fillOpacity="0.08" stroke={accent} strokeOpacity="0.7" />
                  <text x={444 + j * 92} y={73 + i * 56} fontSize="10" textAnchor="middle" fill={ink}>{lanesIn[li].v}: {tx.n}</text>
                </g>)}
            </g>)}
          <text x={490} y={218} fontSize="9.5" textAnchor="middle" fill={ink} fillOpacity="0.7">2. intra-lane order preserved</text>

          <line x1={608} y1={122} x2={652} y2={122} stroke={ink} strokeOpacity="0.5" strokeWidth="1.2" markerEnd="url(#gmr-a)" />
          <text x={630} y={110} fontSize="9.5" textAnchor="middle" fill={ink} fillOpacity="0.7">3. dedupe</text>
          <text x={666} y={34} fontSize="11" fontWeight="600" fill={ink}>executable sequence</text>
          {['c', 'd', 'f', 'e', 'a', 'e'].map((n, i) => {
    const dup = i === 5;
    return <g key={'r' + i}>
                <rect x={666} y={48 + i * 36} width={150} height={28} rx={6} fill={dup ? 'none' : ink} fillOpacity={dup ? 0 : 0.05} stroke={dup ? accent : ink} strokeOpacity={dup ? 0.7 : 0.45} strokeDasharray={dup ? '4 3' : 'none'} />
                <text x={741} y={66 + i * 36} fontSize="10" textAnchor="middle" fill={ink} fillOpacity={dup ? 0.5 : 1} textDecoration={dup ? 'line-through' : 'none'}>{i + 1}. {n}{dup ? ' (duplicate hash)' : ''}</text>
              </g>;
  })}
          <text x={741} y={276} fontSize="9" textAnchor="middle" fill={ink} fillOpacity="0.6">dropped copy gets a partial tip refund</text>
        </svg>
      </div>
      <div className="mt-2 text-xs text-neutral-600 dark:text-neutral-400">The merged order will be a pure function of finalized lane contents. Lanes will sort by their highest included tip, order inside each lane will not change, and the first occurrence of a hash will win.</div>
    </div>;
};

export const GigaBudWindow = () => {
  const ink = 'currentColor';
  const accent = 'var(--sei-maroon-50)';
  const gold = 'var(--sei-diagram-gold, var(--sei-gold-100))';
  const leaves = ['(key a, value, n, prev)', '(key b, value, n, prev)', '(key c, value, n, prev)'];
  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 260" role="img" aria-label="Block Update Digests: per-block Merkle roots aggregated into SuperBUD windows" style={{
    width: '100%',
    minWidth: 620,
    height: 'auto',
    display: 'block'
  }}>
          <defs>
            <marker id="gbw-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>
          {leaves.map((l, i) => <g key={l}>
              <rect x={56} y={36 + i * 34} width={170} height={26} rx={5} fill={ink} fillOpacity="0.05" stroke={ink} strokeOpacity="0.4" />
              <text x={141} y={53 + i * 34} fontSize="9" textAnchor="middle" fill={ink} fillOpacity="0.85" fontFamily="var(--sei-font-mono)">{l}</text>
              <line x1={226} y1={49 + i * 34} x2={262} y2={83} stroke={ink} strokeOpacity="0.4" strokeWidth="1" />
            </g>)}
          <text x={141} y={148} fontSize="9.5" textAnchor="middle" fill={ink} fillOpacity="0.6">this block's writes, sorted by key</text>
          <rect x={264} y={68} width={92} height={32} rx={6} fill={accent} fillOpacity="0.12" stroke={accent} strokeWidth="1.2" />
          <text x={310} y={88} fontSize="10.5" textAnchor="middle" fill={ink}>root U_n</text>
          <line x1={356} y1={84} x2={392} y2={84} stroke={ink} strokeOpacity="0.5" strokeWidth="1.1" markerEnd="url(#gbw-a)" />
          <rect x={396} y={62} width={170} height={44} rx={7} fill={gold} fillOpacity="0.16" stroke={gold} strokeWidth="1.1" />
          <text x={481} y={81} fontSize="10" textAnchor="middle" fill={ink}>attested with D_n</text>
          <text x={481} y={97} fontSize="9" textAnchor="middle" fill={ink} fillOpacity="0.65">same 2/3 voting-power schedule</text>
          <rect x={598} y={54} width={222} height={60} rx={7} fill={ink} fillOpacity="0.04" stroke={ink} strokeOpacity="0.35" strokeDasharray="4 3" />
          <text x={709} y={76} fontSize="9.5" textAnchor="middle" fill={ink} fillOpacity="0.8">proof = Merkle path to attested U_n;</text>
          <text x={709} y={91} fontSize="9.5" textAnchor="middle" fill={ink} fillOpacity="0.8">two proofs bracket an unmodified span</text>
          <text x={709} y={106} fontSize="9.5" textAnchor="middle" fill={ink} fillOpacity="0.8">cost scales with the block's updates</text>

          <line x1={56} y1={196} x2={830} y2={196} stroke={ink} strokeOpacity="0.4" strokeWidth="1" markerEnd="url(#gbw-a)" />
          {Array.from({
    length: 17
  }, (_, i) => <line key={'t' + i} x1={70 + i * 46} y1={192} x2={70 + i * 46} y2={200} stroke={ink} strokeOpacity="0.45" strokeWidth="1" />)}
          <text x={70} y={214} fontSize="9" fill={ink} fillOpacity="0.55">blocks</text>
          {[0, 1, 2, 3].map(i => <path key={'w1' + i} d={`M ${70 + i * 184} 186 L ${70 + i * 184} 180 L ${208 + i * 184} 180 L ${208 + i * 184} 186`} fill="none" stroke={accent} strokeWidth="1.2" />)}
          <text x={139} y={172} fontSize="9" textAnchor="middle" fill={accent}>SuperBUD, e blocks</text>
          <path d="M 70 162 L 70 154 L 806 154 L 806 162" fill="none" stroke={accent} strokeOpacity="0.7" strokeWidth="1.2" strokeDasharray="5 4" />
          <text x={438} y={146} fontSize="9.5" textAnchor="middle" fill={ink} fillOpacity="0.75">guaranteed proof window: the last e^Lmax blocks (governance-set); older claims need archive nodes</text>
          <text x={520} y={232} fontSize="9.5" textAnchor="middle" fill={ink} fillOpacity="0.6">touch transactions refresh a stale key's anchor; deletions leave tombstones for exclusion proofs</text>
        </svg>
      </div>
      <div className="mt-2 text-xs text-neutral-600 dark:text-neutral-400">Every block will get a Merkle root over only its own updates. SuperBUDs will aggregate those roots over exponentially sized windows so provers can cover long ranges with a few digests.</div>
    </div>;
};

export const GigaStorageArchitecture = () => {
  const ink = 'currentColor';
  const accent = 'var(--sei-maroon-50)';
  const gold = 'var(--sei-diagram-gold, var(--sei-gold-100))';
  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 880 300" role="img" aria-label="Giga storage: RAM-first flat key-value state with WAL, tiers, and lattice-hash commitments" style={{
    width: '100%',
    minWidth: 640,
    height: 'auto',
    display: 'block'
  }}>
          <defs>
            <marker id="gsa-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>
          <text x={200} y={32} fontSize="12" fontWeight="600" textAnchor="middle" fill={ink}>state path</text>
          <rect x={60} y={44} width={280} height={40} rx={7} fill={accent} fillOpacity="0.1" stroke={accent} strokeWidth="1.1" />
          <text x={200} y={69} fontSize="10.5" textAnchor="middle" fill={ink}>execution: reads served from RAM</text>
          <line x1={200} y1={84} x2={200} y2={106} stroke={ink} strokeOpacity="0.45" strokeWidth="1.1" markerEnd="url(#gsa-a)" />
          <rect x={60} y={110} width={280} height={44} rx={7} fill={ink} fillOpacity="0.05" stroke={ink} strokeOpacity="0.45" />
          <text x={200} y={129} fontSize="10.5" textAnchor="middle" fill={ink}>flat key-value store (LSM tree)</text>
          <text x={200} y={145} fontSize="9" textAnchor="middle" fill={ink} fillOpacity="0.6">no per-write Merkle updates</text>
          <rect x={372} y={110} width={140} height={44} rx={7} fill={ink} fillOpacity="0.04" stroke={ink} strokeOpacity="0.35" strokeDasharray="4 3" />
          <text x={442} y={129} fontSize="10" textAnchor="middle" fill={ink}>append-only WAL</text>
          <text x={442} y={145} fontSize="9" textAnchor="middle" fill={ink} fillOpacity="0.6">crash recovery</text>
          <line x1={340} y1={132} x2={368} y2={132} stroke={ink} strokeOpacity="0.45" strokeWidth="1.1" markerEnd="url(#gsa-a)" strokeDasharray="3 3" />
          <text x={354} y={122} fontSize="8.5" textAnchor="middle" fill={ink} fillOpacity="0.55">async</text>
          <line x1={200} y1={154} x2={200} y2={176} stroke={ink} strokeOpacity="0.45" strokeWidth="1.1" markerEnd="url(#gsa-a)" />
          <rect x={60} y={180} width={280} height={40} rx={7} fill={ink} fillOpacity="0.05" stroke={ink} strokeOpacity="0.45" />
          <text x={200} y={200} fontSize="10.5" textAnchor="middle" fill={ink}>hot tier: local high-performance SSDs</text>
          <line x1={200} y1={220} x2={200} y2={242} stroke={ink} strokeOpacity="0.45" strokeWidth="1.1" markerEnd="url(#gsa-a)" strokeDasharray="3 3" />
          <rect x={60} y={246} width={280} height={40} rx={7} fill={ink} fillOpacity="0.03" stroke={ink} strokeOpacity="0.3" strokeDasharray="4 3" />
          <text x={200} y={266} fontSize="10.5" textAnchor="middle" fill={ink} fillOpacity="0.85">cold tier: distributed columnar store</text>

          <text x={690} y={32} fontSize="12" fontWeight="600" textAnchor="middle" fill={ink}>commitment path</text>
          <rect x={580} y={44} width={220} height={40} rx={7} fill={ink} fillOpacity="0.05" stroke={ink} strokeOpacity="0.45" />
          <text x={690} y={69} fontSize="10.5" textAnchor="middle" fill={ink}>write log of block n</text>
          <line x1={690} y1={84} x2={690} y2={106} stroke={ink} strokeOpacity="0.45" strokeWidth="1.1" markerEnd="url(#gsa-a)" />
          <rect x={580} y={110} width={220} height={44} rx={7} fill={accent} fillOpacity="0.1" stroke={accent} strokeWidth="1.1" />
          <text x={690} y={129} fontSize="10.5" textAnchor="middle" fill={ink}>lattice hash d_n (LtHash)</text>
          <text x={690} y={145} fontSize="9" textAnchor="middle" fill={ink} fillOpacity="0.6">incremental, order-independent</text>
          <line x1={690} y1={154} x2={690} y2={176} stroke={ink} strokeOpacity="0.45" strokeWidth="1.1" markerEnd="url(#gsa-a)" />
          <rect x={580} y={180} width={220} height={40} rx={7} fill={gold} fillOpacity="0.16" stroke={gold} strokeWidth="1.1" />
          <text x={690} y={205} fontSize="10.5" textAnchor="middle" fill={ink}>D_n attested by 2/3 voting power</text>
          <rect x={580} y={246} width={220} height={40} rx={7} fill={ink} fillOpacity="0.03" stroke={ink} strokeOpacity="0.3" strokeDasharray="4 3" />
          <text x={690} y={262} fontSize="9.5" textAnchor="middle" fill={ink} fillOpacity="0.75">disputes: compare chunk digests,</text>
          <text x={690} y={276} fontSize="9.5" textAnchor="middle" fill={ink} fillOpacity="0.75">bisect, replay one range</text>
        </svg>
      </div>
      <div className="mt-2 text-xs text-neutral-600 dark:text-neutral-400">In the proposed architecture, the write path avoids Merkle-tree updates. State lives in a RAM-first flat store with an append-only WAL. Commitments come from a homomorphic lattice hash over each block's write log.</div>
    </div>;
};

export const GigaOccDiagram = () => {
  const ink = 'currentColor';
  const accent = 'var(--sei-maroon-50)';
  const workers = ['worker 1', 'worker 2', 'worker 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 268" role="img" aria-label="Block-STM optimistic concurrency: parallel execution with conflict re-execution" style={{
    width: '100%',
    minWidth: 620,
    height: 'auto',
    display: 'block'
  }}>
          <defs>
            <marker id="goc-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={accent} />
            </marker>
          </defs>
          {workers.map((w, i) => <g key={w}>
              <text x={104} y={72 + i * 62} fontSize="11" textAnchor="end" fill={ink} fillOpacity="0.75">{w}</text>
              <line x1={116} y1={68 + i * 62} x2={620} y2={68 + i * 62} stroke={ink} strokeOpacity="0.12" strokeWidth="1" />
            </g>)}
          <rect x={126} y={50} width={120} height={34} rx={6} fill={ink} fillOpacity="0.06" stroke={ink} strokeOpacity="0.45" />
          <text x={186} y={71} fontSize="10.5" textAnchor="middle" fill={ink}>t1</text>
          <rect x={126} y={112} width={120} height={34} rx={6} fill={ink} fillOpacity="0.06" stroke={ink} strokeOpacity="0.45" />
          <text x={186} y={133} fontSize="10.5" textAnchor="middle" fill={ink}>t2 writes k</text>
          <rect x={126} y={174} width={180} height={34} rx={6} fill={ink} fillOpacity="0.06" stroke={ink} strokeOpacity="0.45" />
          <text x={216} y={195} fontSize="10.5" textAnchor="middle" fill={ink}>t3</text>
          <rect x={286} y={50} width={120} height={34} rx={6} fill={accent} fillOpacity="0.08" stroke={accent} strokeOpacity="0.8" strokeDasharray="4 3" />
          <text x={346} y={71} fontSize="10.5" textAnchor="middle" fill={ink} fillOpacity="0.85">t4 reads k</text>
          <rect x={286} y={112} width={120} height={34} rx={6} fill={ink} fillOpacity="0.06" stroke={ink} strokeOpacity="0.45" />
          <text x={346} y={133} fontSize="10.5" textAnchor="middle" fill={ink}>t5</text>
          <path d="M 250 129 Q 300 96 330 88" fill="none" stroke={accent} strokeWidth="1.4" strokeDasharray="4 3" markerEnd="url(#goc-a)" />
          <text x={300} y={104} fontSize="9" fill={accent}>conflict</text>
          <path d="M 406 67 Q 446 40 470 58" fill="none" stroke={accent} strokeWidth="1.4" markerEnd="url(#goc-a)" />
          <rect x={470} y={50} width={130} height={34} rx={6} fill={accent} fillOpacity="0.14" stroke={accent} strokeWidth="1.3" />
          <text x={535} y={71} fontSize="10.5" textAnchor="middle" fill={ink}>t4 re-executes</text>
          <text x={452} y={30} fontSize="9.5" fill={ink} fillOpacity="0.6">validation caught the stale read</text>

          <line x1={636} y1={128} x2={664} y2={128} stroke={ink} strokeOpacity="0.5" strokeWidth="1.1" markerEnd="url(#goc-a)" />
          <rect x={668} y={92} width={172} height={72} rx={8} fill={ink} fillOpacity="0.04" stroke={ink} strokeOpacity="0.4" />
          <text x={754} y={117} fontSize="10.5" textAnchor="middle" fill={ink}>commit in block order</text>
          <text x={754} y={133} fontSize="9.5" textAnchor="middle" fill={ink} fillOpacity="0.65">result identical to</text>
          <text x={754} y={147} fontSize="9.5" textAnchor="middle" fill={ink} fillOpacity="0.65">sequential execution</text>

          <text x={126} y={244} fontSize="9.5" fill={ink} fillOpacity="0.6">only conflicting transactions re-run; after 10 retries the implementation falls back to sequential execution</text>
        </svg>
      </div>
      <div className="mt-2 text-xs text-neutral-600 dark:text-neutral-400">All transactions in a block will start in parallel with private write buffers. Validation will re-execute only those whose reads collided with an earlier transaction's writes.</div>
    </div>;
};

export const GigaAttestationFlow = () => {
  const ink = 'currentColor';
  const accent = 'var(--sei-maroon-50)';
  const gold = 'var(--sei-diagram-gold, var(--sei-gold-100))';
  const blocks = ['n-1', 'n', 'n+1', 'n+2', 'n+x'];
  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 880 288" role="img" aria-label="Divergence digest of block n is attested inside a later block" style={{
    width: '100%',
    minWidth: 640,
    height: 'auto',
    display: 'block'
  }}>
          <defs>
            <marker id="gaf-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="gaf-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={gold} />
            </marker>
          </defs>
          {blocks.map((b, i) => <g key={b}>
              <rect x={64 + i * 158} y={44} width={104} height={42} rx={7} fill={i === 1 ? accent : ink} fillOpacity={i === 1 ? 0.14 : 0.05} stroke={i === 1 ? accent : ink} strokeOpacity={i === 1 ? 0.9 : 0.4} strokeWidth={i === 1 ? 1.4 : 1} />
              <text x={116 + i * 158} y={69} fontSize="11" textAnchor="middle" fill={ink}>block {b}</text>
              {i < blocks.length - 1 ? <line x1={168 + i * 158} y1={65} x2={218 + i * 158} y2={65} stroke={ink} strokeOpacity="0.45" strokeWidth="1.1" markerEnd="url(#gaf-a)" strokeDasharray={i === 3 ? '3 4' : 'none'} /> : null}
            </g>)}
          <text x={116 + 158} y={34} fontSize="9.5" textAnchor="middle" fill={accent} fontWeight="600">ordering final</text>

          <line x1={274} y1={86} x2={274} y2={120} stroke={ink} strokeOpacity="0.45" strokeWidth="1.1" markerEnd="url(#gaf-a)" />
          {[{
    x: 96,
    label: 'execute block n',
    sub: 'deterministic Apply'
  }, {
    x: 296,
    label: 'write log',
    sub: 'last write wins'
  }, {
    x: 496,
    label: 'd_n = LtHash(...)',
    sub: 'writes, receipts, gas'
  }].map((s, i) => <g key={s.label}>
              <rect x={s.x} y={124} width={168} height={48} rx={8} fill={ink} fillOpacity="0.05" stroke={ink} strokeOpacity="0.4" />
              <text x={s.x + 84} y={144} fontSize="10.5" textAnchor="middle" fill={ink}>{s.label}</text>
              <text x={s.x + 84} y={160} fontSize="9" textAnchor="middle" fill={ink} fillOpacity="0.6">{s.sub}</text>
              {i < 2 ? <line x1={s.x + 168} y1={148} x2={s.x + 196} y2={148} stroke={ink} strokeOpacity="0.5" strokeWidth="1.1" markerEnd="url(#gaf-a)" /> : null}
            </g>)}
          <line x1={664} y1={148} x2={692} y2={148} stroke={ink} strokeOpacity="0.5" strokeWidth="1.1" markerEnd="url(#gaf-a)" />
          <rect x={696} y={124} width={128} height={48} rx={8} fill={gold} fillOpacity="0.18" stroke={gold} strokeWidth="1.2" />
          <text x={760} y={144} fontSize="10.5" textAnchor="middle" fill={ink}>digest D_n</text>
          <text x={760} y={160} fontSize="9" textAnchor="middle" fill={ink} fillOpacity="0.65">compact commitment</text>
          <path d="M 760 122 Q 762 96 736 88" fill="none" stroke={gold} strokeWidth="1.4" strokeDasharray="4 3" markerEnd="url(#gaf-b)" />
          <text x={810} y={100} fontSize="9.5" textAnchor="middle" fill={ink} fillOpacity="0.75">2/3 voting power, included</text>
          <text x={810} y={113} fontSize="9.5" textAnchor="middle" fill={ink} fillOpacity="0.75">in block n+x</text>

          <rect x={96} y={210} width={728} height={52} rx={8} fill={ink} fillOpacity="0.03" stroke={ink} strokeOpacity="0.25" strokeDasharray="4 3" />
          <text x={460} y={231} fontSize="10" textAnchor="middle" fill={ink} fillOpacity="0.75">signing two different digests for the same block is slashable equivocation;</text>
          <text x={460} y={247} fontSize="10" textAnchor="middle" fill={ink} fillOpacity="0.75">divergence under 1/3 of voting power can be isolated; over 1/3 is designed to halt the chain</text>
        </svg>
      </div>
      <div className="mt-2 text-xs text-neutral-600 dark:text-neutral-400">Execution results will be committed as a lattice-hash digest rather than a state root. Validators will attest to that digest a bounded number of blocks later.</div>
    </div>;
};

export const GigaSlotPipeline = () => {
  const ink = 'currentColor';
  const accent = 'var(--sei-maroon-50)';
  const slots = [0, 1, 2];
  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 238" role="img" aria-label="Pipelined consensus slots with prepare and commit phases" style={{
    width: '100%',
    minWidth: 620,
    height: 'auto',
    display: 'block'
  }}>
          <defs>
            <marker id="gsp-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>
          {slots.map(i => {
    const x = 130 + i * 105;
    const y = 46 + i * 50;
    return <g key={'s' + i}>
                <text x={x - 12} y={y + 20} fontSize="11" textAnchor="end" fill={ink} fillOpacity="0.75">slot s{i > 0 ? '+' + i : ''}</text>
                <rect x={x} y={y} width={210} height={30} rx={5} fill={accent} fillOpacity="0.16" stroke={accent} strokeWidth="1" />
                <text x={x + 105} y={y + 19} fontSize="10" textAnchor="middle" fill={ink}>Prepare (PrepareQC)</text>
                <rect x={x + 210} y={y} width={210} height={30} rx={5} fill={ink} fillOpacity="0.05" stroke={ink} strokeOpacity="0.4" strokeWidth="1" />
                <text x={x + 315} y={y + 19} fontSize="10" textAnchor="middle" fill={ink} fillOpacity="0.85">Commit (CommitQC)</text>
              </g>;
  })}
          <line x1={235} y1={40} x2={235} y2={182} stroke={ink} strokeOpacity="0.3" strokeWidth="1" strokeDasharray="3 3" />
          <text x={640} y={36} fontSize="9.5" textAnchor="middle" fill={ink} fillOpacity="0.6">next slot starts once the Prepare message for s is seen</text>

          <line x1={130} y1={196} x2={340} y2={196} stroke={ink} strokeOpacity="0.5" strokeWidth="1" markerStart="url(#gsp-a)" markerEnd="url(#gsp-a)" />
          <text x={235} y={212} fontSize="9.5" textAnchor="middle" fill={ink} fillOpacity="0.7">1 round trip</text>
          <line x1={340} y1={196} x2={445} y2={196} stroke={accent} strokeWidth="1.4" markerEnd="url(#gsp-a)" />
          <text x={392} y={212} fontSize="9.5" textAnchor="middle" fill={accent} fontWeight="600">+0.5 effective</text>
          <text x={630} y={208} fontSize="10.5" textAnchor="middle" fill={ink} fillOpacity="0.8">steady state: one cut per 1.5 round trips</text>
        </svg>
      </div>
      <div className="mt-2 text-xs text-neutral-600 dark:text-neutral-400">Slots will overlap: replicas will begin slot s+1 as soon as they see the Prepare message for slot s. The target is an effective steady-state cadence of one committed cut per 1.5 network round trips, not per-transaction latency.</div>
    </div>;
};

export const GigaLanesAndCuts = () => {
  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];
  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 880 300" role="img" aria-label="Lanes of chained proposals certified by Proofs of Availability, committed as a cut of tips" style={{
    width: '100%',
    minWidth: 640,
    height: 'auto',
    display: 'block'
  }}>
          <defs>
            <marker id="glc-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="glc-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>
          <rect x={112} y={48} width={386} height={216} rx={10} fill={accent} fillOpacity="0.045" />
          <text x={118} y={40} fontSize="10" fill={ink} fillOpacity="0.55">committing a tip implicitly commits everything behind it</text>
          {lanes.map(i => <g key={'ln' + i}>
              <circle cx={74} cy={92 + i * 72} r={15} fill={accent} fillOpacity="0.85" />
              <text x={74} y={96 + i * 72} fontSize="10.5" textAnchor="middle" fill="#fff">V{i + 1}</text>
              {[0, 1, 2, 3].map(j => <g key={'p' + i + j}>
                  <rect x={124 + j * 96} y={74 + i * 72} width={72} height={36} rx={6} {...box} stroke={j === 3 ? accent : ink} strokeOpacity={j === 3 ? 0.95 : 0.35} strokeWidth={j === 3 ? 1.4 : 1} />
                  <text x={160 + j * 96} y={90 + i * 72} fontSize="9.5" textAnchor="middle" fill={ink} fillOpacity="0.8">pos {j}</text>
                  <text x={160 + j * 96} y={103 + i * 72} fontSize="8.5" textAnchor="middle" fill={ink} fillOpacity="0.5">batch</text>
                  {j < 3 ? <line x1={196 + j * 96} y1={92 + i * 72} x2={218 + j * 96} y2={92 + i * 72} stroke={ink} strokeOpacity="0.5" strokeWidth="1.1" markerEnd="url(#glc-a)" /> : null}
                </g>)}
              <text x={472} y={70 + i * 72} fontSize="9" textAnchor="middle" fill={accent}>tip</text>
            </g>)}
          <text x={252} y={286} fontSize="9.5" fill={ink} fillOpacity="0.55">arrows: parentRef hash-chains each proposal to its predecessor</text>

          <g>
            <rect x={520} y={62} width={128} height={58} rx={8} fill={ink} fillOpacity="0.05" stroke={ink} strokeOpacity="0.4" />
            <text x={584} y={84} fontSize="10.5" textAnchor="middle" fill={ink}>paper: f + 1 replicas</text>
            <text x={584} y={100} fontSize="9.5" textAnchor="middle" fill={ink} fillOpacity="0.65">stake-weighted in implementation</text>
            <line x1={520} y1={91} x2={500} y2={91} stroke={ink} strokeOpacity="0.5" strokeWidth="1.1" markerEnd="url(#glc-a)" />
          </g>

          <line x1={490} y1={56} x2={490} y2={252} stroke={accent} strokeWidth="1.6" strokeDasharray="6 4" />
          <text x={490} y={270} fontSize="10" textAnchor="middle" fill={accent} fontWeight="600">cut = [tip 1, tip 2, tip 3]</text>
          <line x1={498} y1={166} x2={532} y2={166} stroke={accent} strokeWidth="1.6" markerEnd="url(#glc-b)" />
          <rect x={536} y={140} width={188} height={52} rx={8} fill={accent} fillOpacity="0.09" stroke={accent} strokeWidth="1.2" />
          <text x={630} y={162} fontSize="10.5" textAnchor="middle" fill={ink}>committed in one slot</text>
          <text x={630} y={178} fontSize="9.5" textAnchor="middle" fill={ink} fillOpacity="0.65">Prepare, then Commit</text>
          <rect x={536} y={206} width={296} height={46} rx={8} fill={ink} fillOpacity="0.04" stroke={ink} strokeOpacity="0.3" strokeDasharray="4 3" />
          <text x={684} y={225} fontSize="9.5" textAnchor="middle" fill={ink} fillOpacity="0.7">missing batch data is fetched after commit,</text>
          <text x={684} y={239} fontSize="9.5" textAnchor="middle" fill={ink} fillOpacity="0.7">off the critical path</text>
        </svg>
      </div>
      <div className="mt-2 text-xs text-neutral-600 dark:text-neutral-400">Each validator will chain batches into its own lane. The whitepaper uses f + 1 replica votes for availability. The implementation applies stake-weighted thresholds.</div>
    </div>;
};

This page specifies the Sei Giga protocol as defined in the [Giga whitepaper v2.0](https://arxiv.org/abs/2505.14914) by Marsh, Landers, Jog, and Ranchal-Pedrosa (June 2026). It also includes implementation notes from the [sei-chain](https://github.com/sei-protocol/sei-chain) v6.6 release and its Sei Mainnet activation (August 2026). 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](/learn/sei-giga). For practical guidance, see the [developer guide](/learn/sei-giga-developers).

## Protocol at a glance

| Property | Specification |
| - | - |
| Chain type | Permissionless Proof-of-Stake EVM Layer 1. SEI will remain the native gas, fee, and staking asset |
| Fault model | Whitepaper model: `n = 3f + 1` replicas, up to `f` faulty. The implementation weights votes by stake |
| Synchrony assumption | Partial synchrony: under the stated fault and cryptographic assumptions, safety does not depend on network timing. Liveness resumes after network stabilization |
| Consensus | Autobahn: per-validator data lanes with leader-driven cut-of-tips ordering |
| Data availability quorum | Whitepaper: `f + 1` replica votes (Proof of Availability). Implementation thresholds are stake-weighted |
| Ordering quorum | Whitepaper: `n - f` prepare/commit votes. Implementation thresholds are stake-weighted |
| Consensus cadence | Effective steady-state cadence of one committed cut per 1.5 network round trips under pipelining, not submission-to-finality latency |
| Execution | Asynchronous, post-ordering, and deterministic, with Block-STM-style optimistic concurrency control |
| State attestation | Two-thirds voting-power signatures over per-block lattice-hash divergence digests, included in a later block |
| State commitment | Homomorphic multiset hash (LtHash) over the block write log, with no Merkle state root on the hot path |
| State proofs | Block Update Digests (BUDs) + SuperBUDs, governance-configurable proof window |
| Transaction ingress | No traditional public mempool. Before Sedna, complete transactions route to validator lanes. The later [Sedna](#sedna-private-dissemination) milestone introduces coded symbol bundles |
| Transaction encoding | Flat, length-prefixed, single-pass zero-copy decoding (not RLP) |
| EVM compatibility | Ethereum-equivalent except EIP-4844, `PREVRANDAO`, state root, block gas limit, fee mechanism |
| Fee model | Three-part: EIP-1559-style execution fee + ordering fee (priority) + distribution fee (duplicates) |
| Measured performance | >5 gigagas/s, sub-250 ms ordering finality (internal devnet of 40 nodes across 20 regions, reported in whitepaper v2.0, June 2026) |

## 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. When you reason about the live network, do not interpret `f` as a raw validator count. 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 when 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. This is because quorum intersection guarantees that at least one honest validator would have to sign both.
* Censorship resistance: when a proposal reaches the availability threshold, at least one honest replica stores its data under the stated assumptions. The threshold is `f + 1` replicas in the whitepaper model and stake-weighted in the implementation. A correct leader must then include the proposal 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](#mev-and-fee-design), 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. For today's staking parameters, see [Staking](/learn/general-staking).

## Consensus: Autobahn

Sei Giga will order transactions with [Autobahn](https://arxiv.org/abs/2401.10369) (Giridharan, Suri-Payer, Abraham, Alvisi, and Crooks, 2024), a BFT protocol that decouples data dissemination from ordering. The paper positions it between view-based and DAG-based protocols. View-based protocols (HotStuff, Tendermint) can stall during network "blips." DAG-based protocols (Narwhal-style) 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`. Here, `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 that it extends the lane correctly and return a signed vote over its digest. When 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 enough because any such quorum contains at least one correct replica that held the full data when it voted. That replica serves the data until all correct replicas have it. Giga's design deliberately keeps the smaller quorum (instead of `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 that holds 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. Earlier entries do not need to be certified again.

<GigaLanesAndCuts />

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 instead of 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. At `n - f` votes, these votes form a PrepareQC.
2. Commit. Replicas will exchange commit votes over the PrepareQC. In the whitepaper's replica-count model, a CommitQC formed from `n - f` votes finalizes the cut.
3. Pipelining. Slots will overlap. As soon as replicas see the Prepare message for slot `s`, they can begin slot `s + 1`. 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. Tendermint uses three full rounds. This cadence is not a per-transaction finality guarantee.

<GigaSlotPipeline />

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. For this reason, 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. This confines 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](https://arxiv.org/abs/2606.25099)) replaces the timeout race with a "protocol-rigged race" among replicas. Non-leader replicas do useful persistence work in parallel on candidate cuts built from the same certified tips. If a leader is only slow (I/O contention, garbage collection, routing trouble), the slot can finish from existing recovery state. It does not have to wait for a full timeout. Ambulance is planned as a core part of a future upgrade.
* Hermes is a next-generation consensus protocol on the [official roadmap](https://giga.seilabs.io). Its whitepaper has not been published yet.

## Execution

### Two finality notions

Giga will separate what consensus decides from what execution produces:

| Finality | Definition | When it holds |
| - | - | - |
| Ordering finality | Consensus has finalized the unique total order of transactions induced by a committed cut | Sub-250 ms, measured on an internal devnet (not submission-to-receipt latency) |
| State attestation finality | A later finalized block includes a valid two-thirds voting-power attestation of the block's divergence digest | A bounded number of blocks later (lag `x` depends on execution timing) |

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

Execution happens between these two protocol signals. A receipt becomes available only after a node executes the ordered transaction. Ordering finality alone does not give an execution result.

<GigaAttestationFlow />

### 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. Because of this intended determinism, execution can 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](https://arxiv.org/abs/2203.06871) 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 to execute in parallel, and each buffers its writes privately. For each transaction, a validation phase checks 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 it falls back to the sequential path.

<GigaOccDiagram />

Sei Labs measured that [64.85% of historical Ethereum transactions could have been parallelized](https://blog.sei.io/research-64-85-of-ethereum-transactions-can-be-parallelized/) under this model. Contract-design guidance for maximizing parallelism is in the [developer guide](/learn/sei-giga-developers#writing-parallel-friendly-contracts).

### 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.
* A marker byte signals contract creation.
* All remaining bytes are the calldata.

A parser reads each transaction in one pass, with no allocation-heavy tree construction. This matters at decode rates of hundreds of thousands of transactions per second.

## EVM compatibility

Sei Giga's EVM will be mostly equivalent to Ethereum mainnet. You will write contracts in standard Solidity or Vyper and deploy them with standard tooling.

| Exception | What will differ on Giga |
| - | - |
| EIP-4844 (blob transactions) | Will not be supported. Giga will remain an L1 and will not carry rollup blob data |
| `PREVRANDAO` | Will not be supported with Ethereum semantics (no beacon-chain randomness) |
| State root | Blocks will carry no Merkle state root. State will be attested through [divergence digests](#lattice-hash-divergence-digests) and proven with [BUDs](#block-update-digests-buds) |
| Block gas limit | Not a fixed Ethereum-style per-block constant. Lane and consensus parameters will bound throughput |
| Transaction fee mechanism | Three-part model (below) instead of Ethereum's exact EIP-1559 burn semantics |

### Fee model

| Component | What it prices | Mechanism |
| - | - | - |
| Execution fee | Gas consumed by execution | EIP-1559-style dynamic base fee driven by demand |
| Ordering fee | Position in the merged order | Priority fee, strictly enforced by the [deterministic merge rule](#mev-and-fee-design) |
| Distribution fee | Duplicate copies submitted for censorship resistance | Will price each extra lane slot that a duplicate occupies. Only one copy will execute, with a partial tip refund |

## Storage

Giga's storage layer is designed for petabyte-per-year data production at full 5-gigagas load, while validator hardware stays 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. Flushes will therefore stay batched and sequential, and nothing will be 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 will exist for durability only. An append-only write-ahead log (WAL) will protect them and will be replayed on crash recovery.
* Storage will be tiered. Recent and hot data will sit on local high-performance SSDs. Historical data will move to a distributed columnar store built for analytical queries and audit workloads.

<GigaStorageArchitecture />

### Lattice-hash divergence digests

There will be no state root. Instead, Giga will 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). It will also contain one record per transaction receipt (position-bound) and one gas-accounting record. Each record will be 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. Divergent executors will therefore compare chunk digests and narrow the search. They will replay only the affected range to find the first divergent write, receipt, or gas discrepancy.

The homomorphism 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). Their cost will be proportional to per-block update volume, not 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`. It will certify that `key` held `value` immediately after block `n`. It will also record when the key previously changed. Two proofs at heights `a < b` whose `b`-leaf records predecessor `a` will prove that 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). Provers will then cover long ranges with logarithmically many digests. The guaranteed proof window will be `η = e^L_max` blocks. Archive nodes can serve older claims, but those claims fall outside the protocol guarantee.
* Touch transactions will rewrite only a key's last-modified metadata. This will give long-untouched keys a fresh proof anchor. Deletions will leave tombstones, which anchor exclusion proofs and are garbage-collected after `η`.
* At the activation height, a one-time synthetic write log will bootstrap every existing key. The system will reach steady state after `η` blocks. BUD trees deliberately use a classical hash, because the short proof window keeps classical collision resistance sufficient. The trees will also fall under the same [post-quantum migration schedule](#post-quantum-migration) as the rest of the protocol.

<GigaBudWindow />

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 instead of 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](#sedna-private-dissemination) milestone activates, ingress will distribute coded symbol bundles across selected lanes. In the current implementation, EVM senders map deterministically to a validator shard. The implementation proxies `eth_sendRawTransaction` and pending-nonce queries to that shard's owner.
* For censorship resistance, users will be able to submit the same transaction to multiple validators. 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, and only one copy will execute. Unexecuted duplicates will pay the [distribution fee](#fee-model) and earn a partial tip refund.
* Four node roles will exist:
  * Validators will run consensus and execution.
  * Full nodes will run RPC plus execution for the read path.
  * Light nodes will run RPC only.
  * Data nodes will serve recent data.

### Sedna: private dissemination

[Sedna](https://arxiv.org/abs/2512.17045) 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.

The Sedna paper compares the design with threshold-encrypted mempools. It argues that the design can give similar pre-execution privacy without an extra decryption round, and with less per-lane bandwidth. The companion incentive mechanism [PIVOT-K](https://arxiv.org/abs/2603.17614) 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. However, they introduce their own MEV (maximal extractable value) channels, formalized in [MEV in Multiple Concurrent Proposer Blockchains](https://arxiv.org/abs/2511.13080). These channels are same-tick duplicate stealing, proposer-to-proposer orderflow deals, and timing races around PoA latency. Same-tick duplicate stealing means copying a visible transaction into your own lane to win the merge. 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 in descending order of the maximum priority fee among their new transactions. Break ties by replica index.
3. Concatenate the lanes and deduplicate by transaction hash. Only the first occurrence survives.

<GigaMergeRule />

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 the opportunities for post-consensus reordering at the protocol level.

### Socialised tips

All priority fees collected in an epoch (net of duplicate refunds) will be pooled. They will be distributed to validators pro rata by `stake × liveness`. Liveness will be the measured fraction of observable duties performed: consensus votes included in committed QCs, certified lane blocks produced, and signed state attestations. Governance will set the duty weighting. 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 protocol-level revenue motive for duplicate stealing.
* Validator revenue from the protocol would be independent of orderflow routing. This would reduce the protocol-level incentive to steer users to specific proposers.
* Withholding or lazy participation will directly reduce a validator's payout.

The whitepaper summarizes the design this way: 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. The registration (scheme identifier, PQ public key, migration nonce, optional activation height) will be signed with the account's 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 could no longer 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 states explicitly that this is an emergency path and is not fast enough for Giga's throughput. Post-quantum cryptography at Giga scale is open research.

## Performance claims and targets

| Metric | Value | Context | Source (date) |
| - | - | - | - |
| Sustained throughput | >5 gigagas/s | Internal devnet: 40 nodes across 20 regions | Whitepaper v2.0 (June 2026) |
| Ordering finality | \<250 ms | Same devnet. Whitepaper v1: \<400 ms. Feb 2025 devnet: \~700 ms, 4 regions | Whitepaper v2.0 (June 2026) |
| Consensus cadence | 1.5 round trips vs 3 | Effective steady-state cut cadence under Autobahn pipelining, not per-transaction latency | Whitepaper §1.1 and §3.4 (2026) |
| Throughput vs Tendermint | >50× | Multi-Proposer dissemination vs single leader | Whitepaper §1.1 (2026) |
| Block production | \~70× (180 blocks vs 2.5) | All-lanes-at-once commits vs sequential single blocks | Whitepaper §1.1 (2026) |
| Autobahn testnet target | 200,000 TPS at 400 ms finality | Public testnet milestone | [giga.seilabs.io](https://giga.seilabs.io) (May 2026) |

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](/learn/twin-turbo-consensus), 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](https://github.com/sei-protocol/sei-chain). There is no separate Giga repository. The mandatory [v6.6 release](https://github.com/sei-protocol/sei-chain/releases/tag/v6.6.0) brought the first Ares and Eidos components to Sei Mainnet 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:

| Area | Current state |
| - | - |
| Ares, first phase | Active on Sei Mainnet after v6.6. Eligible transactions use the Ares path. Unsupported cases rerun individually through the v2 fallback |
| Giga executor defaults | From v6.6, newly generated configurations and configurations that omit the fields enable the Giga executor and OCC. Explicit `false` values opt out |
| Autobahn | Implemented in `sei-tendermint/autobahn` (lanes, PoAs, prepare/commit QCs, timeout certificates). It ships in the binary but stays disabled until network activation. The committee is capped at 100 validators. The implementation uses a stake-weighted availability threshold that corresponds to the whitepaper's `f + 1` model |
| Operator surface | `autobahn-config-file` in `config.toml`, with a committee file generated by `seid tendermint gen-autobahn-config`. Consensus state persists across restarts to prevent double-signing |
| RPC under Autobahn | `eth_sendRawTransaction` and pending-nonce queries proxy to the sender's shard validator. Block and status endpoints route through Autobahn. `eth_subscribe` (newHeads) is supported |
| Eidos migration support | Shipped in v6.6. RPC-node migration remains opt-in and operator-controlled |
| Later storage phases | FlatKV/lattice-hash state commitment and the broader archive design remain operator-gated or future work. Follow the storage migration guide |
| RPC-node storage | Dedicated EVM state-store split (`evm-ss-split`) that targets \~150k TPS reads. See the [Giga storage migration guide](/node/giga-storage-migration) |
| Testing | Differential Giga-vs-v2 execution across the Ethereum state-test suite, mixed Giga/v2 clusters, and an Autobahn integration harness |

For exact keys and defaults, node operators should follow the [node configuration reference](/node/node-operators#giga-storage-and-giga-executor), not this page.

## Glossary

| Term | Definition |
| - | - |
| **Multi-Proposer (MCP)** | Architecture in which every validator proposes transaction data concurrently (the whitepaper's "multiple concurrent proposers"). Giga is designed to be the first Multi-Proposer EVM Layer 1 |
| **Lane** | A validator's own append-only, hash-chained sequence of transaction batches |
| **Car** | One batch of transactions in a lane (a lane entry) |
| **Proposal** | Signed lane entry `⟨pos, batch, parentRef⟩` |
| **PoA (Proof of Availability)** | Certificate that proves proposal data is retrievable. The whitepaper threshold is `f + 1` replicas, and the implementation threshold is stake-weighted |
| **Tip** | The most recent proposal in a lane that holds a PoA |
| **Cut** | The vector of all lanes' current tips committed by one consensus decision |
| **Slot** | One consensus instance that commits one cut. Slots are pipelined |
| **PrepareQC / CommitQC** | Quorum certificates from the prepare and commit voting phases |
| **Timeout certificate** | Certificate that triggers a view change when a leader stalls |
| **Blip** | A transient network disruption. Autobahn is designed to preserve lane dissemination while ordering recovers |
| **Ordering finality** | Under the protocol's stated fault and cryptographic assumptions, consensus has fixed the transaction order (the sub-250 ms signal) |
| **State attestation finality** | A two-thirds voting-power quorum has attested the block's execution results in a later block |
| **Write log** | A block's canonical key-value write set after last-write-wins resolution |
| **Divergence digest** | Compact lattice-hash commitment over a block's write log, receipts, and gas. Validators attest to it |
| **LtHash** | Homomorphic multiset hash used for divergence digests. It updates incrementally, in any order |
| **BUD (Block Update Digest)** | Per-block Merkle root over that block's state updates, and the basis of Giga state proofs |
| **SuperBUD** | Aggregated BUD covering an exponentially sized window of blocks |
| **Touch transaction** | Transaction that refreshes a key's last-modified metadata to create a fresh proof anchor |
| **Proof window (η)** | Number of blocks over which BUD proofs are protocol-guaranteed (`η = e^L_max`, governance-set) |
| **Merge rule** | Deterministic function from a committed cut to the executable transaction sequence (tip-priority order plus deduplication) |
| **Socialised tips** | Epoch-pooled priority fees distributed by stake × liveness instead of to the carrying proposer |
| **Distribution fee** | Fee component that prices duplicate submissions made for censorship resistance |
| **Sedna** | Planned private dissemination milestone that uses rateless-coded, addressed bundles. Its until-decode privacy depends on coding parameters and collusion assumptions |
| **PIVOT-K** | Sedna's incentive mechanism: bounties on decode-pivotal bundles plus a sender ratchet against withholding |
| **Ambulance** | Planned consensus upgrade that replaces timeout-based leader recovery with a rigged race among replicas |
| **Hermes** | Next-generation consensus protocol after Autobahn (whitepaper forthcoming) |
| **Eidos / Ares** | Storage-rebuild and execution-client upgrades whose first components shipped in v6.6. Ares became the default execution path, and Eidos migration remains phased |

## References

* [Sei Giga whitepaper v2.0](https://arxiv.org/abs/2505.14914) by Marsh, Landers, Jog, and Ranchal-Pedrosa (arXiv 2505.14914, June 2026)
* [Autobahn: Seamless high speed BFT](https://arxiv.org/abs/2401.10369) by Giridharan, Suri-Payer, Abraham, Alvisi, and Crooks (arXiv 2401.10369)
* [MEV in Multiple Concurrent Proposer Blockchains](https://arxiv.org/abs/2511.13080) by Landers and Marsh (arXiv 2511.13080)
* [Sedna: Sharding transactions in multiple concurrent proposer blockchains](https://arxiv.org/abs/2512.17045) (arXiv 2512.17045) and its mechanism-design companion introducing [PIVOT-K](https://arxiv.org/abs/2603.17614) (arXiv 2603.17614)
* [Ambulance: saving BFT through racing](https://arxiv.org/abs/2606.25099) (arXiv 2606.25099)
* [Block-STM](https://arxiv.org/abs/2203.06871), the parallel execution design Giga follows (arXiv 2203.06871)
* [Sei Giga: Achieving 5 Gigagas with Autobahn Consensus](https://seiresearch.io/articles/sei-giga-achieving-5-gigagas-with-autobahn-consensus), devnet results (Feb 2025)
* [Autobahn: Sei Giga's Multi-Proposer approach to blockchain consensus](https://blog.sei.io/autobahn-sei-gigas-multi-proposer-approach-to-blockchain-consensus), explainer post (Apr 2025)
* [The Giga Whitepaper v2](https://blog.sei.io/the-giga-whitepaper-2/), the announcement post (July 2026)
* [Sei v6.6.0](https://github.com/sei-protocol/sei-chain/releases/tag/v6.6.0), mandatory Sei Mainnet upgrade (August 2026)
* [sei-protocol/sei-chain](https://github.com/sei-protocol/sei-chain), the open-source implementation

<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, based on the Giga whitepaper v2.0 (June 29, 2026), the sei-chain v6.6 release, and the Sei Mainnet v6.6 activation.*


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