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

# Building on Sei Giga: What Changes for Developers

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

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 <div className="not-prose w-full my-5">
      <div className="overflow-x-auto rounded-xl border border-neutral-200 dark:border-neutral-800 bg-white/60 dark:bg-neutral-900/40 p-4 text-neutral-800 dark:text-neutral-200">
        <svg viewBox="0 0 860 190" role="img" aria-label="The three components of a Giga transaction fee" style={{
    width: '100%',
    minWidth: 620,
    height: 'auto',
    display: 'block'
  }}>
          {parts.map(p => {
    const fill = p.c === 'accent' ? accent : p.c === 'gold' ? gold : ink;
    const op = p.c ? 0.16 : 0.06;
    return <g key={p.label}>
                <rect x={p.x} y={46} width={p.w - 8} height={44} rx={7} fill={fill} fillOpacity={op} stroke={fill} strokeOpacity={p.c ? 0.9 : 0.4} strokeWidth="1.1" />
                <text x={p.x + (p.w - 8) / 2} y={65} fontSize="11" textAnchor="middle" fontWeight="600" fill={ink}>{p.label}</text>
                <text x={p.x + (p.w - 8) / 2} y={81} fontSize="9.5" textAnchor="middle" fill={ink} fillOpacity="0.65">{p.sub}</text>
                <line x1={p.x + (p.w - 8) / 2} y1={94} x2={p.x + (p.w - 8) / 2} y2={112} stroke={ink} strokeOpacity="0.35" strokeWidth="1" />
                <text x={p.x + (p.w - 8) / 2} y={128} fontSize="9.5" textAnchor="middle" fill={ink} fillOpacity="0.8">{p.to}</text>
              </g>;
  })}
          <text x={60} y={30} fontSize="11.5" fontWeight="600" fill={ink}>one transaction, three priced things</text>
          <text x={430} y={166} fontSize="9.5" textAnchor="middle" fill={ink} fillOpacity="0.6">tipping a specific proposer buys nothing: the pool pays validators by stake and measured liveness</text>
        </svg>
      </div>
      <div className="mt-2 text-xs text-neutral-500 dark:text-neutral-400">Execution, ordering, and duplicate distribution will be priced separately. The tip will be strictly enforced for ordering and then socialised across the validator set.</div>
    </div>;
};

export const GigaParallelismContrast = () => {
  const ink = 'currentColor';
  const accent = 'var(--sei-maroon-50)';
  const users = [0, 1, 2, 3];
  return <div className="not-prose w-full my-5">
      <div className="overflow-x-auto rounded-xl border border-neutral-200 dark:border-neutral-800 bg-white/60 dark:bg-neutral-900/40 p-4 text-neutral-800 dark:text-neutral-200">
        <svg viewBox="0 0 860 250" role="img" aria-label="Isolated per-user state runs in parallel; a shared hot slot serializes" style={{
    width: '100%',
    minWidth: 620,
    height: 'auto',
    display: 'block'
  }}>
          <defs>
            <marker id="gpv-a" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse">
              <path d="M 0 1 L 9 5 L 0 9 z" fill={ink} fillOpacity="0.6" />
            </marker>
            <marker id="gpv-b" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse">
              <path d="M 0 1 L 9 5 L 0 9 z" fill={accent} />
            </marker>
          </defs>
          <text x={120} y={34} fontSize="12.5" fontWeight="600" fill={ink}>isolated state: one wave</text>
          {users.map(i => <g key={'u' + i}>
              <circle cx={92} cy={64 + i * 44} r={13} fill={ink} fillOpacity="0.08" stroke={ink} strokeOpacity="0.45" />
              <text x={92} y={68 + i * 44} fontSize="9.5" textAnchor="middle" fill={ink} fillOpacity="0.8">tx{i + 1}</text>
              <line x1={110} y1={64 + i * 44} x2={196} y2={64 + i * 44} stroke={accent} strokeWidth="1.5" markerEnd="url(#gpv-b)" />
              <rect x={200} y={50 + i * 44} width={168} height={28} rx={6} fill={ink} fillOpacity="0.05" stroke={ink} strokeOpacity="0.45" />
              <text x={284} y={68 + i * 44} fontSize="9.5" textAnchor="middle" fill={ink} fontFamily="var(--sei-font-mono)">balances[user{i + 1}]</text>
            </g>)}
          <text x={230} y={238} fontSize="10" fill={ink} fillOpacity="0.65" textAnchor="middle">disjoint write sets: all four execute simultaneously</text>

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

          <text x={560} y={34} fontSize="12.5" fontWeight="600" fill={ink}>hot slot: one at a time</text>
          {users.map(i => <g key={'h' + i}>
              <circle cx={492} cy={64 + i * 44} r={13} fill={ink} fillOpacity="0.08" stroke={ink} strokeOpacity="0.45" />
              <text x={492} y={68 + i * 44} fontSize="9.5" textAnchor="middle" fill={ink} fillOpacity="0.8">tx{i + 1}</text>
              <path d={`M 510 ${64 + i * 44} Q 580 ${64 + i * 44} 620 ${118 + (i - 1.5) * 6}`} fill="none" stroke={ink} strokeOpacity="0.45" strokeWidth="1.2" strokeDasharray={i === 0 ? 'none' : '4 3'} markerEnd="url(#gpv-a)" />
            </g>)}
          <rect x={626} y={96} width={180} height={40} rx={6} fill={accent} fillOpacity="0.1" stroke={accent} strokeWidth="1.2" />
          <text x={716} y={120} fontSize="9.5" textAnchor="middle" fill={ink} fontFamily="var(--sei-font-mono)">totalTransfers++</text>
          <text x={716} y={158} fontSize="9.5" textAnchor="middle" fill={ink} fillOpacity="0.7">every transaction writes this slot,</text>
          <text x={716} y={173} fontSize="9.5" textAnchor="middle" fill={ink} fillOpacity="0.7">so they re-run in sequence: 1, 2, 3, 4</text>
          <text x={648} y={238} fontSize="10" fill={ink} fillOpacity="0.65" textAnchor="middle">conflicting write sets: parallelism lost for the block</text>
        </svg>
      </div>
      <div className="mt-2 text-xs text-neutral-500 dark:text-neutral-400">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.</div>
    </div>;
};

export const GigaFinalitySignals = () => {
  const ink = 'currentColor';
  const accent = 'var(--sei-maroon-50)';
  const gold = 'var(--sei-gold-25)';
  return <div className="not-prose w-full my-5">
      <div className="overflow-x-auto rounded-xl border border-neutral-200 dark:border-neutral-800 bg-white/60 dark:bg-neutral-900/40 p-4 text-neutral-800 dark:text-neutral-200">
        <svg viewBox="0 0 860 232" role="img" aria-label="Which finality signal to wait for" style={{
    width: '100%',
    minWidth: 620,
    height: 'auto',
    display: 'block'
  }}>
          <defs>
            <marker id="gfs-a" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="7" markerHeight="7" orient="auto-start-reverse">
              <path d="M 0 1 L 9 5 L 0 9 z" fill={ink} fillOpacity="0.6" />
            </marker>
          </defs>
          <rect x={48} y={92} width={158} height={48} rx={8} fill={ink} fillOpacity="0.05" stroke={ink} strokeOpacity="0.45" />
          <text x={127} y={112} fontSize="10.5" textAnchor="middle" fill={ink}>transaction lands</text>
          <text x={127} y={128} fontSize="9.5" textAnchor="middle" fill={ink} fillOpacity="0.65">in a committed cut</text>

          <line x1={206} y1={104} x2={280} y2={70} stroke={ink} strokeOpacity="0.5" strokeWidth="1.1" markerEnd="url(#gfs-a)" />
          <rect x={284} y={44} width={218} height={52} rx={8} fill={accent} fillOpacity="0.1" stroke={accent} strokeWidth="1.2" />
          <text x={393} y={65} fontSize="10.5" textAnchor="middle" fontWeight="600" fill={ink}>ordering finality</text>
          <text x={393} y={82} fontSize="9.5" textAnchor="middle" fill={ink} fillOpacity="0.7">receipt available; no reorgs</text>
          <line x1={502} y1={70} x2={560} y2={70} stroke={ink} strokeOpacity="0.5" strokeWidth="1.1" markerEnd="url(#gfs-a)" />
          <rect x={564} y={44} width={250} height={52} rx={8} fill={ink} fillOpacity="0.04" stroke={ink} strokeOpacity="0.4" />
          <text x={689} y={65} fontSize="10" textAnchor="middle" fill={ink}>trading UX, games, payments,</text>
          <text x={689} y={81} fontSize="10" textAnchor="middle" fill={ink}>most dApp flows</text>

          <line x1={206} y1={128} x2={280} y2={162} stroke={ink} strokeOpacity="0.5" strokeWidth="1.1" strokeDasharray="4 3" markerEnd="url(#gfs-a)" />
          <rect x={284} y={136} width={218} height={52} rx={8} fill={gold} fillOpacity="0.14" stroke={gold} strokeWidth="1.2" />
          <text x={393} y={157} fontSize="10.5" textAnchor="middle" fontWeight="600" fill={ink}>state attestation finality</text>
          <text x={393} y={174} fontSize="9.5" textAnchor="middle" fill={ink} fillOpacity="0.7">2/3-signed digest, x blocks later</text>
          <line x1={502} y1={162} x2={560} y2={162} stroke={ink} strokeOpacity="0.5" strokeWidth="1.1" markerEnd="url(#gfs-a)" />
          <rect x={564} y={136} width={250} height={52} rx={8} fill={ink} fillOpacity="0.04" stroke={ink} strokeOpacity="0.4" />
          <text x={689} y={157} fontSize="10" textAnchor="middle" fill={ink}>exchange deposits, bridges,</text>
          <text x={689} y={173} fontSize="10" textAnchor="middle" fill={ink}>high-value settlement, BUD proofs</text>

          <text x={393} y={216} fontSize="9.5" textAnchor="middle" fill={ink} fillOpacity="0.6">the outcome is already decided at ordering finality; attestation adds a signed confirmation of it</text>
        </svg>
      </div>
      <div className="mt-2 text-xs text-neutral-500 dark:text-neutral-400">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.</div>
    </div>;
};

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.

<Info>
  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).
</Info>

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

<GigaFinalitySignals />

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)):

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.

<GigaFeeSplit />

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

<GigaParallelismContrast />

### Pattern 1: isolate state per user

```solidity theme={"dark"}
// GOOD: per-user state; transfers between different users run in parallel
contract OptimizedToken {
    mapping(address => uint256) private balances;

    function transfer(address to, uint256 amount) public {
        require(balances[msg.sender] >= amount);
        balances[msg.sender] -= amount;
        balances[to] += amount;
    }
}

// BAD: every transfer writes one global slot, so transfers serialize
contract PoorToken {
    uint256 public totalTransfers; // every transfer conflicts here

    function transfer(address to, uint256 amount) public {
        totalTransfers++; // hot slot: blocks parallelism for the whole block
        // ... transfer logic
    }
}
```

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.

### Pattern 2: prefer mappings over shared arrays

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

### Pattern 3: emit events instead of storing history

```solidity theme={"dark"}
contract EventDrivenAuction {
    mapping(uint256 => uint128) public highestBids;

    // 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);
    }
}
```

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.

### Pattern 4: pack storage you must share

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.

```solidity theme={"dark"}
struct Position {
    uint128 size;      // 128 bits ┐
    uint64  entryTime; // 64 bits  ├─ one storage slot
    uint64  nonce;     // 64 bits  ┘
}
```

## Sei precompiles under the Giga executor

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.

## Prepare your app for Giga today

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

## Related

* [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

*Last updated July 2026, based on the Giga whitepaper v2.0 (June 29, 2026) and the sei-chain v6.6 release line.*