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

# Building on Sei Giga: What Changes for Developers

> What Sei Giga will change for smart contract and dApp developers: EVM parity exceptions, ordering and attestation finality, staged transaction ingress before and after Sedna, BUD state proofs, and parallel-friendly contract patterns.

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">the protocol pools tips and does not pay the carrying proposer directly</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="Ordering finality, execution receipt, and state attestation stages" 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">order fixed; execution pending</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}>execution produces receipt;</text>
          <text x={689} y={81} fontSize="10" textAnchor="middle" fill={ink}>interactive flows evaluate risk</text>

          <path d="M 689 96 Q 689 126 506 158" fill="none" 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 voting-power 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">ordering fixes position; execution yields the result; attestation adds a signed quorum confirmation</text>
        </svg>
      </div>
      <div className="mt-2 text-xs text-neutral-500 dark:text-neutral-400">Ordering finality fixes position but has no receipt yet. After execution, applications may use the receipt according to their risk policy; high-value and cross-chain flows should wait for the attested digest.</div>
    </div>;
};

Sei Giga is designed so that standard EVM contracts do not need to change. Contracts that depend on retired Sei-native surfaces, including the native Oracle precompile, must migrate separately. 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. Ordering and state attestation will be separate protocol signals, execution receipts will arrive between them, there will be no traditional public mempool, a priority fee will buy a position in the order rather than a proposer's favor, and state proofs will work differently. Transaction ingress will initially route complete transactions to validator lanes; the later [Sedna](/learn/sei-giga-specs#sedna-private-dissemination) milestone will introduce coded symbol bundles. 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 August 2026 there is no public Giga testnet yet. Sections describing components that have not activated are forward-looking and subject to change. Statements about Ares v6.6, retired native Oracle queries, and IBC reflect the live network as of August 2026. 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 against standard EVM semantics. Opcodes and standard Ethereum precompiles will track Ethereum near parity; retired Sei-native precompiles are outside this compatibility statement.
* 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             | Block inclusion / finalized tag                  | Ordering finality (measured \<250 ms), execution receipt, then state attestation finality                                                                                                           | Wait for the stage your flow requires; see [below](#finality-on-giga-which-signal-to-wait-for)           |
| Mempool              | Public pending pool, gossip, frontrunning games  | No traditional public mempool; complete transactions route to lanes before Sedna, with coded symbol bundles added by the later [Sedna](/learn/sei-giga-specs#sedna-private-dissemination) milestone | 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; the protocol does not pay a specific proposer for preferential treatment |
| 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. Applications will observe three stages:

* Ordering finality (measured under 250 ms on the internal devnet): consensus has fixed your transaction's position under the protocol's stated assumptions. Execution follows, so this stage does not provide a receipt or execution result.
* Execution receipt: a node has executed the ordered transaction and can report its result. This is the first stage at which your application can know whether the transaction succeeded or reverted, but it is not a quorum attestation.
* State attestation finality, a bounded number of blocks later: a two-thirds voting-power quorum has signed the block's [divergence digest](/learn/sei-giga-specs#lattice-hash-divergence-digests). This confirms the executed results.

<GigaFinalitySignals />

Which signal to wait for depends on the flow:

| Use case                                                     | Wait for                                                          | Why                                                                           |
| ------------------------------------------------------------ | ----------------------------------------------------------------- | ----------------------------------------------------------------------------- |
| Interactive UX, games, and payments UI                       | Execution receipt or state attestation, based on your risk policy | The receipt exposes the result; attestation adds a signed quorum confirmation |
| 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 revert is an execution result and does not invalidate the rest of the block. For today's finality behavior, before Giga, see [EVM finality on Sei](/evm/evm-parity/finality).

<Warning>Ordering finality alone does not reveal the execution result. Treat receipt-level action as an application risk decision, not as a substitute for state attestation in high-value or cross-chain flows.</Warning>

## Sending transactions without a public mempool

On Autobahn before the later Sedna milestone, RPC nodes will route complete signed transactions into validator proposal lanes without a shared public pending pool. After Sedna activates, RPC ingress will instead distribute coded symbol bundles and executors will reconstruct the transaction after the finalized symbols cross the decode threshold. Autobahn's pipelining is designed for an effective steady-state cadence of one committed cut per 1.5 network round trips; this is not a submission-to-finality guarantee. 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, which is designed to reduce post-consensus proposer discretion. Sedna is intended to add pre-execution privacy; its guarantees depend on coding parameters and the number of colluding lanes.
* 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 is designed to include at most one copy of a given transaction per epoch, so attempts to amplify a transaction within one validator's lane will struggle to succeed. Cross-validator duplicates remain possible for censorship resistance and will pay the distribution fee.

## 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 intended to reduce protocol-level incentives to tip a specific proposer. Out-of-protocol side payments remain outside the current specification.
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 could have been parallelized](https://blog.sei.io/research-64-85-of-ethereum-transactions-can-be-parallelized/) under this model. 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={null}
// 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={null}
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={null}
struct Position {
    uint128 size;      // 128 bits ┐
    uint64  entryTime; // 64 bits  ├─ one storage slot
    uint64  nonce;     // 64 bits  ┘
}
```

## Sei precompiles under the Giga executor

[Sei v6.6](https://github.com/sei-protocol/sei-chain/releases/tag/v6.6.0) activated the first Ares execution phase on Pacific-1. Eligible transactions use the Ares path; when that path encounters an unsupported case, the individual transaction reruns through the v2 fallback. Eligibility is release-specific, so do not assume every EVM transaction or precompile call uses the same fast path. Follow the [node configuration reference](/node/node-operators#giga-storage-and-giga-executor) for the release you operate.

The retired native Oracle precompile at `0x0000000000000000000000000000000000001008` is not a supported fallback. Its data-query methods revert. Use one of the third-party providers documented for Sei instead.

## 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. IBC is disabled in both directions: Proposals [116](https://seistream.app/proposals/116) and [120](https://seistream.app/proposals/120) disabled inbound transfers, and [121](https://seistream.app/proposals/121) disabled outbound transfers on July 31, 2026. Existing IBC balances can still move within Sei but can no longer be redeemed over IBC on their origin chain. For external data, use the providers documented for Sei: [API3](/evm/oracles/api3), [Chainlink](/evm/oracles/chainlink), [Pyth](/evm/oracles/pyth-network), and [RedStone](/evm/oracles/redstone).
* Audit for hot slots. Per-user state isolation is the single most effective change for parallel throughput. The first Ares phase went live with the mandatory Pacific-1 v6.6 upgrade on August 4, 2026; broader Ares work continues in later releases.
* Classify your confirmation flows. Decide which flows only need the fixed order, which act on an execution receipt, and which wait for state attestation, so the three-stage 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. Standard EVM contracts that do not depend on retired Sei-native surfaces are designed to carry over without redeployment.

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

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

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