Confirmation states

Every streamed record says where it sits between sequencing and settlement, so you pick your own tolerance instead of waiting for a block by default.

The ladder

SequencedIncludedFinalized

A market maker acts on SEQUENCED. A custodian’s books wait for FINALIZED. Same stream, same schema, different tolerance — which is only possible because the state travels with the record rather than being implied by which endpoint you called.

States

Field	Type	Description
SEQUENCED	pre-confirmation	Seen on Robinhood's public sequencer feed, before block inclusion. The lowest-latency signal available on this chain.Can still end at DROPPED. Decide what you do in that case before acting on it.
INCLUDED	confirmed	Present in a published block.
FINALIZED	settled	The L1 batch containing this block has been posted to Ethereum.
DROPPED	terminal	Sequenced but never included in a block.Emitted explicitly. A pre-confirmation is never left unresolved.
REORGED	terminal	Included in a block that was subsequently reorganized out.

The reconciliation guarantee

Every record we emit at SEQUENCED reaches a terminal state. If a sequenced transaction never lands we emit DROPPED; if an included one is reorganized out we emit REORGED.

Silence is not an acceptable outcome. A consumer holding an unresolved pre-confirmation has no way to distinguish “still pending” from “we lost track of it”, and that ambiguity is worse than not offering pre-confirmation data at all.

Subscribing

for await (const tx of client.transactions.stream({  includeUnconfirmed: true,   // include SEQUENCED})) {  switch (tx.confirmationState) {    case "SEQUENCED":  provisionallyAct(tx); break;    case "INCLUDED":   confirm(tx);          break;    case "FINALIZED":  settle(tx);           break;    case "DROPPED":    case "REORGED":    unwind(tx);           break;  }}