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.
Where it lands in Jayverse
- Verex: credit reversible ledger entries at included, pay out at finalized. Encode the six-state machine (detected/included/safe/finalized/reorged/pending-reinclusion) so a bet credits early but a withdrawal or other irreversible payout waits for the configured finality tier, not a single paid boolean.
- Wallet: record which tier a given action requires, per chain. Included versus finalized means different clocks on Sepolia today than on the future OP-Stack Devnet L2, so the simulate-before-sign flow needs a per-chain policy table, not one global setting.
- Devnet: build the reorg test locally before it ships. Use anvil's snapshot/revert or anvil_reorg to mine a payment, revert it, and re-mine without it, then assert the indexer notices the receipt vanish — the same rehearsal the Liquid-issuance invariant work needs.
Key expressions
| Expression | 뜻 · 쓰이는 자리 |
|---|---|
| roll back | 원상 복구하다, 되돌리다 · 리오그 발생 시 혜택을 취소할 때. "the reversible tier rolls back" |
| converge on | 결국 ~로 수렴하다 · 서로 다른 접근이 같은 결론에 이를 때. "any honest payment product converges on the same tiered shape" |
| hide behind a boolean | 단순 참/거짓 뒤에 복잡한 상태를 숨기다 · 리오그 가능성을 감춘 설계를 비판할 때. "Crypto... hid it behind a boolean" |
| false-positive trap | 오탐 함정(가짜 경보에 속아 잘못 대응함) · 성급한 실패 처리 로직을 지적할 때. "is the false-positive trap" |
| grace window | 유예 기간 · 확정 판단을 잠시 미루는 시간대. "delay the customer-facing verdict through a grace window" |
| re-land | (트랜잭션이) 다시 블록에 포함되다 · 리오그 후 재포함 상황을 설명할 때. "the removed transaction usually re-lands automatically" |
| plug in | (어디에) 들어맞다, 연결되다 · 이 개념이 실제로 적용되는 지점을 말할 때. "where Jayverse plugs in" |
| threshold | 기준치, 문턱값 · 정책이 발동하는 설정값을 말할 때. "high-value fulfillment never starts before its configured threshold" |
| rediscovered | (이미 있던 개념을) 다시 발견한 · 새 기술이 옛 관행을 재발명했을 때. "the chargeback, rediscovered" |
| chargeback | 지불 거절(카드결제 취소 청구) · 카드망의 분쟁 처리 절차, 리오그 상태와 같은 개념으로 연결됨. "This card's reorged state is the chargeback, rediscovered" |