Sample: replay across a restart

A pay-per-call server must remember that a payment was already used. In our own test server that memory lived in process memory, so a restart reopened the window: the same signed payload was accepted again and the settlement call ran twice.

before restart: HTTP 200, settle calls = 1
after restart:  HTTP 200, settle calls = 2

Scope of the claim

The facilitator in this test was a mock that always reports success, so this shows the server calling settlement twice. It does not show a second on-chain transfer, and it says nothing about anyone else’s deployment.

Run the proof offline

Download the reproduction and source (ZIP) · SHA-256. Python 3.10 or later; no dependencies, accounts or network calls. MIT licensed.

unzip restart-proof.zip
cd restart-proof
python3 verify.py

The verifier runs the same two checks in fresh Python processes. Both fail with memory-only state; both pass when the existing reference service is configured with a persistent state file. It checks completed-payment replay and a pending broadcast across restart. The final command exits successfully only when that before/after result matches.

This is a configuration-level fix in our own reference service. All settlement calls are mocked. It does not establish a second on-chain charge, multi-process safety or production readiness; the included README states the exact limits.

Working on a data migration? Run our separate CSV reconciliation example.

What a deliverable looks like

The exact preconditions, a minimal test that fails before the fix and passes after, a severity rating based on what actually moves money, and a fix plan: persist the payment key before settling, and treat a pending settlement with a broadcast transaction id as unresolved rather than failed.

Have a reproducible bug? See the $60 pilot terms.