Payment finality is a ladder, not a timestamp.
“Confirmed” sounds binary. On a rollup, it is a sequence of increasingly strong guarantees—and the right waiting point depends on what a seller delivers next.
Four useful stages on Base
Base currently documents four stages for ordinary L2 transactions: Flashblock inclusion at roughly 200 milliseconds, L2 block inclusion at roughly 2 seconds, L1 batch inclusion at roughly 2 minutes and L1 batch finality at roughly 20 minutes. These are estimates and network behaviour can change, which is why this article carries a review date.
The seven-day period people often associate with optimistic rollups applies to withdrawals from Base to Ethereum, not to regular sends within Base.
Match the guarantee to the thing being sold
A low-cost, reversible API response and a high-value, irreversible shipment do not need the same confirmation policy. The first may prioritise latency; the second may prioritise the strongest available assurance before fulfilment.
- Preconfirmation: fastest feedback, with a small documented reorganisation risk.
- L2 block inclusion: stronger operational confidence after the sequencer has produced and distributed the block.
- L1 batch inclusion: transaction data is posted to Ethereum, adding a stronger external anchor.
- L1 batch finality: the batch has Ethereum finality and is, in practice, extremely difficult to reverse.
Use honest status words
A payment system should avoid using one “paid” label for several different states. “Authorization verified,” “submitted,” “included” and “finalized” communicate different levels of certainty. Receipts and webhooks should include the transaction identifier and the status that triggered the event so downstream systems can apply their own policy.
Operational rule: Do not copy a confirmation threshold from another product. Document the loss you are willing to tolerate, the reversibility of fulfilment and the latency your customer can accept—then choose the stage.
Revisit the policy as the network changes
Confirmation timings and infrastructure evolve. Keep the threshold configurable, monitor delayed or reorganized transactions and review the primary network documentation instead of freezing today’s estimates into permanent business logic.
Primary sources
Check the original sources.
- 01Transaction finalityBase Documentation
- 02Troubleshooting transactions and confirmation stagesBase Documentation
Last source review: Jul 22, 2026. This is technical education, not financial or legal advice.
