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	Resource Metering
Base Sepolia	Flashblocks + Per-Transaction Gas Max	Resource Metering

See the Configuration Changelog for a history of changes to block building and other network parameters.

Configurations

Flashblocks

Currently, blocks are built using op-rbuilder and priority fee auctions occur every 200ms. There are two changes from the vanilla ordering to be aware of:

Timing

Flashblocks are built every 200ms, each ordering a portion of the block. Unlike the current system where later-arriving transactions with higher priority fees can be placed at the top of the block, Flashblocks creates a time-based constraint. Once a Flashblock is built and broadcast, its transaction ordering is locked even if a transaction with a higher priority fee arrives later, it cannot be included in earlier, already built Flashblocks.

High Gas Limits

If your app creates transactions with large gas limits, we recommend monitoring to detect any changes in inclusion latency. Transactions with gas limits over 1/10 of the current block gas limit (currently 14 million gas), face additional constraints:

• Each Flashblock can only use a portion of the block’s total gas limit
• Flashblock 1: up to 1/10 of the total gas
• Flashblock 2: up to 2/10 of the total gas

And so on for subsequent Flashblocks

Consequently, transactions with large gas requirements must wait for later Flashblocks with sufficient gas capacity. For example, a transaction exceeding 1/10 of the block’s gas limit cannot be included in Flashblock 1 and must wait for Flashblock 2 or later.

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.

Resource metering

In addition to gas limits, Base measures the execution time and data availability (DA) cost of each transaction. The block builder uses these measurements to enforce per-transaction and per-flashblock resource limits, ensuring no single transaction can cause builder timeouts or uneven resource distribution across flashblocks.

When resources are constrained, transactions are included in priority fee order — higher-paying transactions are included first. You can query the recommended priority fee for your transaction using the base_meteredPriorityFeePerGas RPC method. See Resource Metering for details.

Vanilla

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