Transaction Finality

Finality is the point at which a Base transaction becomes irreversible. The behavior differs for transactions that update L2 state versus transactions that withdraw funds from Base L2 to Ethereum L1.

Note

Only withdrawals from Base to Ethereum have to sit out a finalization window — 5 days when one proof backs the claim, 1 day when both a TEE proof and a ZK proof do. Regular L2 transactions — swaps, transfers, contract calls — never wait on it.

Finality for Base L2 transactions

This section covers every Base transaction except withdrawals back to Ethereum.

Finality is layered: each successive stage strengthens the security guarantee.

Flashblock inclusion: ~200ms

After about 200 milliseconds, the Base sequencer includes the transaction in a preconfirmation block (a Flashblock).

Reorg probability is below 0.001%. Flashblocks reorg less than 0.001% of the time; the public stats page records the reorg history.

L2 block inclusion: ~2s

After roughly 2 seconds, the sequencer has packaged the transaction into a sealed L2 block and propagated it to validator nodes.

Reorg probability is effectively 0%. Only one Base L2 block has ever reorged, accounting for 0.0000003% of transactions. The data is visible on Blockscout.

L1 batch inclusion: ~2m

After about 2 minutes, a Base batch containing the transaction has been posted to Ethereum.

Reorg probability is effectively 0%. No L2 blocks that have been batched to Ethereum L1 have ever reorged. An Ethereum L1 reorg does not force a Base L2 reorg. The sequencer and validator nodes maintain a configurable lag from the L1 tip, so typical L1 reorgs have no impact. If a deeper L1 reorg occurs, Base can resubmit batch data without altering the sequenced L2 blocks.

L1 batch finality: ~20m

The Ethereum batch carrying the transaction is older than 2 epochs (64 L1 blocks).

Reorg probability is effectively 0%. L2 blocks past L1 batch finality enjoy the same protection as Ethereum-finalized blocks and are practically impossible to reverse.

Finality for withdrawals

A withdrawal from Base to Ethereum is released to the L1 recipient only after its finalization window closes. That window is what lets Base’s proof system give bridged funds strong security guarantees.

Since Beryl activated, the window is 5 days for a dispute game backed by a single proof. When a TEE proof and a ZK proof both support the same proposal, the dual-proof fast path cuts it to 1 day. The window dominates the end-to-end time: the wait for the relevant Base state to be proposed on Ethereum typically adds only 20 to 60 minutes, plus however long the prove and finalize transactions take. Third-party bridges that pay out sooner do it with their own liquidity; they leave this window untouched.

What happens during the finalization window

The funds leave the Base account as soon as the withdrawal is initiated. A proposer then posts a checkpoint claim on Ethereum through an AggregateVerifier game, backed by a TEE or ZK proof. An independent challenger can contest an invalid claim by supplying a ZK proof. The window exists so that others have time to check the claim, and it is shorter when TEE and ZK proofs agree. The Azul proof system page walks through the full flow.

If a claim turns out to be invalid, withdrawals proven against it cannot finalize and have to be proven again against a valid claim. Contesting a claim never reorgs the Base chain.

FAQ

If Ethereum reorgs, will Base reorg?

Almost never. Base resubmits batch data to Ethereum transparently while the L2 chain continues forward.

How long do deposit transactions take to finalize?

Deposits are initiated on Ethereum and are typically picked up by the Base sequencer within 3 minutes.

If a challenger wins a dispute game, will the L2 chain reorg?

No. The challenged output proposal is marked invalid, and any actions that depended on its output root must use a valid replacement. In practice, withdrawals proven against the invalid proposal must be re-proven against a different one.