The wallet with 97% of its balance frozen

When an order closed, the release routine looked for a payment-detail record to know how much to return: that collateral field was the only evidence that something had been reserved. A new flow came in that charged correctly and completed the order, but never created that record. Orders finished perfectly and the release found nothing to release. The balance froze over weeks without a single error in the logs.

I rebuilt the balance timeline with forensic SQL over production to separate the real hold from the amount inflated by an earlier bulk UPDATE. I found that the guard written to detect stranded reservations carried the same original flaw — it joined against the reservations table, so holds with no reservation row were invisible to it. A detector built on the assumption that caused the problem detects nothing.

The root cause was fixed in the new flow and stranded holds stopped being created. The balance already frozen was NOT released blindly, and that was the call that mattered most: the forensics showed the largest hold was indistinguishable between "the payout went out and was never settled" and "the payout never went out". Releasing it by default meant either paying twice or taking money from the customer, and the database could not tell which. Each hold was separated by type and routed to provider reconciliation and to compliance, corrected through reversal entries with two-person approval instead of editing the balance by hand. The lesson became a design principle: a hold is not a boolean or a side effect, it is a ledger entry. With double-entry, "how much is held" is a balance and not a hopeful JOIN — which is exactly why LedgerCore treats holds and releases as first-class entries.