What commits when the answer never arrives.

The interesting part of a wallet is what happens when the happy path stops. A request can commit and lose its reply; a retry can arrive twice; cancellation can overtake the bet it cancels. I wanted visitors to explore those decisions themselves, with enough evidence to challenge the result.

The interface turns persisted events into moving requests, commit markers, a ledger tape, and replay. Four guided incidents explain the mechanisms; eight interactive heists let visitors choose attacks. Free play uses seeded outcomes. The ledger and attempt tables expose the records behind the animation, and replay changes the view without sending another payment.

The wallet stores the transaction identity, payload hash, ledger effect, and original response in one database transaction. An identical retry receives that stored receipt. Reusing the identity with a changed amount or player is refused. Double-entry postings must balance at commit, and accounting records are append-only within each run.

In the duplicate-payout incident, a 10-credit stake and 30-credit win move the balance from 100 to 90 to 120. Seven payout deliveries produce one payout effect; two conflicting copies are refused. Visitors can inspect the transaction identity, each attempt, and the postings rather than rely on the PASS label.

The provider records deliveries in a durable outbox and retries under the same economic identity. A failure before commit rolls the transaction back. A failure after commit leaves a receipt that a retry can recover. Reconciliation checks cached balances against the postings instead of treating the displayed balance as proof.

The native NestJS reference uses PostgreSQL and a supervisor that restarts a wallet process killed after commit, before its reply. Tests cover real multi-connection duplicate and competing-spend cases. The browser demonstrates its own commit, storage-flush, worker-termination, replacement, and retry sequence; its database worker survives the wallet replacement.

The public version imports the reference wallet and provider services and their SQL migrations. React runs the interface; Web Workers run the services and PGlite databases. Browser adapters replace native transport and process management, while a separate adapter makes scenario setup and its opening event atomic.

PGlite serializes SQL on one connection per database. Controlled scheduling and worker termination demonstrate those browser behaviours; they do not reproduce PostgreSQL multi-connection races or an operating-system process kill. Reload can reopen this tab’s stored history and resume deliveries. Browser storage eviction and power-loss recovery are outside the demonstrated guarantees.

The Inside job heist deliberately crosses a different boundary: a crooked provider submits 300 credits for a legitimate 30-credit win. The wallet accepts the signed amount and the postings balance, but the outcome audit detects the extra 270. Prevention and detection are different results, and the interface shows that failure.

Verification compares browser fixtures with disposable native PostgreSQL runs, independently recomputes balances from postings, and includes deliberately defective controls. Hosted checks cover the incidents, eight heists, reload, and evidence inspection. These are scoped engineering results: the project uses fictional credits, integrates with no commercial provider, and makes no claim of production financial use. Physical-device and visitor-comprehension testing remain open. Source is private.