Skip to main content

​
Overview

This section describes how blocks are ordered on the Base networks. The ordering is separate from the UX, for example the sequencer could be building Flashblocks every 200ms, without these Flashblocks being exposed publicly. In this scenario, block ordering would change but the user experience would remain consistent. The Base networks are currently configured in the following ways:
NetworkCurrent ConfigurationUpcoming Deployments
Base MainnetFlashblocks + Per-Transaction Gas Max
Base SepoliaFlashblocks + Per-Transaction Gas Max
See the Configuration Changelog for a history of changes to block building and other network parameters.

​
Configurations

​
Flashblocks

Blocks are built using op-rbuilder with priority fee auctions occurring every 200ms. This reduces effective block times from 2 seconds to 200 milliseconds through preconfirmations.
For a comprehensive technical deep dive into Flashblocks architecture, see the Flashblocks Overview.
There are two key differences from vanilla ordering:
  1. Timing — Flashblocks are built every 200ms, each ordering a portion of the block. Once built and broadcast, transaction ordering is locked. Later-arriving transactions with higher priority fees cannot be included in earlier Flashblocks.
  2. Gas Allocation — Each Flashblock has an incrementally increasing gas budget. Flashblock 1 can use 1/10 of the block gas limit, Flashblock 2 can use 2/10, and so on until Flashblock 10 has access to the full limit.
    FlashblockAvailable Gas
    1~14M gas (1/10)
    2~28M gas (2/10)
    3~42M gas (3/10)
    ……
    10~140M gas (full)
    Transactions exceeding 14M gas cannot fit in Flashblock 1 and must wait for later Flashblocks. Monitor inclusion latency if your app creates large transactions.

​
Per-Transaction Gas Maximum

Base enforces a per-transaction gas maximum of 25,000,000 gas. Transactions that specify a gas limit above this value are rejected by the mempool before inclusion. eth_sendTransaction or eth_sendRawTransaction will return a JSON-RPC error (for example: exceeds maximum per-transaction gas limit). This cap does not change the block gas limit or the block validity conditions. Fusaka’s EIP 7825 will change the block validity conditions and enforce a lower per-transaction gas maximum of 16,777,216 gas (2^24). We expect this protocol change to be adopted in all OP Stack chains around January 2026. Bundler operators for smart contract wallets must configure their systems to limit the bundle size to fit within this cap.

​
Vanilla

Blocks are built every 2s by op-geth. Transactions within those blocks are ordered by priority fee, see the (code).