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

# 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-diagram-gold, var(--sei-gold-100))';
  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-600 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-600 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-diagram-gold, var(--sei-gold-100))';
  return <div className="not-prose w-full my-5">
      <div className="overflow-x-auto rounded-xl border border-neutral-200 dark:border-neutral-800 bg-white/60 dark:bg-neutral-900/40 p-4 text-neutral-800 dark:text-neutral-200">
        <svg viewBox="0 0 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-600 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, with five exceptions. The exceptions are EIP-4844 blobs, `PREVRANDAO`, the state root, the block gas limit, and the transaction fee mechanism. Standard Solidity and Vyper tooling will keep working: Foundry, Hardhat, viem, and ethers.

The environment around your contracts will change:

* 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, not a proposer's favor.
* 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 make the best use 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 about 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. To build 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: the standard JSON-RPC methods will remain (`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. The later [Sedna](/learn/sei-giga-specs#sedna-private-dissemination) milestone adds coded symbol bundles | Drop pending-pool assumptions. There will be no pending stream to watch |
| Priority fee | Paid to the block proposer, and 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 | Avoid a hard dependency 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. Lane and consensus parameters will bound throughput | Do not encode assumptions about a specific block gas limit |
| Duplicate submission | Rebroadcasting the same transaction 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 and get 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 you do not get a receipt or execution result at this stage.
* 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. 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>Treat receipt-level action as an application risk decision, not as a substitute for state attestation in high-value or cross-chain flows. Ordering finality alone does not reveal the execution result.</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 distribute coded symbol bundles instead. 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. The merged execution order will be a [deterministic function](/learn/sei-giga-specs#deterministic-merge-rule) of finalized lane contents. This 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. Do not build features that depend on watching a gossiped pending-transaction stream. The validator responsible for your sender address will answer pending-nonce queries. The RPC layer will route these queries for you.
* You will control your own censorship resistance. If censorship resistance matters for a transaction, submit the identical signed transaction to multiple validators. Only one copy will execute, because duplicates will be dropped by hash at merge time. 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. Attempts to amplify a transaction within one validator's lane will therefore 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 the gas a transaction consumes. `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. A higher tip will therefore buy earlier execution, deterministically. The fee will also be socialised: pooled per epoch and distributed to validators by stake and liveness. This design is 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. Expect parameter-level details to become more definite 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 and 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 that touch disjoint storage will run simultaneously. Transactions that contend on one hot slot will serialize. The engine will retry conflicted transactions. Under sustained contention, it will fall back to sequential execution. This fallback is 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. This 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 especially cost-effective on Giga. Receipt generation and log indexing will run off the execution hot path, in dedicated stores. Keeping history in events will therefore trim your write set, and the history will stay queryable.

### Pattern 4: pack storage you must share

When state must be shared, make it cheap. Pack related fields into one slot, so a conflicting transaction pays for 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 Sei Mainnet. 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 that 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 an 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 Sei Mainnet 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. The three-stage model will then need only a configuration change, not 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.
* Do not wait for a "Giga chain." There will not be one. Giga will arrive on the network where you are 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 Sei Mainnet v6.6 activation.*


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