Verification checklist
- Copy the wallet status and timestamp; label it soft confirmation, not L1 inclusion.
- Find the L1 batch or blob that contains the transaction; write block number and hash.
- Check whether that L1 block is beacon-finalized; if not, do not write settled.
- The optimistic challenge window constrains withdrawals only; do not fold it into inbound settlement.
1. A green tick is a sequencer receipt, not a settlement proof
A centralized sequencer queues the transaction first, then later posts a batch or blob to L1. Optimism’s transaction-finality note splits unsafe / safe / finalized. The wallet’s Confirmed usually maps to unsafe or a preconfirmation: the sequencer said it took the tx; L1 has not seen it. Writing the tick as settled treats one operator’s memory as Ethereum consensus.
This is not the site’s dashboard-clock note. That note asks whether a screenshot clock is a chain clock. This note asks: even when the L2 explorer already shows a hash, which clock does that hash sit on. The units differ. Soft confirmation is a sequencer log. L1 inclusion is a batch transaction or an EIP-4844 blob. Finality is a beacon checkpoint.
2. A worked example: two-second tick, thirty-one minutes to finalize
A researcher sends an L2 transfer at T0. At T0+2s the wallet shows Confirmed. At T0+18 min an L1 block contains the batch, still unfinalized. At T0+31 min the beacon marks that L1 block finalized. A write-up that screenshots T0+2s and says “bridged in, counted in today’s book” has two clocks still missing. The table is hypothetical.
| Clock | What is read | Teaching wait | May write settled? |
|---|---|---|---|
| Soft confirm | wallet or sequencer receipt | ~2 seconds | No; can be rewritten |
| L1 inclusion | batch or blob block | ~18 minutes | No; L1 can still reorg |
| L1 finality | beacon finalized checkpoint | ~31 minutes | Inbound credit may pass |
| Optimistic window | fault-proof window | days | Withdrawals only, not inbound credit |
The gap between two seconds and thirty-one minutes is not UI lag. Most of the safety still sits in L1 consensus, not in the sequencer mempool. Treating wallet speed as settlement speed writes an operator SLA as a protocol guarantee. Ethereum’s optimistic-rollup note likewise splits fast sequencer blocks from mainnet publication: the first is UX; the second is verifiability.
3. Read three paths so a preconfirmation is not mistaken for finality
Layer one is the wallet or RPC status string. Copy Confirmed, Success or Safe verbatim, with client and timestamp. Layer two is L1: invert the tx hash to the batch-posting transaction or blob versioned hash, and check that the L2 tx is actually inside that batch. An L2-explorer hash with no L1 inclusion stops at soft confirm. Layer three is the beacon: using the PoS finality note, check whether that L1 block sits in a finalized checkpoint, and write the epoch or block number rather than “about fifteen minutes”.
The failure modes differ. Soft-confirm failure is sequencer censorship, downtime or a private reordering. Inclusion failure is a batch not yet posted or a missing blob. Finality failure is an L1 reorg. Collapsing all three into “not arrived yet” starts the next debug on the wrong layer.
4. A screen: settled requires a finalized L1 block
The teaching screen allows a research note to call an L2 transfer settled, bookable or safe to sequence the next action only if a batch containing it exists on L1 and that L1 block is finalized. Soft confirmation is written as “sequencer accepted”. Included but unfinalized is written as “posted, awaiting finality”. The optimistic challenge window sits on its own line and is labelled withdrawals-only.
The screen does not replace a data-availability check or a forced-exit check. Those ask whether data can be retrieved and whether a user can leave under censorship. This note only answers which clock the wallet’s Confirmed sits on. Passing finality also does not prove a counterparty on another chain has credited the funds — that is a messaging-finality question, a separate reconciliation.
5. Keep a record another researcher can replay
A minimum record includes L2 chain ID, tx hash, wallet copy and client, soft-confirm timestamp, L1 batch or blob tx hash, L1 block number and hash, whether that block is finalized, minutes from send to finality, and whether settled entered the conclusion. An L2-explorer screenshot is not an L1 inclusion proof. Store RPC request and return so two refreshes are not spliced into one row.
Reconcile in a fixed order: soft confirm, then L1 inclusion, then L1 finality, then the challenge window if a withdrawal is in scope. Any gap between wallet Confirmed and L1 inclusion belongs in unexplained wait. Unexplained is not an accusation of fabrication; it is a ban on writing the gap into verified settlement. If a paid archive node is required to read historical blobs stably, record that source grade.
6. Confirmed is three clocks, not one adjective
The weak sentence is “the L2 already confirmed; it landed in two seconds”. A useful one is “soft confirm t1; L1 inclusion block B; finalized at t3; minutes from send to t3”. Until those three quantities are written, using a wallet tick to narrate irreversibility treats a sequencer receipt as Ethereum finality.
This is a research framework with hypothetical calculations, not a quality opinion on any rollup or wallet, and not investment advice.