Why
The RPC call succeeds before the business promise is safe. This is where chain finality becomes product policy: cheap reversible goods can accept risk; expensive irreversible delivery cannot.
A payment system that stores only paid = true cannot represent a reorg. Product fulfillment and chain confidence must advance separately: a reversible benefit can be granted early, while an irreversible shipment waits.
How it works
Build a reorg-aware payment state machine, replay a removed receipt on a local fork, and verify that reversible fulfillment rolls back while irreversible fulfillment waits for the configured confidence level.
PoC
Implement detected → included → safe → finalized plus reorged. Replay a removed receipt on a local fork and prove that provisional fulfillment is withdrawn or retried, while high-value fulfillment never starts before its configured threshold.
| Chain state | Product action |
|---|---|
| Included/latest | Acknowledge and reserve |
| Safe | Low-risk fulfillment |
| Finalized | Irreversible settlement |
| Reorged | Rollback, retry, or request payment |
Reference: Ethereum JSON-RPC block tags.
Review clarification
Card rails already run this machine — crypto hid it behind a boolean
Traditional card processing is authorize → capture → settle, with a chargeback window measured in months. This card's reorged state is the chargeback, rediscovered. Crypto marketed "no chargebacks," but until finality a payment is probabilistic — so any honest payment product converges on the same tiered shape card rails use. The table's real move is pairing each chain state with a product action: that is risk pricing, not plumbing.
The tiers have numbers, and they are chain-specific
On Ethereum L1: included ≈ 12 seconds, safe (justified) ≈ 6.4 minutes, finalized ≈ 12.8 minutes. On an L2 the same words mean different clocks — sequencer preconfirmation in milliseconds, L1 posting, L1 finality — which is exactly l2-finality-three-clocks. So "which tier ships the goods" cannot be one global setting; it is a per-chain policy table, and the PoC should record one per target chain.
The machine is missing a sixth state, and it prevents false alarms
After a reorg the removed transaction usually re-lands automatically — it returns to the mempool and is mined into the replacement chain. So reorged → rollback + "payment failed" email is the false-positive trap. The honest machine is six states: reorged → pending-reinclusion → (re-included | failed after timeout). Roll back the benefit immediately; delay the customer-facing verdict through a grace window.
Test mechanics, and where Jayverse plugs in
Locally this is very runnable: anvil's snapshot/revert (or anvil_reorg) mines the payment, reverts, re-mines without it — then assert the indexer notices the receipt vanish. ponder-reorg-indexer is this card's infrastructure half: "detected the removal" actually happens in the indexer. Applications in this catalogue's own plans: a Verex bet credits at included (a reversible ledger entry), withdrawals wait for finalized, and x402-settlement-retry shares the boundary — a facilitator's "settled" response is also a receipt, and this card asks the follow-up: settled at which tier? Pairs naturally with a local supersim L2 lab: same fork, three clocks disagreeing, one state machine reacting.