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 how preconfirmed state is exposed to applications, see the Base RPC Overview. For node operation, see Run a Base Node.

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 j can use up to j/10 of the full block gas limit, minus gas already consumed by earlier Flashblocks in the same block.

   Current parameters, last verified 2026-05-08

   Network	Full block gas limit	Flashblock 1 cumulative budget
   Base Mainnet	400M gas	40M gas
   Base Sepolia	1.2B gas	120M gas

   Base Sepolia’s block gas limit is scheduled to increase every 2 weeks. See the Configuration Changelog for network parameter history.

   For example, on Base Mainnet, Flashblock 1 can use up to 40M gas, Flashblock 2 can use up to 80M gas minus gas already consumed by Flashblock 1, and Flashblock 10 can use up to the full 400M gas limit minus gas already consumed.

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. If strict fee-based ordering is critical for your workflow, account for arrival timing as well as priority fee within each 200ms Flashblock window.

Per-Transaction Gas Maximum

Base enforces a per-transaction gas maximum. Transactions that specify a gas limit above the active maximum 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.

Network	Active per-transaction gas maximum
Base Mainnet	25,000,000 gas until Azul activates on May 21, 2026 at 18:00 UTC; 16,777,216 gas after activation
Base Sepolia	16,777,216 gas, active since April 20, 2026 at 18:00 UTC

For the Azul protocol change that enforces the 16,777,216 gas cap, see the Azul execution engine specification.

Bundler operators for smart contract wallets must configure their systems to limit the bundle size to fit within this cap.

Vanilla

After Azul activation, blocks are built by base-reth-node. Before Mainnet activates Azul on May 21, 2026 at 18:00 UTC, Mainnet block production still uses op-geth.