Transaction Lifecycle

Follow a Base transaction from submission through sequencing, preconfirmation, L2 inclusion, L1 batching, and finality.

Most transactions on Base follow the same high-level path: a wallet signs a transaction, an RPC endpoint accepts it, the sequencer orders it, Base exposes the result through preconfirmed and sealed block data, and the batcher posts the transaction data to Ethereum.

For normal L2 activity, such as transfers, swaps, mints, contract calls, and app interactions, this process completes quickly. The 7 day waiting period only applies to withdrawals from Base back to Ethereum.

Only Base-to-Ethereum withdrawals use the 7 day fault proof window. Regular transactions on Base do not wait 7 days before apps can treat them as complete.

Lifecycle at a glance

Stage	Typical timing	What happens	What apps can do
Submit and price	Immediate	The wallet signs a transaction and sends it to an RPC endpoint. The transaction must pay the required L2 execution fee and L1 data fee.	Surface wallet or RPC errors, show the transaction as submitted, and keep tracking by hash.
Sequence	Sub-second	The sequencer admits valid transactions, orders them, and begins building the next L2 block.	Treat the transaction as pending until it appears in preconfirmed or sealed block data.
Flashblock preconfirmation	About 200 ms	Flashblocks-aware infrastructure can expose preconfirmed transaction and state updates before the full L2 block is sealed.	Use Flashblocks endpoints for faster UI updates when your product can tolerate preconfirmation semantics.
L2 block inclusion	About 2 seconds	The transaction is included in a sealed L2 block distributed to Base nodes.	Show the transaction as included on Base and read its receipt through standard JSON-RPC.
L1 batch inclusion	About 2 minutes	The batcher posts Base transaction data to Ethereum.	Treat the transaction as having stronger settlement guarantees because the data has been posted to L1.
L1 finality	About 20 minutes	The Ethereum block containing the batch reaches Ethereum finality.	Treat the transaction as finalized for normal L2 app and accounting workflows.
Withdrawal finality	7 days	For Base-to-Ethereum withdrawals only, the withdrawal must pass the fault proof challenge window before funds can be released on L1.	Keep withdrawal-specific UX separate from normal L2 transaction confirmation.

Submission and fees

A Base transaction starts the same way as an Ethereum transaction: a wallet signs calldata, gas parameters, nonce, chain ID, and value. The transaction is then sent to a Base RPC endpoint with eth_sendRawTransaction.

Before a transaction can be included, it must be valid for the current account state and fee market. Common reasons for rejection or delay include an underpriced fee, an incorrect nonce, insufficient funds for gas, reverted execution, or endpoint rate limits. Base fees include L2 execution costs and the L1 data cost of eventually posting transaction data to Ethereum.

Sequencing and preconfirmation

The Base sequencer orders admitted transactions and builds L2 blocks. With Flashblocks, the sequencer also emits preconfirmation data before the full L2 block is sealed. This gives apps a faster signal that a transaction is likely to land.

Preconfirmed state is useful for low-latency UX, but it is not the same as L2 block inclusion. Apps should label or handle preconfirmed state separately when the distinction matters. For example, an app can optimistically update an order, mint, or transfer view from Flashblocks data, then reconcile the final receipt after L2 block inclusion.

L2 inclusion and receipts

Once a transaction is included in a sealed L2 block, standard JSON-RPC methods such as eth_getTransactionReceipt, eth_getTransactionByHash, and eth_getBlockByNumber can return the canonical L2 result. This is the main confirmation point most apps use for normal Base activity.

At this point, the receipt tells you whether execution succeeded, which logs were emitted, how much gas was used, and which block included the transaction. If a transaction is missing, still pending, or replaced by another transaction with the same nonce, handle that as a transaction tracking problem rather than a finality problem.

L1 batching and finality

After L2 inclusion, Base batches transaction data and posts it to Ethereum. L1 batch inclusion gives the transaction stronger guarantees because the data needed to derive the L2 chain has been published to Ethereum.

When the Ethereum block containing the batch reaches finality, the transaction has reached the strongest finality stage relevant to normal L2 app workflows. This is separate from withdrawal finality, which protects cross-chain withdrawals through the fault proof system.

Withdrawals are different

Deposits from Ethereum to Base and normal transactions on Base do not use the 7 day withdrawal period. The 7 day window applies when a user withdraws from Base to Ethereum through the native bridge.

During a withdrawal, the user initiates the withdrawal on Base, a proposer submits an output root to Ethereum, and the withdrawal can be finalized after the fault proof challenge window if the output root remains valid. If a challenge invalidates an output root, the L2 chain itself does not reorg, but withdrawals proven against that invalid output need to be proven again against a valid output.

Related docs

Network Fees

Understand L2 execution fees, L1 data fees, and minimum base fee settings.

Block Building

Learn how Base sequences transactions, builds Flashblocks, and enforces gas limits.

RPC Overview

Compare Standard and Flashblocks endpoint behavior by method.

Transaction Finality

Compare preconfirmation, L2 inclusion, L1 batching, L1 finality, and withdrawal finality.