[ctfbruce]

Behaviour

Chain payment receipts are processed durably and acknowledged only after their effect is recorded:

• Dispatcher schema 22 adds payment_receipts: every PaymentReceipt addressed to this dispatcher is stored under its chain transaction digest and event position (one transaction may carry several receipts, even for one nonce) with a disposition (applied, duplicate, mismatch naming the field that differed, unknown_intent, expired). Marking a transaction paid is a conditional write on its outstanding status in the same local transaction, so a duplicate, reordered or re-read receipt cannot pay twice, and a second payment for a paid intent, by another transaction or another event of the same one, is recorded as a mismatch naming the paying digest and event.
• A receipt is validated before any effect: chain method, coin type for the currency, receiver (addresses compared in normalised form), exact amount that fits the local representation, and expiry. The expiry check never fired on main: the decoder read nothing into the timestamp field.
• The listener's cursor advances only over proven coverage: a catch-up asks the GraphQL indexer for the last checkpoint whose events it serves and reads and stores no further than the lower of that and the full node's tip, with each events query bounded above as well. Every receipt of the covered range is recorded before the cursor moves; a local failure or an undecodable event stops the pass and leaves the cursor, so a restart re-reads the range and finds duplicates instead of skipping payments. A streamed checkpoint ahead of the cursor records its own receipts and holds the cursor at the proven bound until the gap between them has been read through the indexer; the cursor never moves backwards. An invalid stored cursor is a startup error, not a silent reset; a first start without a cursor persists the bound it begins at.
• The schema also adds chain_transfers, the record of outbound payouts and refunds with the intended transfer, the signed transaction and its digest persisted before anything is broadcast, used by the following change.

Proof

• Base reproduction: an expired receipt was fulfilled and an invalid stored cursor accepted (internal/dispatcher/payments/sui scratch test on main).
• Local-fixture tests (an in-process GraphQL server serving pages and the indexer's mark, and real SQLite; no network, wallet or chain endpoint): node at 110 with the indexer at 105 keeps the cursor at 105 and applies the payment at 108 exactly once when the indexer reaches it; a streamed checkpoint 115 at indexer 105 records its receipt, holds the cursor and completes the gap when the indexer has it, and a re-read after a restart applies nothing twice; a rejected and a valid receipt event of one transaction pay in either order, replay without effect, and a second valid event is a mismatch; receipts applied once across pages, duplicates and a restart with reordered pages; each rejection recorded with its reason, including an amount beyond the signed range recorded exactly; unknown nonce recorded; a receipt to another payee not recorded; a trigger-refused write leaves the cursor and the retry applies once; undecodable events keep the cursor; a streamed checkpoint records its sequence and a failure keeps the cursor; a gap before the first streamed checkpoint is caught up first; an invalid cursor refuses to start; disabled mode writes nothing.
• The payments, Sui, HTTP API, storage and schema packages pass under -race on the composed tree.

Upgrade

Dispatcher schema 22 is required: stop the dispatcher, back up the database and run the explicit upgrade before starting this build.

Requires #364 (schema 20) and #373 (schema 21); this branch is based on #373's head.

Limits

• Receipts were exercised against local fixtures only; the payment-kit event layout (timestamp_ms last) and the coin-type string form are assumptions until a deployed package is checked.
• The indexer's mark (serviceConfig.availableRange for Query.events) and the event position (Event.sequenceNumber) are taken from the published Sui GraphQL schema and have not been confirmed against a live service; the streamed event index and Event.sequenceNumber are assumed to agree, and if they did not, a re-read receipt would be recorded as a second row whose effect is a mismatch, never a second payment. Receipts read during catch-up record no checkpoint number.
• Payout reservation and refunds outside the local transaction (Reserve exact payout amounts and reconcile uncertain transfers #80, Make refunds safe for empty orders, write failures and uncertain transfers #81) are the following change; chain payments remain disabled in every shipped configuration.

GitHub issue #79.

Candidate CI

Run 37284811811 on 2554a22: 16 of 16 lanes and required succeeded. Corrections (indexer-bounded cursor, receipt identity by event) are in f7c0b14, with #373's corrected head merged forward: run 37290240068 on f7c0b14, 16 of 16 lanes and required succeeded.