diff --git a/index.mdx b/index.mdx index d1fc152..6012de0 100644 --- a/index.mdx +++ b/index.mdx @@ -108,7 +108,7 @@ The first parallelized EVM blockchain delivering unmatched scalability and speed - Next-gen design enabling giga gas execution bandwidth. + Next-gen design enabling gigagas execution bandwidth. Sub-second finality and fast block production. diff --git a/learn/general-brand-kit.mdx b/learn/general-brand-kit.mdx index edca97a..78b1db3 100644 --- a/learn/general-brand-kit.mdx +++ b/learn/general-brand-kit.mdx @@ -19,7 +19,7 @@ sidebarTitle: 'Brand Kit' Black and white carry the brand. Maroon and Gold are heritage accents — use them only for emphasis and legacy moments, never as the base palette. -Sei delivers breakthrough performance through the world's first multi-proposer EVM Layer 1, combining unmatched speed, security, and seamless execution. Every design decision communicates speed, trust, and uncompromising quality. +Sei delivers breakthrough performance, with a roadmap toward the first Multi-Proposer EVM Layer 1 — combining unmatched speed, security, and seamless execution. Every design decision communicates speed, trust, and uncompromising quality. --- diff --git a/learn/index.mdx b/learn/index.mdx index 5ca4e3e..1b3d4b8 100644 --- a/learn/index.mdx +++ b/learn/index.mdx @@ -128,26 +128,26 @@ The Sei Model Context Protocol (MCP) Server brings blockchain functionality dire -## Sei Giga: Next-Generation Architecture +## Sei Giga: the next-generation architecture -**Engineered for Maximum Throughput & Efficiency** +**Designed to be the first Multi-Proposer EVM Layer 1** -Sei Giga represents a leap forward in blockchain performance. It combines cutting-edge consensus with novel execution strategies to deliver sub-second finality and massive scalability. +Sei Giga will be the next generation of the Sei protocol following the Giga Upgrade. It will arrive as in-place upgrades to the live network. Every validator will propose concurrently, consensus will finalize only the transaction order, and execution will run asynchronously. On an internal devnet this architecture sustained more than 5 gigagas per second (200,000+ TPS) with ordering finality under 250 ms. - High-speed BFT consensus for sub-second finality. + Multi-Proposer BFT: per-validator lanes, 1.5 round trips, sub-250 ms ordering finality. - Decouples execution to unblock consensus. + Consensus will fix ordering; execution and state attestation will follow off the critical path. - - Optimistic concurrency for max throughput. + + Block-STM-style optimistic concurrency across all CPU cores. - Full technical specifications, developer guidance, and upgrade details. + Architecture, roadmap and status, technical specification, and developer guidance. ## Key Use Cases diff --git a/learn/sei-giga-developers.mdx b/learn/sei-giga-developers.mdx index 7f87844..f2d87f1 100644 --- a/learn/sei-giga-developers.mdx +++ b/learn/sei-giga-developers.mdx @@ -1,26 +1,89 @@ --- -title: 'Sei Giga Developer Guide' +title: 'Building on Sei Giga: What Changes for Developers' sidebarTitle: 'Developer Guide' -description: 'Key patterns and techniques for building high-performance dApps on Sei Giga' -keywords: ['sei giga development', 'smart contracts', 'dapp development', 'solidity', 'parallel execution'] +description: 'What Sei Giga will change for smart contract and dApp developers: EVM parity with five exceptions, two finality signals, Sedna-routed submission with no public mempool, socialised priority fees, BUD state proofs, and contract patterns that maximize parallel execution.' +keywords: ['sei giga development', 'giga developer guide', 'ordering finality', 'parallel execution patterns', 'no public mempool', 'priority fee', 'eth_getproof', 'solidity', 'evm compatibility'] --- -This is a sneak peek at the patterns and optimizations developers should consider when building on Sei Giga. For current EVM development tutorials, check out the [EVM development guides](/evm/evm-general). -## Why Build on Sei Giga? +import { GigaFinalitySignals, GigaParallelismContrast, GigaFeeSplit } from '/snippets/giga-diagrams.jsx'; -- **Familiar Tools:** Full EVM compatibility—use existing Ethereum tooling -- **Parallel Execution:** Transactions touching different state run simultaneously -- **Lower Costs:** Efficient architecture means cheaper transactions -- **Native Precompiles:** Access to staking, and more from Solidity +Sei Giga is designed so that your contracts will not need to change. The EVM will be equivalent to Ethereum mainnet except for five things (EIP-4844 blobs, `PREVRANDAO`, the state root, the block gas limit, and the transaction fee mechanism), and standard Solidity and Vyper tooling will keep working: Foundry, Hardhat, viem, ethers. What will change is the environment around your contracts. Finality will come in two signals, there will be no traditional public mempool (transactions will route through [Sedna](/learn/sei-giga-specs#sedna-private-dissemination) into validator lanes), a priority fee will buy a position in the order rather than a proposer's favor, and state proofs will work differently. This page covers each change, plus the patterns that will get the most out of Giga's parallel execution. -## Key Development Patterns + + Sei Giga will roll out as [phased upgrades to the live network](/learn/sei-giga#how-will-sei-giga-ship); as of July 2026 there is no public Giga testnet yet. Everything on this page describes the Giga architecture from the [whitepaper v2.0](https://arxiv.org/abs/2505.14914) and the shipping [sei-chain](https://github.com/sei-protocol/sei-chain) implementation; it is forward-looking and subject to change until each upgrade activates on the network. For building on Sei today, start with the [EVM development guides](/evm/evm-general). + + +## What will stay the same + +- Contract code: Solidity and Vyper will compile and behave identically. Opcodes and standard precompiles will match Ethereum, and Sei will track future EVM upgrades to stay near parity. +- Tooling: standard JSON-RPC (`eth_call`, `eth_sendRawTransaction`, `eth_getTransactionReceipt`, `eth_feeHistory`, `eth_subscribe` for new heads), so Foundry, Hardhat, viem, ethers.js, and wagmi will work unchanged. +- Accounts and signing: the same `0x` addresses and the same ECDSA flow, with a [post-quantum migration path](/learn/sei-giga-specs#post-quantum-migration) specified for the long term. +- The gas token: SEI will stay the native token for gas, staking, and fees. +- The network itself: Giga will upgrade the live Sei network in place, with no new chain to redeploy to. + +## What will change for your application + +| Area | On Ethereum / Sei today | On Sei Giga | What you should do | +| ------------------- | -------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------ | +| Finality | One signal (block inclusion / finalized tag) | Two signals: ordering finality (measured <250 ms) and state attestation finality (a few blocks later) | Pick the signal per flow; see [below](#finality-on-giga-which-signal-to-wait-for) | +| Mempool | Public pending pool, gossip, frontrunning games | No traditional public mempool; transactions will route through [Sedna](/learn/sei-giga-specs#sedna-private-dissemination) into a validator's lane | Drop pending-pool assumptions; there will be no pending stream to watch | +| Priority fee | Paid to the block proposer; buys inclusion favor | Strictly enforced for ordering, then socialised across validators by stake × liveness | Use the tip to express urgency; courting specific proposers buys nothing | +| State proofs | `eth_getProof` against the block state root | No state root; [BUD proofs](/learn/sei-giga-specs#block-update-digests-buds) against attested per-block digests | Don't hard-depend on `eth_getProof`; plan for BUD-based verification | +| Randomness | `PREVRANDAO` (beacon randomness) | `PREVRANDAO` not supported with Ethereum semantics | Use a VRF or oracle for randomness | +| Blob transactions | EIP-4844 type-3 transactions | Will not be supported (Giga will remain an L1, not a rollup DA consumer) | Nothing to do unless you post blobs | +| Block gas limit | Fixed per-block constant | No Ethereum-style fixed block gas limit; throughput bounded by lane and consensus parameters | Don't encode assumptions about a specific block gas limit | +| Duplicate submission | Re-broadcasting the same tx is free but useless | Multi-submitting to several validators will be a censorship-resistance feature: one copy will execute, duplicates will pay a distribution fee with a partial tip refund | Optionally multi-submit high-value transactions | + +## Finality on Giga: which signal to wait for + +Giga will separate consensus from execution, which will give you two distinct confirmation signals: + +- Ordering finality (measured under 250 ms on the internal devnet): consensus has irrevocably fixed your transaction's position. Execution will be deterministic, so the outcome will be decided at this moment; every honest node will compute the same result. Ordered transactions are designed never to reorg. +- State attestation finality, a bounded number of blocks later: a 2/3 validator quorum has signed the block's [divergence digest](/learn/sei-giga-specs#lattice-hash-divergence-digests). This confirms the executed results, not just the order. + + + +Which signal to wait for depends on the flow: + +| Use case | Wait for | Why | +| --------------------------------------------------- | --------------------------- | ------------------------------------------------------------------------ | +| Trading UX, games, payments UI, most dApp flows | Ordering finality (receipt) | Deterministic outcome; the devnet measured it in under 250 ms | +| Exchange deposits, bridge withdrawals, high-value settlement | State attestation finality | Adds a signed quorum attestation of executed state before you act on it | +| External verification (light clients, cross-chain) | Attested BUD proofs | Proofs anchor to attested digests, which follow the attestation schedule | + +A transaction that reverts will stay reverted; a revert will be a valid, final outcome and will not invalidate the block. For today's finality behavior, before Giga, see [EVM finality on Sei](/evm/evm-parity/finality). + +## Sending transactions without a public mempool + +On Giga there will be no shared public pending pool. Transactions will route through [Sedna](/learn/sei-giga-specs#sedna-private-dissemination), Giga's private dissemination layer, into a validator's proposal lane; consensus will then commit the cut containing them in 1.5 network round trips. In practice: + +- There will be no public mempool to scan for victims, and the merged execution order will be a [deterministic function](/learn/sei-giga-specs#deterministic-merge-rule) of finalized lane contents — a design that leaves no post-consensus reordering game to play. Sedna will add pre-execution privacy on top: transaction contents are designed to stay hidden until ordering is final. +- Pending semantics will change. Don't build features on watching a gossiped pending-transaction stream. Pending-nonce queries will be answered by the validator responsible for your sender address; the RPC layer will route this for you. +- You will control your own censorship resistance. Submit the identical signed transaction to multiple validators if it matters; only one copy will execute, since duplicates will be dropped by hash at merge time, and extra copies will pay a distribution fee and get part of the tip back. A single submission will be the right default for most transactions. +- Each validator will include at most one copy of a given transaction per epoch, so duplicate floods cannot amplify. + +## Fees on Giga + +Giga will price three things separately (full details in the [fee model spec](/learn/sei-giga-specs#fee-model)): -### Pattern 1: User-Isolated State +1. The execution fee: an EIP-1559-style dynamic base fee for gas actually consumed. `eth_feeHistory` and `eth_maxPriorityFeePerGas` will remain your estimation tools. +2. The ordering fee, better known as the priority fee. Giga will enforce it strictly: lanes in each committed cut will be ordered by their highest included tip, so a higher tip will buy earlier execution, deterministically. The fee will also be socialised (pooled per epoch and distributed to validators by stake and liveness), a design under which tipping a specific proposer for special treatment achieves nothing. +3. The distribution fee, charged per duplicate copy when you multi-submit for censorship resistance. -Sei Giga's parallel execution engine rewards contracts with isolated state. When users' operations don't touch shared state, they execute simultaneously. + + +For gas metering inside the EVM, Sei's existing schedule will continue to apply, including Sei's custom `SSTORE` pricing (see [gas and fees](/evm/evm-parity/gas-and-fees)). The whitepaper defers the final Giga fee mechanism to a dedicated paper, so expect parameter-level details to firm up around the Autobahn testnet. + +## Writing parallel-friendly contracts + +Giga will execute each block with [Block-STM-style optimistic concurrency](/learn/sei-giga-specs#parallel-execution-block-stm-style-occ): transactions will run in parallel and re-execute only when their read/write sets collide. Sei Labs measured that [64.85% of historical Ethereum transactions parallelize](https://blog.sei.io/research-64-85-of-ethereum-transactions-can-be-parallelized/) as-is. Your contract's storage layout will decide which side of that statistic it lands on. Transactions touching disjoint storage will run simultaneously; transactions contending on one hot slot will serialize (the engine will retry conflicted transactions and, under sustained contention, fall back to sequential execution — a fallback designed to protect correctness at the cost of speed). + + + +### Pattern 1: isolate state per user ```solidity -// GOOD: Each user has isolated state - transfers can run in parallel +// GOOD: per-user state; transfers between different users run in parallel contract OptimizedToken { mapping(address => uint256) private balances; @@ -31,91 +94,72 @@ contract OptimizedToken { } } -// BAD: Global counter forces sequential execution +// BAD: every transfer writes one global slot, so transfers serialize contract PoorToken { - uint256 public totalTransfers; // Every transfer conflicts! + uint256 public totalTransfers; // every transfer conflicts here function transfer(address to, uint256 amount) public { - totalTransfers++; // Blocks parallelism + totalTransfers++; // hot slot: blocks parallelism for the whole block // ... transfer logic } } ``` -### Pattern 2: Struct Packing - -Pack struct variables to minimize storage slots and reduce gas costs. - -```solidity -contract OptimizedStorage { - // GOOD: Uses 1 storage slot (256 bits total) - struct User { - uint128 balance; // 128 bits - uint64 lastUpdate; // 64 bits - uint64 nonce; // 64 bits - } +Global counters, monolithic `totalSupply` updates on every operation, shared round-robin pointers, and single-slot reward accumulators are the classic hot spots. If you need an aggregate, update it lazily, shard it (per-address buckets aggregated on read), or derive it off-chain from events. - // BAD: Uses 3 storage slots - struct InefficientUser { - uint256 balance; // 256 bits = 1 slot - uint64 lastUpdate; // 64 bits = 1 slot (wastes 192 bits) - uint64 nonce; // 64 bits = 1 slot (wastes 192 bits) - } -} -``` +### Pattern 2: prefer mappings over shared arrays -### Pattern 3: Event-Driven Architecture +`mapping(address => T)` lookups touch one isolated slot per user. Pushing to a shared array touches the array-length slot on every insert, which makes the length slot a hidden global counter. -Store historical data in events instead of storage to reduce costs. +### Pattern 3: emit events instead of storing history ```solidity contract EventDrivenAuction { mapping(uint256 => uint128) public highestBids; - // Bid history stored in events, not storage + // Bid history lives in events, not storage event BidPlaced(uint256 indexed auctionId, address indexed bidder, uint256 amount); function bid(uint256 auctionId) external payable { require(msg.value > highestBids[auctionId], "Bid too low"); highestBids[auctionId] = uint128(msg.value); - emit BidPlaced(auctionId, msg.sender, msg.value); // Cheap! + emit BidPlaced(auctionId, msg.sender, msg.value); } } ``` -## Gas Optimization Tips +Events will be a particularly good deal on Giga: receipt generation and log indexing will run off the execution hot path in dedicated stores, so keeping history in events will trim your write set without losing queryability. - -**Quick Wins:** -- Use `memory` for temporary data, `calldata` for read-only parameters -- Cache array lengths in loops: `uint256 len = arr.length;` -- Use `unchecked { i++; }` in loops where overflow is impossible -- Batch operations to amortize base transaction costs - +### Pattern 4: pack storage you must share -## Native Precompiles +When state is genuinely shared, make it cheap: pack related fields into one slot so a conflicting transaction pays one slot conflict instead of three. -Sei Giga will also provide precompiles for direct access to chain features from Solidity. - -See the [Precompiles documentation](/evm/precompiles) for full details. +```solidity +struct Position { + uint128 size; // 128 bits ┐ + uint64 entryTime; // 64 bits ├─ one storage slot + uint64 nonce; // 64 bits ┘ +} +``` -## Development Checklists +## Sei precompiles under the Giga executor -### Parallel Execution Checklist +The Giga execution engine currently fast-paths pure-EVM transactions. Calls into Sei's custom precompiles (staking, governance, distribution, oracle, bank, and the other [Sei-native precompiles](/evm/precompiles/example-usage)) execute correctly but are routed through the legacy engine as of the sei-chain v6.6 release line: they work, but they sit off the parallel fast path. If you're optimizing a hot path for Giga-scale throughput, keep custom-precompile calls out of it where you can. -- Isolate state by user/entity -- Avoid global counters and shared state -- Use mappings over arrays for lookups +## Prepare your app for Giga today -### Gas Optimization Checklist +- Build EVM-only. [SIP-3](/learn/sip-03-migration) consolidates Sei to a streamlined EVM-only stack ahead of Giga: CosmWasm no longer accepts new deployments, inbound IBC is disabled, and oracles come from standard providers such as Chainlink, API3, and Pyth instead of the native module. +- Audit for hot slots. Per-user state isolation is the single most effective change for parallel throughput, and it pays off now: the Giga executor with OCC ships enabled by default from the sei-chain v6.6 release line. +- Classify your confirmation flows. Decide which flows act on ordering finality and which wait for state attestation, so the two-signal model will land as a config change rather than a redesign. +- Remove fragile dependencies. Anything that relies on `eth_getProof` and state roots ([current behavior](/evm/evm-parity/state-proofs)), `PREVRANDAO` randomness, blob transactions, or watching the public mempool will need a plan. +- Don't wait for a "Giga chain." There won't be one; Giga will arrive on the network where you're already deployed, and contracts shipped on Sei today are designed to carry over untouched. -- Pack structs to minimize storage slots -- Use events for historical data -- Cache array lengths in loops -- Batch operations when possible +## Related -## Next Steps +- [Sei Giga overview](/learn/sei-giga): architecture and roadmap +- [Sei Giga technical specification](/learn/sei-giga-specs): the full protocol spec and glossary +- [EVM development guides](/evm/evm-general): building on Sei today +- [Differences with Ethereum](/evm/differences-with-ethereum): current-network EVM deltas +- [SIP-3 migration guide](/learn/sip-03-migration): the EVM-only consolidation -1. **Full Tutorials** - Start with the [EVM development guides](/evm/evm-general) -2. **Architecture Details** - Review the [Sei Giga Overview](/learn/sei-giga) -3. **Precompiles** - Explore [native precompiles](/evm/precompiles) for advanced features +_Last updated July 2026, based on the Giga whitepaper v2.0 (June 29, 2026) and the sei-chain v6.6 release line._ diff --git a/learn/sei-giga-specs.mdx b/learn/sei-giga-specs.mdx index 65b9c13..9ef93b1 100644 --- a/learn/sei-giga-specs.mdx +++ b/learn/sei-giga-specs.mdx @@ -1,194 +1,294 @@ --- -title: 'Sei Giga Technical Specifications' +title: 'Sei Giga Technical Specification' sidebarTitle: 'Technical Specs' -description: 'Comprehensive technical specifications for Sei Giga architecture, consensus protocols, and performance characteristics' -keywords: ['sei giga specs', 'technical specifications', 'autobahn consensus', 'blockchain architecture', 'performance specs'] +description: 'The complete Sei Giga protocol specification: Autobahn consensus with per-validator lanes and f+1 Proofs of Availability, asynchronous execution with divergence-digest attestation, Block-STM parallel EVM, flat lattice-hashed storage, BUD state proofs, a fee design built to counter Multi-Proposer MEV channels, and the security model.' +keywords: ['sei giga specification', 'autobahn consensus', 'proof of availability', 'ordering finality', 'divergence digest', 'lattice hash', 'block update digest', 'block-stm', 'socialised tips', 'multi-proposer bft'] --- -## Introduction - -This document provides comprehensive technical specifications for Sei Giga, covering both current features and upcoming architectural enhancements. - -The specifications are organized to clearly distinguish between what is currently deployed and what is planned for future releases. - - - - Features and specifications that are live on the Sei network today. - - - Planned features and specifications in development. - - - -## Consensus Architecture - -### Current: Twin Turbo Consensus - - - - - | Property | Value | - | --- | --- | - | Base Protocol | Enhanced Tendermint BFT | - | Marketing Name | Twin Turbo Consensus | - | Target Block Time | ~400ms | - | Finality | Instant (1 block) | - | Safety Threshold | ⅔ + 1 validators | - - - - Pipelined block processing - - Optimistic execution - - Aggressive timeouts - - Parallel validation - - - - -### Upcoming: Autobahn Consensus - - - - - | Property | Value | - | --- | --- | - | Architecture | Multi-proposer BFT | - | Target Block Time | Sub-second | - | Proposer Model | Parallel lanes | - | Safety Model | Byzantine Fault Tolerant | - - - - Asynchronous execution - - Data availability lanes - - Consensus/execution separation - - Optimized data dissemination - - - - -## Execution Engine - -### Current: Parallel EVM Execution - - - - - Full Ethereum Virtual Machine compatibility with standard opcodes and gas metering. - - - Optimistic Concurrency Control with multi-worker transaction processing and conflict resolution. - - - Optimized state access patterns with SeiDB storage backend. - - - - **Execution Specifications** - - | Property | Value | - | --- | --- | - | VM Type | Ethereum Virtual Machine | - | Gas Model | Ethereum-compatible | - | Execution Model | Parallel with OCC | - | Supported Languages | Solidity, Vyper, YUL | - | Precompiles | Standard + Sei Native | - | State Model | Account-based | - - -## Storage Architecture - -### Current: SeiDB - - - - - | Property | Value | - | --- | --- | - | Storage Type | Key-Value Store | - | State Storage | MemIAVL (Cosmos) + FlatKV/LtHash (EVM) | - | Caching | Multi-level | - | Concurrency | Thread-safe | - - - - Hot state caching - - Efficient pruning - - Parallel state access - - Optimized serialization - - - - -## Network Specifications - -### Protocol Parameters - -**Network Configuration** - - - - | Property | Value | - | --- | --- | - | Max Validators | 100 | - | Voting Power | Stake-weighted | - | Unbonding Period | 21 days | - | Slashing | Byzantine behavior | - - - | Property | Value | - | --- | --- | - | Max Block Size | 21 MB | - | Max Gas Limit | 12.5 M | - | Base Fee | Dynamic, on-chain param; no burn (validators receive fees) | - | Priority Fee | Supported | - - - -## Performance Targets - -**Engineering Targets**: The following performance specifications represent engineering targets for the upcoming Sei Giga architecture with Autobahn consensus, not current network performance. - -### Upcoming: Target Performance Specifications - - - - - Peak throughput target - - - Transaction confirmation - - - Simple transfers - - - - -## Developer Interface - -### JSON-RPC Compatibility - -**Ethereum JSON-RPC Support** - - - - - `eth_sendRawTransaction` - - `eth_call` - - `eth_getBalance` - - `eth_getTransactionReceipt` - - - - `debug_traceTransaction` - - `eth_feeHistory` - - `eth_maxPriorityFeePerGas` - - - -## Related Resources - - - - High-level introduction to Sei Giga architecture and features. - - - Complete guide for building applications on Sei Giga. - - +import { GigaLanesAndCuts, GigaSlotPipeline, GigaAttestationFlow, GigaOccDiagram, GigaStorageArchitecture, GigaBudWindow, GigaMergeRule } from '/snippets/giga-diagrams.jsx'; + +This page specifies the Sei Giga protocol as defined in the [Giga whitepaper v2.0](https://arxiv.org/abs/2505.14914) (Marsh, Landers, Jog, Ranchal-Pedrosa; June 2026), with implementation notes from the [sei-chain](https://github.com/sei-protocol/sei-chain) codebase as of the v6.6 release line (July 2026). The specification 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 | Byzantine, `n = 3f + 1` validators, up to `f` faulty | +| Synchrony assumption | Partial synchrony: safety unconditional, liveness after network stabilization | +| Consensus | Autobahn: per-validator data lanes with leader-driven cut-of-tips ordering | +| Data availability quorum | `f + 1` votes (Proof of Availability) | +| Ordering quorum | `n - f` prepare/commit votes (stake-weighted in the implementation) | +| Consensus latency | 1.5 network round trips (pipelined slow path; Tendermint requires 3 rounds) | +| Execution | Asynchronous, post-ordering; deterministic; Block-STM-style optimistic concurrency control | +| State attestation | 2/3-quorum 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 | +| Mempool | No traditional public mempool; transactions will route through [Sedna](#sedna-private-dissemination) into per-validator lanes, at most one copy of a transaction per validator per epoch | +| 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: 40 nodes, 20 regions; reported in whitepaper v2.0, June 2026) | + +## Network and security model + +Giga's fault model assumes `n = 3f + 1` validator replicas, of which at most `f` are Byzantine, communicating over authenticated point-to-point channels with unforgeable cryptographic primitives. The protocol targets the partial synchrony model: safety is unconditional, and liveness requires only that the network eventually stabilizes so message delays respect known upper bounds. + +- Safety: no two conflicting proposals can both obtain a valid commit certificate in the same consensus slot. Attesting to two different divergence digests for the same finalized block will be slashable equivocation, because quorum intersection guarantees at least one honest validator would have to sign both. +- Censorship resistance: once a proposal holds `f + 1` availability votes, at least one honest replica stores its data, and a correct leader must include it in a future cut. Faulty proposers will not be able to disseminate data without it eventually being ordered, which bounds 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: if fewer than 1/3 of validators compute a divergent state (hardware fault, software bug), the chain will continue while the fault is localized. Divergence beyond the Byzantine threshold will pause the chain, as in any BFT system. +- Staking: validators will continue to bond SEI and can be slashed for malicious behavior. The complete slashing schedule, reward functions, and tokenomics for Giga are deferred to future work; today's staking parameters are documented in [Staking](/learn/general-staking). + +## Consensus: Autobahn + +Sei Giga will order transactions with [Autobahn](https://arxiv.org/abs/2401.10369) (Giridharan, Suri-Payer, Abraham, Alvisi, Crooks; 2024), a BFT protocol that decouples data dissemination from ordering. It occupies a deliberate middle ground between view-based protocols (HotStuff, Tendermint), which stall during network "blips," and DAG-based protocols (Narwhal-style), which pay extra latency in the good case. Autobahn pairs an asynchronous data layer with a partially synchronous, low-latency ordering layer; it recovers cleanly after periods of asynchrony and matches DAG-class throughput at roughly half the latency. + +### Data dissemination: lanes and Proofs of Availability + +- Every validator `r` will maintain its own lane: an append-only, hash-chained sequence of transaction batches (called cars). A proposal is the tuple `Prop = ⟨pos, batch, parentRef⟩` signed by `r`, where `pos` is the lane sequence number and `parentRef` is the hash of the previous proposal in the same lane. +- Validators that receive a proposal will verify it extends the lane correctly and return a signed vote over its digest. Once the proposer collects `f + 1` matching votes, it will assemble a Proof of Availability (PoA), a certificate that the data is retrievable. +- `f + 1` is sufficient because any such quorum contains at least one correct replica that held the full data when it voted, and that replica serves it until all correct replicas have it. Giga's design deliberately keeps the smaller quorum (rather than `2f + 1`) because commitment itself triggers full replication along the execution path; a larger quorum would only add certification latency. +- The latest proposal in a lane holding a PoA is the lane's tip. Lanes are hash-chained, so certifying a tip implicitly attests the availability of every earlier proposal in that lane, and consensus never re-certifies history. + + + +All validators will disseminate batches in parallel, continuously, without waiting for consensus. Dissemination will therefore not be the bottleneck, and total bandwidth will scale with the validator count rather than one leader's uplink. + +### Ordering: cuts of tips + +Consensus will periodically fix a global order by committing a cut, a vector of every lane's current certified tip: + +1. Prepare. The slot's leader (chosen by stake-weighted selection, as in Tendermint) will bundle the latest certified tips into a cut proposal; replicas will validate the PoAs and broadcast prepare votes, forming a PrepareQC at `n - f` votes. +2. Commit. Replicas will exchange commit votes over the PrepareQC; a CommitQC finalizes the cut. If the leader gathers only the minimum `n - f` commit votes, it will run an additional confirm phase, collecting `2f + 1` confirmations before the commit certificate is final. +3. Pipelining. Slots will overlap: as soon as replicas see the Prepare message for slot `s`, they can begin slot `s + 1`, and the next leader may start proposing while the previous cut is still in its commit phase. With quadratic communication and pipelining, the effective cost will be a 1.5 round-trip slow path, versus 2.5 without pipelining and 3 full rounds in Tendermint. + + + +Committing one cut will finalize every uncommitted proposal in every lane up to the referenced tips. A single consensus decision can therefore commit many blocks' worth of data at once, which is why the whitepaper reports 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. Data dissemination will continue in every lane throughout, so a view change will cost some ordering latency but no throughput. The Autobahn paper calls this "seamless" recovery from blips; chained-HotStuff-style protocols instead pay a hangover after asynchrony. + +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": non-leader replicas do useful persistence work on candidate cuts built from the same certified tips in parallel, so when a leader is merely slow (I/O contention, garbage collection, routing trouble) the slot can finish from existing recovery state instead of paying a full timeout. Planned as a core part of a future upgrade. +- Hermes, a next-generation consensus protocol on the [official roadmap](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 after submission (measured on an internal devnet) | +| State attestation finality | A later finalized block includes a valid 2/3-quorum 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. Ordering finality is already irreversible (the transaction sequence can never change); state attestation finality adds a BFT-signed confirmation of the results of execution. + + + +### Deterministic block transition + +For each finalized block, every executor will compute the canonical transition `Apply(S_prev, context, block) → (S_new, receipts, gas, writeLog)`. Given the same pre-state, block context, ordered transactions, identical execution semantics, and serializable parallel execution, this transition is unique, so all honest executors will derive byte-identical results without communicating. A transaction that reverts will stay reverted; it will not invalidate the rest of the block. This determinism is what makes it safe to run execution entirely 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 executing in parallel, each buffering its writes privately. A validation phase checks, for each transaction, whether any earlier-ordered transaction committed a write into its read or write set after it began; conflicting transactions are rolled back and re-executed. +- The committed result is provably identical to sequential execution in block order (a "valid parallel schedule"). When contention is low, most transactions commit on their first attempt; under sustained contention the engine may fall back to sequential execution with unchanged semantics. In `sei-chain`, the scheduler retries a transaction up to 10 times before reverting to the sequential path. + + + +Sei Labs measured that [64.85% of historical Ethereum transactions can be 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, contract creation is signaled by a marker byte, and all remaining bytes are the calldata. A parser reads each transaction in one pass with no allocation-heavy tree construction, which matters when decoding hundreds of thousands of transactions per second. + +## EVM compatibility + +Sei Giga's EVM will be mostly equivalent to mainnet Ethereum. Contracts will be written in standard Solidity or Vyper and deployed with standard tooling. + +| 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 via [divergence digests](#lattice-hash-divergence-digests) and proven via [BUDs](#block-update-digests-buds) | +| Block gas limit | Not a fixed Ethereum-style per-block constant; throughput will be bounded by lane and consensus parameters | +| 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 additional lane slot 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 keeping validator hardware practical. + +### Flat state, RAM-first + +- Every account, storage slot, and global variable will map directly to an entry in a log-structured merge (LSM) tree. Writes will skip per-write Merkle path updates entirely, so flushes stay batched and sequential and nothing is re-hashed on the write path. +- Frequently accessed state will be held in RAM, and reads will be served from memory in the common case. All disk writes will be asynchronous and exist for durability only, protected by an append-only write-ahead log (WAL) that is replayed on crash recovery. +- Storage will be tiered: recent and hot data will sit on local high-performance SSDs, while historical data will move to a distributed columnar store built for analytical queries and audit workloads. + + + +### Lattice-hash divergence digests + +There will be no state root; Giga will instead commit to execution results with a homomorphic multiset hash (LtHash, by Lewi, Kim, Maykov, and Weis): `LH(X) = Σ h(x) mod q`. Its collision resistance rests on lattice assumptions (short integer solution style). For each block `n`: + +- The committed multiset `X_n` will contain one record per surviving write (after intra-block last-write-wins resolution), one record per transaction receipt (position-bound), and one gas-accounting record, each domain-separated by type tag and height. +- The block digest is `d_n = LH(X_n)`; validators will attest to the compact commitment `D_n = H(enc(n, d_n))`. The full vector `d_n` will be exchanged only during disputes. +- Disputes will resolve by bisection. The key space partitions into ranges whose chunk digests sum to the write component of `d_n` by construction, so divergent executors will compare chunk digests, narrow down, and replay only the affected range to find the first divergent write, receipt, or gas discrepancy. + +The homomorphism is what makes this practical: digests update incrementally as writes commit, in any order, and no tree walk is involved. + +### Block Update Digests (BUDs) + +BUDs will restore externally verifiable state proofs (the role `eth_getProof` plays on Ethereum) at a cost proportional to per-block update volume rather than total state size: + +- Every state entry will carry an 8-byte last-modified height and a 1-byte serialization version. For each block `n`, the BUD `U_n` is the Merkle root over the lexicographically sorted leaves `(key, newValue, n, prevHeight)` of that block's writes. Validators will attest `U_n` on the same delayed 2/3-quorum schedule as the divergence digest. +- A membership proof will be a Merkle path to an attested `U_n`, certifying that `key` held `value` immediately after block `n` and recording when it previously changed. Two proofs at heights `a < b` whose `b`-leaf records predecessor `a` will prove the key was unmodified throughout `(a, b)`. +- SuperBUDs will aggregate BUDs over exponentially growing aligned windows (branching base `e` and maximum level `L_max`, both governance parameters), so provers will cover long ranges with logarithmically many digests. The guaranteed proof window will be `η = e^L_max` blocks; older claims can be served by archive nodes but fall outside the protocol guarantee. +- Touch transactions will rewrite only a key's last-modified metadata, giving long-untouched keys a fresh proof anchor. Deletions will leave tombstones, garbage-collected after `η`, which anchor exclusion proofs. +- At the activation height a one-time synthetic write log will bootstrap every existing key, and the system will reach steady state after `η` blocks. BUD trees deliberately use a classical hash: the short proof window keeps classical collision resistance sufficient, and the trees will fall under the same [post-quantum migration schedule](#post-quantum-migration) as the rest of the protocol. + + + +Light clients, bridges, and any external verifier will consume BUD proofs against attested digests instead of Merkle-Patricia proofs against a state root. + +## Networking and transaction ingress + +- Nodes will communicate over direct, authenticated point-to-point connections; nothing will be gossip-flooded. 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. Transactions will route through [Sedna](#sedna-private-dissemination), Giga's private dissemination layer, into validator lanes for immediate inclusion, allocated by stake weight. In the current implementation, EVM senders map deterministically to a validator shard, and `eth_sendRawTransaction` plus pending-nonce queries are proxied to that shard's owner. +- Users will be able to submit the same transaction to multiple validators for censorship resistance. Admission will be rate-limited: each validator will include at most one copy of a given transaction per epoch, duplicates will be dropped deterministically at merge time, only one copy will execute, and unexecuted duplicates will earn a partial tip refund while paying the [distribution fee](#fee-model). +- Four node roles will exist: validators (consensus and execution), full nodes (RPC plus execution for the read path), light nodes (RPC only), and data nodes that serve recent data. + +### Sedna: private dissemination + +[Sedna](https://arxiv.org/abs/2512.17045) will be Giga's private dissemination layer, the mempool-adjacent stage of the transaction path: transactions will route through Sedna on their way into validator lanes. Senders will encode a committed transaction payload into verifiable rateless coded symbols and send addressed bundles to selected proposer lanes. No lane will see the whole transaction, and executors will reconstruct the unique payload only after ordering, once finalized symbols cross the decode threshold ("until-decode privacy"). Compared with threshold-encrypted mempools, the Sedna paper argues this design reaches similar pre-execution privacy without an extra decryption round or any trust assumption beyond the existing `f + 1` availability quorum, and with better goodput; coding is also designed to cut per-lane bandwidth to a fraction of the payload size. The companion incentive mechanism [PIVOT-K](https://arxiv.org/abs/2603.17614) will concentrate a sender-funded bounty on the bundles that trigger decoding and ratchet away from lanes that withhold, a mechanism designed to close the withholding attack. Sedna will ship as its own roadmap milestone after Autobahn reaches mainnet. + +## MEV and fee design + +Multi-Proposer architectures remove the single block-builder's private ordering monopoly but introduce their own MEV (maximal extractable value) channels, formalized in [MEV in Multiple Concurrent Proposer Blockchains](https://arxiv.org/abs/2511.13080): same-tick duplicate stealing (copying a visible transaction into your own lane to win the merge), proposer-to-proposer orderflow deals, and timing races around PoA latency. Giga's countermeasures will live at the protocol level. + +### Deterministic merge rule + +For each committed cut, every node will derive the executable sequence with the same pure function: + +1. Take each lane's newly committed transactions, meaning those not in any previous cut, in their intra-lane order. +2. Sort lanes by the maximum priority fee among their new transactions, descending; break ties by replica index. +3. Concatenate the lanes and deduplicate by transaction hash; only the first occurrence survives. + + + +The merged order will depend only on finalized lane contents, not on arrival timing, wall clocks, or any node's discretion — a design that leaves no post-consensus ordering game to play. + +### Socialised tips + +All priority fees collected in an epoch (net of duplicate refunds) will be pooled and distributed to validators pro rata by `stake × liveness`, where liveness will be the measured fraction of observable duties performed: consensus votes included in committed QCs, certified lane blocks produced, and signed state attestations, with duty weighting set by governance. Payouts will be shared with delegators in the same way as block rewards. + +- Copying a high-tip transaction into your own lane will not capture its fee, a design that removes the duplicate-steal channel's revenue motive. +- Validator revenue will be independent of orderflow routing, removing the protocol-level incentive to steer users to specific proposers. +- Withholding or lazy participation will directly reduce a validator's payout. + +The whitepaper sums it up: the priority fee will buy ordering, not a relationship with a particular proposer. Side payments for intra-lane position are out of protocol scope for now and belong to the forthcoming fee-mechanism work. + +## Post-quantum migration + +Giga will ship with a survivability path for a sudden ECDSA break ("Q-day") that avoids a chain-wide account reset: + +- Before a governance-set cutoff height, any account will be able to register a post-quantum verification key (scheme identifier, PQ public key, migration nonce, optional activation height), signed with its current classical key. +- During the transition window the chain will accept classical or dual classical+PQ signatures. After the cutoff, verification will be table-driven PQ-only: unregistered accounts will become invalid, there will be no public-key-recovery path, and no new classical EOAs will be creatable. Onboarding will continue through pre-registration, contract wallets, or a later native PQ account format. +- The designated short-term scheme is ML-DSA (FIPS 204). The whitepaper is explicit that this is an emergency path and not fast enough for Giga's throughput; post-quantum cryptography at Giga scale is open research. + +## Performance + +| 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) | +| Transactions per second | 200,000+ | Simple transfers at 5 gigagas/s | Sei Labs roadmap and whitepaper (2025 and 2026) | +| Consensus efficiency | 1.5 round trips vs 3 (2×) | Autobahn vs Tendermint voting rounds | Whitepaper §1.1 (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 Giga. + +## Implementation snapshot (sei-chain v6.6 release line, July 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 facts below describe the v6.6 release line and can change before network activation: + +| Area | Current state | +| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------ | +| Giga executor | `giga/` package; enabled by default with OCC (`[giga_executor]` in `app.toml`); EVM engine is Sei's go-ethereum fork (v1.15.7-sei-17), with an optional evmone 0.12.0 interpreter that is not used in production | +| Execution fallback | EVM transactions run through the Giga executor; calls into Sei's custom precompiles, unsupported iterator patterns, and legacy balance migrations fall back to the v2 engine transparently | +| Autobahn | Implemented in `sei-tendermint/autobahn` (lanes, PoAs, prepare/commit QCs, timeout certificates); ships in the binary but disabled by default in all supported environments until network activation; committee capped at 100 validators; PoA quorum is `f + 1` by stake weight | +| Operator surface | `autobahn-config-file` in `config.toml`, committee file generated with `seid tendermint gen-autobahn-config`; consensus state persisted 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) supported | +| Storage | FlatKV state-commitment store with blake3-based LtHash (1024 × 16-bit limbs) for EVM state; composite store routes Cosmos state to memiavl and EVM state to FlatKV; HashVault pins one block-hash commitment per height and halts the node on mismatch; receipts are served from a dedicated Pebble-backed store, with LittDB (an append-only engine built for this workload) shipping in the tree as the intended receipts-and-blocks engine, wired in after v6.6 | +| RPC-node storage | Dedicated EVM state-store split (`evm-ss-split`) targeting ~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; Autobahn integration harness | + +Node operators should follow the [node configuration reference](/node/node-operators#giga-storage-and-giga-executor) rather than this page for exact keys and defaults. + +## 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 L1 | +| **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 formed from `f + 1` votes that a proposal's data is retrievable | +| **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 committing 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 recovers from blips without throughput loss | +| **Ordering finality** | The transaction order is irrevocably fixed by consensus (the sub-250 ms signal) | +| **State attestation finality** | A 2/3 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; this is what validators attest | +| **LtHash** | Homomorphic multiset hash used for divergence digests; updates incrementally, in any order | +| **BUD (Block Update Digest)** | Per-block Merkle root over that block's state updates; 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 pricing duplicate submissions made for censorship resistance | +| **Sedna** | Giga's private dissemination layer (its own roadmap milestone): rateless-coded, addressed bundles with until-decode privacy | +| **PIVOT-K** | Sedna's incentive mechanism: bounties on decode-pivotal bundles plus a sender ratchet against withholding | +| **Ambulance** | Planned consensus upgrade replacing timeout-based leader recovery with a rigged race among replicas | +| **Hermes** | Next-generation consensus protocol after Autobahn (whitepaper forthcoming) | +| **Ares / Eidos** | The execution-client and storage rebuild upgrades currently shipping Giga components to the live network | + +## 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-protocol/sei-chain](https://github.com/sei-protocol/sei-chain), the open-source implementation + +_Last updated July 2026, based on the Giga whitepaper v2.0 (June 29, 2026) and the sei-chain v6.6 release line._ diff --git a/learn/sei-giga.mdx b/learn/sei-giga.mdx index bd6cbe0..6bef404 100644 --- a/learn/sei-giga.mdx +++ b/learn/sei-giga.mdx @@ -1,342 +1,195 @@ --- -title: 'Sei Giga Overview: The Fastest EVM Blockchain' +title: 'What Is Sei Giga?' sidebarTitle: 'Overview' -description: 'A comprehensive technical overview of Sei Giga - a high-performance blockchain platform combining EVM compatibility with groundbreaking consensus, execution, and storage innovations for unprecedented throughput and sub-second finality.' -keywords: ['sei giga', 'evm blockchain', 'autobahn consensus', 'parallel execution', 'blockchain performance', '5 gigagas', 'sub-second finality'] +description: '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.' +keywords: ['sei giga', 'multi-proposer blockchain', 'autobahn consensus', 'evm layer 1', 'gigagas', 'asynchronous execution', 'parallel execution', '200000 tps', 'sub-250ms finality'] --- -## Introduction +import { GigaProposerComparison, GigaAsyncPipeline, GigaTxJourney, GigaRoadmapTrack } from '/snippets/giga-diagrams.jsx'; -Sei Giga represents a high-performance blockchain platform designed to address the persistent challenges of the "blockchain trilemma": the difficulty of simultaneously optimizing for security, decentralization, and performance. The platform combines current optimizations with upcoming architectural innovations to achieve exceptional performance while maintaining security guarantees and developer experience. +Sei Giga will be the next generation of the Sei protocol following the Giga Upgrade, designed to be the first Multi-Proposer EVM Layer 1. Every validator will propose transactions at the same time, consensus will finalize only the order of those transactions, and execution and state attestation will happen afterwards, off the critical path. On an internal devnet of 40 nodes across 20 regions, Giga sustained more than 5 gigagas per second (5 billion gas per second) with ordering finality under 250 ms, which works out to roughly 200,000 transactions per second. Giga will ship as a series of in-place upgrades to the live Sei network rather than as a new chain. -**Current Features**: Sei operates with Twin Turbo consensus optimizations, parallel execution capabilities, and SeiDB storage, delivering significant performance improvements over traditional blockchains. + + **Status (July 2026):** The [Giga whitepaper v2.0](https://arxiv.org/abs/2505.14914) was published in June 2026. The execution rebuild (Ares), storage rebuild (Eidos), and the EVM-only consolidation ([SIP-3](/learn/sip-03-migration)) are in progress on the live network today; the Autobahn consensus testnet is the next milestone on the [official roadmap](https://giga.seilabs.io). See [How Sei Giga will ship](#how-will-sei-giga-ship) below. Giga functionality described on this page is forward-looking and subject to change until each upgrade activates on the Sei network. + -**Upcoming Features**: Advanced features including Autobahn consensus, multi-proposer architecture, and 5 gigagas throughput targets are in development and represent the next evolution of the platform. +## Sei Giga at a glance -## Current Architecture +| 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 latency | 1.5 network round trips per commit (Tendermint needs 3 full rounds) | +| 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; 200,000+ TPS | +| 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 | +| Mempool | No traditional public mempool; transactions will route through [Sedna](/learn/sei-giga-specs#sedna-private-dissemination) into validator proposal lanes | +| 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 | BFT with `n = 3f + 1` validators; safety unconditional, liveness under partial synchrony | +| Delivery | Phased, in-place upgrades of the live Sei network, keeping the existing chain ID | -Sei's current system delivers significant performance improvements through three core components: +## Why does Sei Giga exist? -### 1. Twin Turbo Consensus +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: -The current consensus mechanism achieves ~400ms block times through aggressive optimization of the Tendermint BFT consensus engine. Key features include: +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. -- Pipelined block processing -- Optimistic transaction execution during consensus -- Aggressive timeout configurations -- Parallel transaction decoding and validation +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. -[Learn more about Twin Turbo Consensus →](/learn/twin-turbo-consensus) +## How will Sei Giga work? -### 2. Parallel Execution Engine +Giga will separate the work of a blockchain into four decoupled stages: data dissemination, ordering, execution, and state attestation. Each stage will run concurrently rather than blocking the next. -Sei implements Optimistic Concurrency Control (OCC) for parallel transaction execution: +### Autobahn consensus -- Multiple CPU cores process non-conflicting transactions simultaneously -- Automatic conflict detection and resolution -- Maintains deterministic execution order -- Compatible with standard EVM semantics +Giga will order transactions with [Autobahn](https://arxiv.org/abs/2401.10369), a Byzantine Fault Tolerant consensus protocol that separates data dissemination from ordering: -[Learn more about the Parallelization Engine →](/learn/parallelization-engine) +- Each validator will continuously stream batches of transactions ("cars") into its own hash-chained lane, in parallel with every other validator. +- A batch will be certified by a Proof of Availability (PoA) once `f + 1` validators vote that they hold the data, which is enough to guarantee at least one honest holder. +- Consensus will periodically commit a cut: a snapshot of the latest certified tip of every lane. Lanes are hash-chained, so committing a tip implicitly commits everything behind it, and one consensus decision can finalize many blocks of data at once. +- The ordering vote will take 1.5 network round trips with pipelined slots, versus three full rounds for Tendermint, and validators will vote on compact certificates instead of downloading full blocks first. -### 3. SeiDB Storage System + -A specialized database optimized for blockchain workloads: +Throughput will scale with the number of validators disseminating data instead of being capped by one leader's connection; Sei Labs cites over 50 times Tendermint's throughput, with standard BFT safety intact. The full protocol is in the [consensus specification](/learn/sei-giga-specs#consensus-autobahn). -- Multi-level caching for hot state data -- Optimized Merkle Patricia Trie structure -- Concurrent state access controls -- Efficient state versioning and pruning +### Asynchronous execution and state attestation -[Learn more about SeiDB →](/learn/seidb) +Giga will provide two distinct finality signals: -## Upcoming Sei Giga Architecture +- Ordering finality: consensus has fixed the transaction order irrevocably. This is the sub-250 ms signal, and for most applications it will be the moment a transaction is final. +- State attestation finality: validators have executed the block, computed a compact divergence digest over its write log, and a 2/3 quorum has attested to that digest in a later block. -The next evolution of Sei Giga will introduce three key innovations designed to achieve target performance characteristics: + -### 1. Asynchronous Execution Model (Upcoming) +Execution will be deterministic, so every honest node that executes the same ordered transactions from the same state will compute the identical result, and ordering will continue while execution catches up. If fewer than 1/3 of validators diverge (a hardware fault or software bug), the chain will keep running while the fault is isolated; a divergence beyond the Byzantine threshold will halt the chain, exactly as in any BFT system. Signing two different digests for the same block will be slashable equivocation. -A planned architectural enhancement will implement complete separation of consensus and execution. Unlike traditional blockchains where these processes are tightly coupled, the upcoming Sei Giga architecture will reach consensus solely on the ordering of transactions within a block, not the resulting state change. +### Parallel execution -**Asynchronous Execution Architecture** +Once ordering is final, each block will execute across all CPU cores using optimistic concurrency control: - - - 1. Order Transactions - 2. Execute & Compute State - 3. Reach Consensus on State - 4. Finalize Block +- 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. - ⚠️ Execution delays consensus - - - 1. Order Transactions - 2. Consensus on Order - 3. Finalize Block n - - **Parallel Process:** - - Execute Block $n - 1$ - - Commit State in Block $n+x$ - - ✓ Consensus proceeds independently - - - -This approach leverages the key property of deterministic execution: +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). -**Lemma 1 (Deterministic Execution)**: Given the same initial state ($S_{init}$) and the same ordered sequence of transactions (${tx}_1, {tx}_2, ..., {tx}_n$), all honest nodes executing these transactions will arrive at the exact same final state ($S_{final}$). +### Flat storage and lattice hashes -Key benefits of this model: +Giga's storage layer is designed for a network that will produce petabytes of new data per year at full load: -- **Non-blocking consensus**: Heavy computational blocks don't delay consensus -- **Pipelined processing**: Multiple blocks can be in different stages simultaneously -- **Optimized resource usage**: Consensus and execution use different hardware resources +- 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. -### 2. Autobahn Consensus Protocol (Upcoming) +The [Eidos upgrade](#how-will-sei-giga-ship) is delivering this storage model to the live network, and its first production pieces (FlatKV with lattice hashing) already ship in `sei-chain`. Details are in the [storage specification](/learn/sei-giga-specs#storage). -**Future Features**: The Autobahn consensus protocol described here represents upcoming enhancements. The current system uses optimized Tendermint consensus (Twin Turbo). +## What will change from today's Sei? -The upcoming Sei Giga will employ Autobahn, a Byzantine Fault Tolerant (BFT) consensus protocol designed for high performance blockchain networks. Unlike traditional single-proposer systems, Autobahn will enable multiple validators to propose blocks simultaneously, targeting significant throughput improvements while maintaining security guarantees. +| 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, 1.5 round trips, sub-250 ms | +| 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 + FlatKV) | 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; transactions will route through [Sedna](/learn/sei-giga-specs#sedna-private-dissemination) into validator lanes | +| 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)) | -**Autobahn Consensus Architecture** +## What will happen to a transaction on Sei Giga? - - - - **Lane $\ell_1$**: ${Prop}_1$, ${Prop}_2$, ${Prop}_3$, $Tip$ - - **Lane $\ell_2$**: ${Prop}_1$, ${Prop}_2$, $Tip$, ... - - **Lane $\ell_n$**: ${Prop}_1$, ${Prop}_2$, ${Prop}_3$, $Tip$ +Giga will have no traditional public mempool: instead of waiting in a shared pending pool, a submitted transaction will route through [Sedna](/learn/sei-giga-specs#sedna-private-dissemination), Giga's private dissemination layer, into validator proposal lanes. Sedna will spread transaction fragments across lanes and reassemble them only after ordering, so no single validator will see the whole transaction before its position is fixed. - Each validator maintains independent lane. - - - $Cut = [{Tip}_1, {Tip}_2, ..., {Tip}_n]$ - - Periodic ordering of lane tips. + - 1. **Prepare Phase** — Leader collects tips, forms Cut - 2. **Fast Path** ($n$ votes) — Immediate commit if all agree - 3. **Slow Path** ($2f+1$ votes) — Additional round if needed +1. You will send a signed transaction to an RPC node, which will route it toward a validator. Allocation will be stake-weighted, and you will be able to submit the same transaction to several validators for censorship resistance. +2. The validator will append the transaction to its next batch and chain that batch into its lane. +3. Once `f + 1` validators acknowledge the batch, it will hold a Proof of Availability and the lane tip will advance. +4. The consensus leader will commit a cut of all lane tips in 1.5 round trips. Your transaction's position will now be fixed. This is ordering finality; on the internal devnet it arrived in under 250 ms. +5. Every node will merge the cut into one sequence using the deterministic tip-priority rule, drop duplicates by hash, and execute the result in parallel. Duplicate copies will not execute and will not pay execution costs twice. +6. Validators will attest to the block's divergence digest in a later block. This is state attestation finality. - Global ordering through BFT agreement. - - +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). -**Protocol Properties** +## How will Giga handle MEV and fees? - - - $n = 3f + 1$ replicas - - - Unconditional - - - Eventual synchrony - - +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 protocol operates through two complementary layers: +- The merge rule will be deterministic. The order of transactions within a committed cut will be a pure function of lane contents: lanes will sort by their highest included tip, intra-lane order will be preserved, and duplicates will be dropped. Arrival timing and proposer discretion will play no part. +- Priority fees will be socialised. Fees from each epoch will be pooled and distributed to validators by stake and measured liveness, not paid to whichever proposer carried the transaction. Copying someone else's high-tip transaction into your own lane will earn the copier nothing extra, and routing deals with specific proposers will have no protocol revenue to capture. Under this design, a tip pays for position in the order and nothing else. +- Fees will come in three parts: an EIP-1559-style execution fee, a strictly enforced ordering fee (the priority fee), and a distribution fee that will price duplicate submissions. Duplicates will be deduplicated at merge time, and only one copy will execute; the rest will be refunded part of their tip. +- Sedna will add pre-execution privacy. Transactions will travel through [Sedna](/learn/sei-giga-specs#sedna-private-dissemination) as coded fragments spread across lanes, so their contents will stay hidden until ordering is final — a design intended to leave no visible pending transaction to front-run. -**Data Dissemination Layer (Lanes)**: +The full mechanism is specified in [MEV and fee design](/learn/sei-giga-specs#mev-and-fee-design). -- Each validator maintains an independent lane for proposing transaction batches -- Three-step certification process: Propose → Vote → Proof of Availability (PoA) -- Chained proposals ensure availability of historical data +## How will Sei Giga ship? -**Consensus Layer (Cut of Tips)**: +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 July 2026: -- Periodic ordering of latest certified tips from all lanes -- Two-phase BFT agreement with fast and slow paths -- Pipelined slots for minimal latency + -### 3. Advanced Parallel Execution +| 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 | +| Ares upgrade | Execution client rebuilt for Giga-scale throughput on existing consensus: pipelined parsing, validation, and signature checks; receipts and indexing moved off the commit path; VM efficiency work; live deployment to mainnet | In progress | +| Eidos upgrade | Storage rebuild: Merkle trees replaced by a flat key-value store with lattice hashes; embedded DB for hot state, horizontally scalable cold archive; engines built specifically for receipts, logs, and blocks | In progress | +| 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 | -The parallel execution architecture extends beyond current OCC capabilities to include: +Parts of this are already in the `sei-chain` codebase. As of July 2026 the Giga execution engine ships in [sei-chain](https://github.com/sei-protocol/sei-chain) and runs by default (with OCC) from the v6.6 release line, while Autobahn consensus and the FlatKV/lattice-hash storage stack ship in the same binary behind operator flags, disabled until their network activations. Node operators can review the [Giga executor configuration](/node/node-operators#giga-storage-and-giga-executor) and the [Giga storage migration guide](/node/giga-storage-migration). -**Parallel Execution Pipeline** + + There is no public Giga testnet yet (as of July 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). + - - - **Transaction Parsing** +## Measured performance - Parallel decode - - - **Dependency Analysis** +Each row carries its source and date: the devnet figures are Sei Labs' internal measurements, the consensus multipliers are whitepaper claims, and the testnet figures are targets. - Conflict prediction - - - **Parallel Execution** +| 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) | +| Transactions per second | 200,000+ | Simple transfers at 5 gigagas/s (21,000 gas each) | [Roadmap](https://giga.seilabs.io) and whitepaper (2025 and 2026) | +| Consensus round trips | 1.5 (vs 3 in Tendermint) | Autobahn pipelined slow path | 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) | - Multi-core OCC - - - **State Commit** +## Learn more - Batch writes + + + The full protocol spec: Autobahn, asynchronous execution, storage, MEV and fee design, security model, and glossary. - - - - - - Read/Write set tracking - - Optimistic execution - - Automatic re-execution on conflict - - Preserves deterministic ordering + + What will change for contracts and apps: finality semantics, fees, proofs, and parallel-friendly patterns. - - - ~65% of ETH txs parallelizable - - Linear scaling with cores - - Minimal conflict overhead - - Zero-copy transaction handling + + The canonical specification on arXiv (Marsh, Landers, Jog, Ranchal-Pedrosa; June 2026). - - -Key innovations in the execution model: - -- **Flat encoding format**: Length-prefixed layout for fast, zero-copy decoding -- **Predictive conflict analysis**: ML-based prediction of transaction dependencies -- **Semantic understanding**: Special handling for common patterns (ERC-20 transfers) -- **Adaptive parallelism**: Dynamic adjustment based on conflict rates - -## Storage Architecture Evolution - -Beyond the current SeiDB capabilities, the Sei Giga architecture includes advanced storage innovations: - -**Hybrid Storage Architecture** - - - - - **Recent Blocks** — High-speed NVMe SSDs - - **Active State** — Memory-mapped files - - **Access Pattern** — Sub-ms latency + + Live milestone tracker for the Giga upgrade. - - - **Recent History** — Standard SSDs - - **Compressed State** — LZ4 compression - - **Access Pattern** — 1-10ms latency + + The EVM-only consolidation that clears the path to Giga. - - - **Historical Data** — Distributed storage - - **Columnar Format** — Analytics optimized - - **Access Pattern** — Batch queries + + Twin Turbo consensus, the parallelization engine, and SeiDB: the system Giga will supersede. - + -**Cryptographic Layer** - - - - LSM-tree based - - - Compact proofs - - - Durability guarantee - - - -## Economic Model - -Sei operates with a native SEI token that serves multiple functions within the ecosystem: - -### Token Distribution - -- **Total Supply**: 10,000,000,000 (10 billion) SEI -- **Initial Distribution**: Allocated across ecosystem participants, validators, and development - -### Token Utility - -1. **Gas Fees**: All transactions require SEI for execution -2. **Staking**: Validators and delegators stake SEI to secure the network -3. **Governance**: SEI holders participate in protocol governance -4. **Rewards**: Block rewards and fee distribution to validators - -### Staking Mechanics - -**Staking & Validation** - - - - - **Self-Stake Requirement** — Minimum SEI to operate - - **Commission Rate** — Set by validator - - **Responsibilities** — Consensus & execution - - - - **Delegation** — Stake with chosen validators - - **Rewards** — Proportional to stake - - **Unbonding** — 21-day period - - - -**Slashing Conditions** - - - - Penalties for downtime - - - Severe penalties for double-signing - - - -## Developer Experience - -Sei maintains full EVM compatibility while providing enhanced capabilities: - -### Standard EVM Features - -- Complete support for Solidity and Vyper -- Standard JSON-RPC endpoints -- Compatible with existing tools (Hardhat, Foundry, Remix) -- Familiar development workflow - -### Enhanced Capabilities - -- Sub-second transaction finality -- Predictable gas costs -- High throughput for complex applications -- Advanced storage access patterns - -## Implementation Status - -**Current & Upcoming Features** - - - - - ~400ms blocks - - - Multi-core processing - - - Optimized state access - - - - - - - - Multi-proposer protocol - - - Performance target - - - Enhanced execution - - - - -## Learn More - -Explore the technical components that make Sei's performance possible: - -- [Twin Turbo Consensus →](/learn/twin-turbo-consensus) -- [Parallelization Engine →](/learn/parallelization-engine) -- [SeiDB Storage →](/learn/seidb) -- [Developer Guide →](/learn/sei-giga-developers) +_Last updated July 2026_ diff --git a/node/node-operators.mdx b/node/node-operators.mdx index 04e2fc6..3d2dd9b 100644 --- a/node/node-operators.mdx +++ b/node/node-operators.mdx @@ -518,14 +518,14 @@ worker_queue_size = 1000 ############################################################################### [giga_executor] -# enabled controls whether to use the Giga executor (evmone-based) instead of geth's interpreter. -# This is an experimental feature for improved EVM throughput. -# Default: false +# enabled controls whether to use the Giga executor instead of the legacy execution path. +# Improves EVM throughput. +# Default: false through v6.5.x; true from the v6.6 release line. enabled = false # occ_enabled controls whether to use OCC (Optimistic Concurrency Control) with the Giga executor. # When true, transactions are executed in parallel with conflict detection and retry. -# Default: false +# Default: false through v6.5.x; true from the v6.6 release line. occ_enabled = false ############################################################################### @@ -1450,10 +1450,9 @@ ss-keep-recent = 100000 # snapshot creation. ss-prune-interval = 600 -# Optional EVM SS routing — same semantics as the SC modes above. Leave on -# cosmos_only unless you have completed the Giga SS Store migration. -evm-ss-write-mode = "cosmos_only" -evm-ss-read-mode = "cosmos_only" +# EVM state-store split. Leave false unless you have completed the Giga +# SS Store migration (RPC nodes only); see the migration guide. +evm-ss-split = false evm-ss-separate-dbs = false [receipt-store] @@ -1470,45 +1469,33 @@ longer overall, which can cause missed blocks and excessive resync time. ### Giga Storage and Giga Executor -These are two **separate** opt-in features that ship in newer `seid` -releases. Both default to off; only enable them deliberately and after -following the relevant migration guide. +These are two **separate** features that ship in newer `seid` releases. **Giga Storage** repartitions SeiDB so EVM state lives in its own databases at both the SC and SS layers, freeing non-EVM modules from EVM -write amplification. - -For step-by-step instructions — including the full state-sync flow, startup verification, safety checks, and rollback — see the [Giga SS Store Migration Guide](/node/giga-storage-migration). The snippet below is just the resulting `app.toml` shape. - - -```toml -[state-commit] -sc-write-mode = "dual_write" # write EVM data to memiavl AND FlatKV -sc-read-mode = "split_read" # read EVM data from FlatKV -sc-enable-lattice-hash = true # required for split-mode app-hash equality - -[state-store] -evm-ss-write-mode = "split_write" -evm-ss-read-mode = "split_read" -``` - -Enabling Giga Storage requires a fresh state sync — flipping the EVM SS -modes on a node with existing data fails the startup safety checks because -the new EVM SS DB starts empty while Cosmos SS already has history. The -full procedure is in the -[Giga SS Store Migration Guide](/node/giga-storage-migration) and is +write amplification. It is opt-in on every release, and enabling it +requires a fresh state sync: turning on the EVM SS split on a node with +existing data fails the startup safety checks, because the new EVM SS DB +starts empty while Cosmos SS already has history. The full procedure, +including the exact `app.toml` keys, startup verification, safety checks, +and rollback, is in the +[Giga SS Store Migration Guide](/node/giga-storage-migration). It is currently supported on **RPC nodes only**; validators and archive nodes are not yet covered. -**Giga Executor** is independent of Giga Storage. It swaps the EVM -interpreter from go-ethereum's geth to an evmone-based executor for -higher throughput, with optional OCC parallelism on top: +**Giga Executor** is independent of Giga Storage. It routes EVM +transactions through the Giga execution engine, built on Sei's go-ethereum +fork, instead of the legacy execution path, with optional OCC parallelism +on top. It is disabled by default through v6.5.x and enabled by default, +together with OCC, from the v6.6 release line: ```toml [giga_executor] -# Use the evmone-based executor instead of geth's interpreter. Experimental. +# Use the Giga execution engine instead of the legacy path. +# Default: false through v6.5.x; true from the v6.6 release line. enabled = false # Run Giga-executed txs in parallel with Optimistic Concurrency Control. +# Default: false through v6.5.x; true from the v6.6 release line. occ_enabled = false ``` diff --git a/scripts/generate-llms.mjs b/scripts/generate-llms.mjs index c39db95..c1c255f 100644 --- a/scripts/generate-llms.mjs +++ b/scripts/generate-llms.mjs @@ -28,7 +28,7 @@ const SEI_LLMS_CONFIG = { blockquote: 'Technical documentation for Sei — a parallelized EVM Layer 1 with sub-second finality, full Ethereum tooling compatibility, and a clear roadmap toward Sei Giga (200K TPS, 5 gigagas/s).', intro: - 'Sei is a parallelized EVM Layer 1 blockchain with 400ms finality, ~100 MGas/s throughput today, and full Ethereum tooling compatibility. Deploy standard Solidity contracts with no modifications. Chain ID: mainnet 1329, testnet 1328. The next major upgrade, Sei Giga, targets 200K TPS via Autobahn multi-proposer BFT consensus and a custom EVM execution engine.', + 'Sei is a parallelized EVM Layer 1 blockchain with 400ms finality, ~100 MGas/s throughput today, and full Ethereum tooling compatibility. Deploy standard Solidity contracts with no modifications. Chain ID: mainnet 1329, testnet 1328. The next major upgrade, Sei Giga, will target 200K TPS via Autobahn Multi-Proposer BFT consensus and a custom EVM execution engine.', constraints: [ 'Prerequisites: Node.js ≥ 18, a wallet (Compass, Rabby, MetaMask, or any EVM-compatible wallet), and SEI tokens for gas.', 'Authentication: No API key is required for public RPC endpoints. Rate limits apply — use a dedicated provider (Ankr, DRPC, Nirvana) for production workloads.', @@ -138,7 +138,7 @@ const LLMS_SECTION_ORDER = [ match: (p) => p.startsWith('/learn'), overview: [ "Sei is a parallelized EVM Layer 1 blockchain. Performance comes from Twin Turbo Consensus (optimistic block processing), parallel EVM execution (concurrent transactions on independent state), and SeiDB (high-throughput storage). Full Ethereum tooling compatibility — deploy standard Solidity contracts with no modifications.", - "Sei Giga is the next major upgrade targeting 200K TPS and 5 gigagas/s via Autobahn multi-proposer BFT consensus and a custom EVM execution engine. For developers, Sei Giga's parallel engine rewards contracts with user-scoped state (mapping per address) over shared global state.", + "Sei Giga, the next major upgrade, will target 200K TPS and 5 gigagas/s via Autobahn Multi-Proposer BFT consensus and a custom EVM execution engine. For developers, Sei Giga's parallel engine will reward contracts with user-scoped state (mapping per address) over shared global state.", 'Mainnet (pacific-1): chain ID 1329. Testnet (atlantic-2): chain ID 1328.', 'SIP-03 migration: inbound/outbound IBC transfers are being disabled. Holders of IBC assets must swap, migrate, or bridge out before the governance proposal activates.' ].join('\n\n') diff --git a/snippets/giga-diagrams.jsx b/snippets/giga-diagrams.jsx new file mode 100644 index 0000000..417f5e9 --- /dev/null +++ b/snippets/giga-diagrams.jsx @@ -0,0 +1,732 @@ +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 ( +
+
+ + + + + + + + + + + Single proposer (Tendermint-style) + {lanes.map((i) => ( + + + V{i + 1} + + ))} + leader + {[0, 2, 3].map((i) => ( + + ))} + votes + + + block h + one block per round + + {[0, 1, 2].map((i) => ( + + + {['h-2', 'h-1', 'h'][i]} + + ))} + throughput capped by one leader's bandwidth + + + + Multi-Proposer (Sei Giga) + {lanes.map((i) => ( + + + V{i + 1} + {[0, 1, 2].map((j) => ( + + + {j < 2 ? : null} + + ))} + + ))} + every validator streams its own lane + tips + + + + cut of tips + one consensus slot + commits all lanes + bandwidth scales with the validator count + +
+
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.
+
+ ); +}; + +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 ( +
+
+ + + + + + + {rows.map((r) => ( + + {r.label} + + + ))} + {[0, 1, 2, 3].map((i) => ( + + + order n{i > 0 ? '+' + i : ''} + + ))} + {[0, 1, 2].map((i) => ( + + + execute n{i > 0 ? '+' + i : ''} + + ))} + + attest n: 2/3 sign digest D_n + + + ordering finality for n + + attestation for n lags by x blocks + + state attestation finality for n + + + time + +
+
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.
+
+ ); +}; + +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: 'f+1 availability votes' }, + { t: 'ordered', s: 'cut committed' }, + { t: 'executed', s: 'merged, run in parallel' }, + { t: 'attested', s: 'digest signed by 2/3' } + ]; + return ( +
+
+ + + + + + + {steps.map((st, i) => { + const x = 76 + i * 150; + const strong = i === 3 || i === 5; + return ( + + {i < steps.length - 1 ? : null} + + {i + 1} + {st.t} + {st.s} + + ); + })} + ordering finality + + state attestation finality + + +
+
The six stops of a Giga transaction. With no traditional public mempool, step 2 will happen immediately, and step 4 will fix the order irrevocably.
+
+ ); +}; + +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: 'Ares', s: 'prog' }, + { l: 'Eidos', 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 ( +
+
+ + + + + {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 ( + + + {it.s === 'done' ? : null} + {it.s === 'prog' ? : null} + + {it.l} + + ); + })} + + complete + + in progress (July 2026) + + coming soon + +
+
The eleven roadmap milestones from giga.seilabs.io. Ares, Eidos, and SIP-3 are live workstreams on the network today; the Autobahn testnet is next.
+
+ ); +}; + +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 ( +
+
+ + + + + + + + + + + committing a tip implicitly commits everything behind it + {lanes.map((i) => ( + + + V{i + 1} + {[0, 1, 2, 3].map((j) => ( + + + pos {j} + batch + {j < 3 ? : null} + + ))} + tip + + ))} + arrows: parentRef hash-chains each proposal to its predecessor + + + + f + 1 votes + Proof of Availability + + + + + cut = [tip 1, tip 2, tip 3] + + + committed in one slot + Prepare, then Commit + + missing batch data is fetched after commit, + off the critical path + +
+
Each validator will chain batches into its own lane and certify them with f + 1 availability votes. Consensus will only ever order the vector of lane tips.
+
+ ); +}; + +export const GigaSlotPipeline = () => { + const ink = 'currentColor'; + const accent = 'var(--sei-maroon-50)'; + const slots = [0, 1, 2]; + return ( +
+
+ + + + + + + {slots.map((i) => { + const x = 130 + i * 105; + const y = 46 + i * 50; + return ( + + slot s{i > 0 ? '+' + i : ''} + + Prepare (PrepareQC) + + Commit (CommitQC) + + ); + })} + + next slot starts once the Prepare message for s is seen + + + 1 round trip + + +0.5 effective + steady state: 1.5 round trips per cut + +
+
Slots will overlap: replicas will begin slot s+1 as soon as they see the Prepare message for slot s, so the steady-state cost will be 1.5 network round trips per committed cut.
+
+ ); +}; + +export const GigaAttestationFlow = () => { + const ink = 'currentColor'; + const accent = 'var(--sei-maroon-50)'; + const gold = 'var(--sei-gold-25)'; + const blocks = ['n-1', 'n', 'n+1', 'n+2', 'n+x']; + return ( +
+
+ + + + + + + + + + {blocks.map((b, i) => ( + + + block {b} + {i < blocks.length - 1 ? : null} + + ))} + ordering final + + + {[ + { 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) => ( + + + {s.label} + {s.sub} + {i < 2 ? : null} + + ))} + + + digest D_n + compact commitment + + 2/3-signed, included + in block n+x + + + signing two different digests for the same block is slashable equivocation; + divergence under 1/3 of validators isolates the fault, divergence over 1/3 halts the chain + +
+
Execution results will be committed as a lattice-hash digest rather than a state root, and validators will attest to that digest a bounded number of blocks later.
+
+ ); +}; + +export const GigaOccDiagram = () => { + const ink = 'currentColor'; + const accent = 'var(--sei-maroon-50)'; + const workers = ['worker 1', 'worker 2', 'worker 3']; + return ( +
+
+ + + + + + + {workers.map((w, i) => ( + + {w} + + + ))} + + t1 + + t2 writes k + + t3 + + t4 reads k + + t5 + + conflict + + + t4 re-executes + validation caught the stale read + + + + commit in block order + result identical to + sequential execution + + only conflicting transactions re-run; after 10 retries the implementation falls back to sequential execution + +
+
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.
+
+ ); +}; + +export const GigaStorageArchitecture = () => { + const ink = 'currentColor'; + const accent = 'var(--sei-maroon-50)'; + const gold = 'var(--sei-gold-25)'; + return ( +
+
+ + + + + + + state path + + execution: reads served from RAM + + + flat key-value store (LSM tree) + no per-write Merkle updates + + append-only WAL + crash recovery + + async + + + hot tier: local high-performance SSDs + + + cold tier: distributed columnar store + + commitment path + + write log of block n + + + lattice hash d_n (LtHash) + incremental, order-independent + + + D_n attested by 2/3 quorum + + disputes: compare chunk digests, + bisect, replay one range + +
+
The write path will never touch a Merkle tree: state will live in a RAM-first flat store with an append-only WAL, while commitments will come from a homomorphic lattice hash over each block's write log.
+
+ ); +}; + +export const GigaBudWindow = () => { + const ink = 'currentColor'; + const accent = 'var(--sei-maroon-50)'; + const gold = 'var(--sei-gold-25)'; + const leaves = ['(key a, value, n, prev)', '(key b, value, n, prev)', '(key c, value, n, prev)']; + return ( +
+
+ + + + + + + {leaves.map((l, i) => ( + + + {l} + + + ))} + this block's writes, sorted by key + + root U_n + + + attested with D_n + same 2/3 quorum schedule + + proof = Merkle path to attested U_n; + two proofs bracket an unmodified span + cost scales with the block's updates + + + {Array.from({ length: 17 }, (_, i) => ( + + ))} + blocks + {[0, 1, 2, 3].map((i) => ( + + ))} + SuperBUD, e blocks + + guaranteed proof window: the last e^Lmax blocks (governance-set); older claims need archive nodes + touch transactions refresh a stale key's anchor; deletions leave tombstones for exclusion proofs + +
+
Every block will get a Merkle root over just its own updates. SuperBUDs will aggregate those roots over exponentially sized windows so provers can cover long ranges with a handful of digests.
+
+ ); +}; + +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 ( +
+
+ + + + + + + new transactions per lane + {lanesIn.map((ln, i) => ( + + {ln.v} + max {ln.max} + {ln.txs.map((tx, j) => ( + + + {tx.n} · tip {tx.t} + + ))} + + ))} + + 1. sort lanes + by max tip + + lane order: V2, V3, V1 + {sorted.map((li, i) => ( + + {i + 1} + {lanesIn[li].txs.map((tx, j) => ( + + + {lanesIn[li].v}: {tx.n} + + ))} + + ))} + 2. intra-lane order preserved + + + 3. dedupe + executable sequence + {['c', 'd', 'f', 'e', 'a', 'e'].map((n, i) => { + const dup = i === 5; + return ( + + + {i + 1}. {n}{dup ? ' (duplicate hash)' : ''} + + ); + })} + dropped copy gets a partial tip refund + +
+
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.
+
+ ); +}; + +export const GigaFinalitySignals = () => { + const ink = 'currentColor'; + const accent = 'var(--sei-maroon-50)'; + const gold = 'var(--sei-gold-25)'; + return ( +
+
+ + + + + + + + transaction lands + in a committed cut + + + + ordering finality + receipt available; no reorgs + + + trading UX, games, payments, + most dApp flows + + + + state attestation finality + 2/3-signed digest, x blocks later + + + exchange deposits, bridges, + high-value settlement, BUD proofs + + the outcome is already decided at ordering finality; attestation adds a signed confirmation of it + +
+
Two confirmation signals, two audiences: act on the receipt for interactive flows, and wait for the attested digest when third-party value moves on the result.
+
+ ); +}; + +export const GigaParallelismContrast = () => { + const ink = 'currentColor'; + const accent = 'var(--sei-maroon-50)'; + const users = [0, 1, 2, 3]; + return ( +
+
+ + + + + + + + + + isolated state: one wave + {users.map((i) => ( + + + tx{i + 1} + + + balances[user{i + 1}] + + ))} + disjoint write sets: all four execute simultaneously + + + + hot slot: one at a time + {users.map((i) => ( + + + tx{i + 1} + + + ))} + + totalTransfers++ + every transaction writes this slot, + so they re-run in sequence: 1, 2, 3, 4 + conflicting write sets: parallelism lost for the block + +
+
The same four transfers, two storage layouts. Per-user slots let Block-STM commit everything in one pass; a shared counter forces retries until the transactions run one by one.
+
+ ); +}; + +export const GigaFeeSplit = () => { + const ink = 'currentColor'; + const accent = 'var(--sei-maroon-50)'; + const gold = 'var(--sei-gold-25)'; + const parts = [ + { x: 60, w: 300, label: 'execution fee', sub: '1559-style base fee', to: 'pays for gas actually consumed', c: null }, + { x: 360, w: 240, label: 'ordering fee (tip)', sub: 'buys a position in the order', to: 'socialised: epoch pool, stake x liveness', c: 'accent' }, + { x: 600, w: 200, label: 'distribution fee', sub: 'prices duplicate copies', to: 'only one copy executes; partial refund', c: 'gold' } + ]; + return ( +
+
+ + {parts.map((p) => { + const fill = p.c === 'accent' ? accent : p.c === 'gold' ? gold : ink; + const op = p.c ? 0.16 : 0.06; + return ( + + + {p.label} + {p.sub} + + {p.to} + + ); + })} + one transaction, three priced things + tipping a specific proposer buys nothing: the pool pays validators by stake and measured liveness + +
+
Execution, ordering, and duplicate distribution will be priced separately. The tip will be strictly enforced for ordering and then socialised across the validator set.
+
+ ); +};