Block Building

This page outlines how Base blocks are built.

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:

Network	Current Configuration	Upcoming Deployments
Base Mainnet	Flashblocks + Per-Transaction Gas Max
Base Sepolia	Flashblocks + 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 three 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.

   Flashblock	Available 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.

3. Dynamic Mempool — The builder continuously accepts new transactions while building each Flashblock. This minimizes inclusion latency but means transactions are ordered by fee at the time of selection, not globally across all transactions that arrive during the 200ms window. A late-arriving high-fee transaction may appear after an already-committed lower-fee transaction.

   This is a deliberate tradeoff: faster inclusion at the cost of occasionally “breaking” expected priority gas auction (PGA) ordering within a Flashblock. See the Flashblocks FAQ for more details.

Per-Transaction Gas Maximum

As of the Azul hardfork, Base enforces a protocol-level per-transaction gas maximum of 16,777,216 gas (2^24) via EIP-7825. Transactions that specify a gas limit above this value are rejected during block validation. eth_sendTransaction or eth_sendRawTransaction will return a JSON-RPC error (for example: exceeds maximum per-transaction gas limit).

Deposit transactions are exempt from this cap. They are limited by the maximum gas includable in an L1 block (20,000,000 gas).

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 base-reth-node. Transactions within those blocks are ordered by priority fee.