Building on Sei Giga: What Changes for Developers

​

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

​

Finality on Giga: which signal to wait for

• 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. This confirms the executed results.

​

Sending transactions without a public mempool

• There will be no public mempool to scan for victims, and the merged execution order will be a deterministic function 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

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.

​

Writing parallel-friendly contracts

​

Pattern 1: isolate state per user

// 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
    }
}

​

Pattern 2: prefer mappings over shared arrays

​

Pattern 3: emit events instead of storing history

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

​

Pattern 4: pack storage you must share

struct Position {
    uint128 size;      // 128 bits ┐
    uint64  entryTime; // 64 bits  ├─ one storage slot
    uint64  nonce;     // 64 bits  ┘
}

​

Sei precompiles under the Giga executor

​

Prepare your app for Giga today

• Build EVM-only. SIP-3 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 and 120 disabled inbound transfers, and 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, Chainlink, Pyth, and 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), 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: architecture and roadmap
• Sei Giga technical specification: the full protocol spec and glossary
• EVM development guides: building on Sei today
• Differences with Ethereum: current-network EVM deltas
• SIP-3 migration guide: the EVM-only consolidation