Block Building

Base block ordering is independent of the user-facing experience: the sequencer can build sub-block updates without exposing them, and the underlying ordering rules continue to apply.

Current configuration

Network	Active configuration	Upcoming
Base Mainnet	Flashblocks and per-transaction gas maximum
Base Sepolia	Flashblocks and per-transaction gas maximum

The configuration changelog records every change to block building parameters and other network-level settings.

Flashblocks

Blocks are produced by base-builder, with a fresh priority fee auction running every 200ms. The auction shortens effective block times from 2 seconds to 200 milliseconds via preconfirmations.

Note

For a deeper architectural walkthrough, see the Flashblocks overview.

Three properties distinguish Flashblocks from vanilla ordering:

1. Timing — The builder emits one Flashblock every 200ms, sealing a slice of the eventual block. Once a Flashblock is broadcast, its ordering is final; later transactions with higher priority fees cannot displace transactions already committed to an earlier Flashblock.

2. Gas allocation — Each Flashblock has a progressively larger gas budget. Flashblock 1 may consume up to one tenth of the block gas limit, Flashblock 2 up to two tenths, and so on through Flashblock 10, which may use the full limit.

   Flashblock	Available gas
   1	~14M gas (1/10)
   2	~28M gas (2/10)
   3	~42M gas (3/10)
   …	…
   10	~140M gas (full)

   Caution

   A transaction that needs more than ~14M gas cannot land in Flashblock 1 and will wait for a later Flashblock. Track inclusion latency if your application submits large transactions.

3. Dynamic mempool — The builder keeps accepting new transactions while a Flashblock is being assembled. This minimizes inclusion latency, but transactions are ordered by fee at the moment of selection, not against every transaction that arrived during the 200ms window. A high-fee transaction that arrives late may appear after a lower-fee transaction that was already committed.

   Note

   This is an intentional trade-off — faster inclusion at the cost of occasionally violating strict priority gas auction (PGA) ordering inside a Flashblock. The Flashblocks FAQ covers the implications in more detail.

Per-transaction gas maximum

Since the Azul hardfork, Base applies a protocol-level ceiling of 16,777,216 gas (2^24) to any single transaction, as specified by EIP-7825. A transaction that declares a gas limit above this figure is rejected during block validation, and eth_sendTransaction or eth_sendRawTransaction returns a JSON-RPC error — for instance, exceeds maximum per-transaction gas limit.

Note

The cap does not apply to deposit transactions. Those are instead bounded by the largest amount of gas that fits in an L1 block, which is 20,000,000 gas.

Operators running bundlers for smart contract wallets need to size each bundle so that it stays within this limit.

Vanilla ordering

Under the legacy configuration, op-geth builds a block every 2 seconds and orders transactions inside the block by priority fee. See the reference implementation.