Sequencer Confirmation
Pronunciation: SEE-kwen-ser kon-fer-MAY-shun
Also known as: Sequencer-Confirmed Transaction
Definition
A sequencer confirmation is an early status indicating that a layer-two sequencer has accepted and ordered a transaction in its local chain or batch. It usually arrives faster than base-layer settlement, but it is provisional. The transaction can still be excluded or reordered if the sequencer fails to publish data, the layer-two chain reorganizes, or protocol validation rejects the batch.
Overview
A sequencer confirmation is issued when the sequencer responsible for ordering layer-two activity includes a transaction in its current view of the chain. Users may see this status within seconds, making it useful for responsive applications. On optimistic rollups, it is often called an unsafe or sequencer-confirmed state until the relevant data is published to the underlying settlement layer.
The confirmation is not equivalent to Protocol Finality. The sequencer may temporarily control ordering, and its local block can be replaced if data availability or derivation rules are not satisfied. After publication to the base layer, the transaction can move to a safer state, and later to finalization when the underlying chain finalizes the corresponding commitment. Different rollups use different names and timing.
A sequencer confirmation can still provide meaningful evidence: it shows that the ordering service received the transaction and represented it in a proposed history. The strength improves when users can independently obtain the block data, verify execution, and confirm that the batch has been posted. However, a single operator acknowledgment remains vulnerable to outage, equivocation, censorship, or delayed publication.
Payment systems should model sequencer-confirmed, base-layer-published, safe, and finalized as separate states. Low-risk digital access may be granted at the early stage, while high-value fulfillment or withdrawals should wait for stronger confirmation. Monitoring should detect when a transaction remains sequencer-confirmed beyond expected publication time or disappears, triggering rollback and investigation procedures.
Audit and recovery workflows should preserve the sequencer block, ordering timestamp, batch publication reference, safe status, and base-layer finality. These records help because a sequencer can acknowledge an order before the data and commitment become enforceable on the settlement chain. Production safeguards need to detect disappearance or delayed publication and reserve irreversible actions for stronger states.
Its progression should be compared with Optimistic Confirmation and the later settlement state rather than compressed into one status.
Key Takeaway
A sequencer confirmation provides fast layer-two feedback, but final settlement depends on publication and finality at the underlying settlement layer.
Sources
- Transaction Statuses — Optimism Documentation (2026-08-02)
- Transaction Finality — Optimism Documentation (2026-08-02)
- OP Stack Protocol Overview — Optimism Documentation (2026-08-02)