Skip to main content
Finality refers to the point at which a transaction sent to Base becomes irreversible. This provides guarantees that the transaction will not be rolled back or lost. Finality works differently for normal transactions that modify Base L2 state than it does for transactions that withdraw funds from Base L2 to Ethereum L1.
Only transactions that withdraw funds from Base to Ethereum must wait for a withdrawal finalization window (5 days, or 1 day when both TEE and ZK proofs are present). Regular transactions within Base, such as swaps or sends, do not have this wait.

​
Finality for Base L2 Transactions

This describes finality for transactions on Base except withdrawal transactions that move funds from Base to Ethereum L1 For transactions on Base, finality is not a single time to wait for. Instead, there are 4 stages in time that each provide increasing security guarantees.
Diagram of transaction finality stages on Base
1

Flashblock Inclusion: ~200ms

After roughly 200ms, the transaction is included in a preconfirmation block (Flashblock) by the Base sequencer.
  • Flashblocks reorg less than 0.001% of the time
  • You can see the reorg history in our public stats page.
2

L2 Block Inclusion: ~2s

After roughly 2 seconds, the sequencer has built the transaction into an L2 block and distributed it to validator nodes.
  • Only a single Base L2 block has ever reorged, representing .0000003% of transactions. The data can be seen here
3

L1 Batch Inclusion: ~2m

After roughly 2 minutes, a Base batch containing the transaction has been posted to Ethereum.
  • There has never been a reorg of L2 blocks that were batched to Ethereum L1.
  • A reorg of Ethereum L1 does not require a reorg of the Base L2 chain. The sequencer and validator nodes maintain a configurable lag from the tip of Ethereum, so typical L1 reorgs have no effect. In the event of larger Ethereum reorgs, Base can resubmit batch data on L1 without changing the sequenced L2 blocks.
4

L1 Batch Finality: ~20m

The Ethereum L1 batch containing the transaction is older than 2 epochs, or 64 L1 blocks.
  • L2 blocks that have reached L1 batch finality are protected from reorgs the same way Ethereum finalized blocks are. They are in practice impossible to reverse.

​
Finality for Withdrawal Transactions

This describes finality of transactions that move funds from Base to Ethereum Only withdrawals to Ethereum must wait for a finalization window before the funds can be released to the address on Ethereum L1. This allows Base’s proof system to provide extremely high security guarantees for funds bridged to Base. Since the Beryl upgrade, the finalization window is 5 days for a single-proof dispute game and 1 day on the dual-proof fast path, when both a TEE proof and a ZK proof back the same proposal. The window accounts for most of the end-to-end time; waiting for the relevant Base state to be proposed on Ethereum usually adds only about 20 to 60 minutes, plus the prove and finalize transactions. Third-party bridges that release funds faster use their own liquidity and do not change this window.
After a withdrawal is initiated on Base, a proposer submits a checkpoint claim on Ethereum through an AggregateVerifier game with a TEE or ZK proof. An independent challenger can dispute an invalid claim with a ZK proof. The game’s finalization window gives other participants time to verify the claim; when TEE and ZK proofs support the same proposal, the dual-proof path is shorter. See the Azul proof system for the proof flow.A withdrawal proven against an invalid claim cannot finalize and must be re-proven against a valid one. Challenging a claim does not reorg the Base chain.

​
FAQ

In almost all circumstances, no. Base can simply re-submit batch data to Ethereum transparently while the L2 chain continues to progress.
Transactions moving funds from Ethereum L1 to Base must be initiated on Ethereum and typically get included within 3 minutes by the Base sequencer.
No. The output proposal that was challenged is marked invalid, and any actions that used it’s output root become invalid. Specifically, withdrawals from Base to L1 that proved against this output root must now prove against a different and valid one.