Sequencing Policy

How Base orders, includes, and preconfirms transactions.

Base transactions are ordered by the Base sequencer before they become sealed L2 blocks. This page explains the practical sequencing model app developers, traders, market makers, and infrastructure operators should account for when they submit or monitor transactions.

What the sequencer does

The sequencer receives signed transactions, validates them against current account state and network rules, chooses which valid transactions to include, and produces ordered L2 blocks. Validators can independently derive and verify the resulting L2 chain from data posted to Ethereum.

Sequencing is separate from finality. A transaction can be:

• Received by an RPC endpoint or mempool.
• Preconfirmed in a Flashblock before the full L2 block seals.
• Included in a sealed L2 block.
• Batched to Ethereum.
• Finalized once the Ethereum batch reaches L1 finality.

For the timing and guarantees of those stages, see Transaction Lifecycle and Transaction Finality.

How transactions are selected

Base uses Flashblocks for block production. The block-in-progress is divided into roughly 200ms Flashblocks. Each Flashblock orders a portion of the next full L2 block.

Transaction selection is affected by:

• Validity: invalid nonce, insufficient balance, gas-limit violations, or reverted execution can prevent inclusion.
• Priority fee at selection time: higher-priority transactions are more likely to be selected earlier, but ordering is evaluated continuously as Flashblocks are built.
• Arrival timing: a transaction that arrives after an earlier Flashblock has already been built cannot be inserted into that earlier Flashblock, even if it pays a higher fee.
• Gas budget: each Flashblock has an incrementally increasing gas budget within the full L2 block gas limit.
• Per-transaction gas maximum: transactions above the active per-transaction gas cap are rejected before inclusion.

Flashblocks improve inclusion latency, but they do not create a single global auction over every transaction that arrives during the full 2 second block window. For latency-sensitive workflows, arrival timing and propagation path matter alongside fee settings.

What preconfirmation means

When a transaction appears in Flashblocks data, it has been sequencer-ordered into the current block-in-progress. This is a strong preconfirmation signal, not the same thing as L2 block inclusion.

Applications can use Flashblocks-aware RPC endpoints and subscriptions to display faster state updates, pending logs, transaction status, or preconfirmed receipts. They should still reconcile against sealed L2 block data before treating the transaction as fully included.

Practical guidance

For apps and wallets:

• Submit transactions with realistic fee settings and handle RPC rejection errors clearly.
• Track transactions by hash until a sealed receipt is available.
• If using preconfirmed state, label optimistic UI states and reconcile after L2 inclusion.

For market makers and latency-sensitive systems:

• Account for transaction propagation and arrival time, not only priority fee.
• Monitor both preconfirmation signals and sealed block receipts.
• Avoid assuming that a later high-fee transaction can reorder already-built Flashblocks.

For infrastructure providers:

• Expose Standard and Flashblocks endpoint behavior clearly to users.
• Document whether by-hash lookups can return preconfirmed cache data.
• Keep raw Flashblocks stream dependencies separate from application-facing RPC behavior.

Related references

• Block Building documents Flashblocks timing, gas allocation, and active gas limits.
• Base RPC Overview explains how sequencing and preconfirmed state are exposed over RPC.
• eth_sendRawTransaction documents transaction submission behavior.
• eth_getTransactionReceipt documents sealed and preconfirmed receipt lookups.
• Protocol Overview describes sequencer and validator roles at the specification layer.