Fifth & Nine

The problem

A token claim debits a custodial balance, then sends on chain. If confirmation times out, the obvious retry re-sends — and the first transaction may well have landed. That is a double payout, in someone else's money.

What we did

The claim moves from claimable to processing before the transfer is submitted, so a retry finds nothing left to reserve and returns the in-flight state instead of sending again. Recovery is deliberately manual: the reconciler reports stuck claims for a human to verify on chain, because from the database alone, "no signature was recorded" and "the signature has not been recorded yet" are indistinguishable.

The problem

Instalment plans need to know how many payments have landed. Incrementing a counter when a webhook arrives is wrong, because webhook delivery is at-least-once and retries are normal operation, not failure.

What we did

Each paid invoice inserts a ledger row under a unique constraint on the invoice identifier — that insert is the idempotency gate. The instalment count is then a recount of paid rows, never an increment. If the ledger write fails, the endpoint returns an error so the processor retries; acknowledging a payment we did not record loses a customer's money quietly. The final payment flips plan state under a compare-and-set, so the claim email is sent exactly once.

The problem

A custodial balance is a promise. If the treasury sells tokens that already back customer balances, the promise silently stops being funded — and nothing in the system notices.

What we did

Sales check a reserve invariant — tokens held, minus tokens sold, must still cover the sum of custodial balances — and refuse when it does not hold. Related: when a required database function is missing, the endpoint returns an explicit error naming it rather than a zero balance. A zero is a lie the interface will render confidently. An error is not.

The problem

For unique-edition tiers the buyer picks a specific edition. Between page load and signature, someone else can take it. The contract then aborts at the edition-marker account — after the buyer has already approved a wallet prompt on a transaction guaranteed to fail.

What we did

A preflight treats the chosen edition as preferred rather than required, resolving against the live sold bitmap plus an in-flight reservation set so two lines in one cart cannot book the same slot. If the preference is gone, it substitutes the lowest free edition silently. The same resolver runs in the card-payment path, so background retries self-heal identically.