Which agent-payment code pays once when the answer is lost?
A payment settles. The connection drops before the reply. Most code reads that as "failed" and pays again — and every replay guard correctly lets the second payment through, because it is a genuinely new one. This register records, with public evidence, which implementations survive that moment.
The ledger
Every row links to its proof. Open findings are counted, never named — a company is not put next to a bug until they have fixed it. Fixed entries are listed with credit, because shipping a fix in hours is the thing worth recording.
| Implementation | Verdict | What was at stake | Evidence | Time to fix |
|---|---|---|---|---|
| x402 reference implementation x402-foundation/x402 · TypeScript, Go, Python | VERIFIED SAFE by code read | Reference facilitator & resource server for the whole ecosystem | Emits settlement_pending with the broadcast hash; reconciles a same-payload retry through a pending-settlement store instead of re-broadcasting (PR #3083). Read 2 Sep 2026. | — |
| Stellar facilitator accensa/x402-facilitator-stellar | VERIFIED SAFE by code read | Facilitator on the Stellar rail | Retries only pre-response failures; never fast-fails a live sendTransaction (src/rpc-retry.js). Read 1 Sep 2026. | — |
| PipRail SDK piprail/piprail · multi-chain agent payer + gate | VERIFIED SAFE by code read | Payer that submits signed authorizations and on-chain proofs across rails | On a timeout after submitting the authorization it surfaces the nonce and instructs "re-present the SAME signed authorization; do NOT re-pay"; a 402 without success:false re-presents the same header; spend is recorded exactly once on the affirmative-settle path (sdk/src/client.ts). Read 3 Sep 2026. | — |
| ClawRouter BlockRunAI · LLM router, USDC per call | FIXED | Pre-auth catch spanned the payment-carrying send; a lost response signed a second payment | #317 → released v0.12.267 with a red-green test that makes the send reject | 4.3 h |
| Agent402 MikeyPetrillo · agent purchase client | FIXED | Default idempotency key was clock-seeded, so an agent-level retry re-debited credits | #1126 → agent402-client 0.8.3, key now stable across calls | 16.5 h |
| x402 MCP bridge hpp-io | FIXED | Wallet daily-spend cap could be exceeded by concurrent payments | #10 | 18 h |
| hypawave MCP hypawave | FIXED | Spending cap bounded each payment, not total spend | #1 | 26 h |
| Franklin BlockRunAI · agent wallet | FIXED | Wallet reservation released on an aborted x402 payment that could still settle | #128 | 9 d |
| 19 implementations facilitators, wallets, payment SDKs, MCP servers | UNDER DISCLOSURE | Same seam, reported privately or as a finding-first issue with the fix | Named here only after they ship. Counts updated as they close. | open |
| Everything else | UNREAD | — | No verdict is implied by absence. Unread means unread. | — |
Also fixed outside payments after our reports: mcp-server-kibana #12, #13, atlassian-confluence-mcp-server #55.
Method
Two evidence tiers, always labelled. A verdict never rests on a claim we cannot link.
Battery run — the strong tier
The client makes one purchase against hostile-facilitator, which settles and then misbehaves on cue, counting how many distinct payments actually arrived. One is safe. Two is the double-charge.
accept_then_timeout— settles, hangs past your timeout5xx_after_settle— settles, returns 502double_402— re-challenges a request that already paidslow_answer— settles, answers just under the wirereconcile_unavailable— settles ambiguously, and the "did it land?" read also failsdeclared_safe— checks you are not over-refusingclean— control
Code read — the honest tier
A line-by-line read of the settle, retry and signing paths, written up as a public issue with the mechanism, why the existing guards do not cover it, the minimal fix, and the test that would have caught it. Every finding is checked against the implementer's own defences before it is filed, and each report states its own ceiling: a code read is not a live reproduction.
- Verdicts by code read are marked as such in the ledger.
- A finding becomes public only after the gate that refuses to name a company next to an unfixed claim.
- Nothing here is a CVE, an exploit, or an accusation — it is a reliability seam with a fix attached.
Get your implementation verified
A fixed-scope Retry-Safety Review reads every path where a payment can be signed, sent, or retried, runs the battery against your client, and returns each finding with its fix and its test. If it passes, it goes on this page as VERIFIED SAFE by battery run — with a badge you can link. If it doesn't, you get the fixes, and it goes on the page when you ship them.
1 · Pay — $1,200 2 · Send your repoTwo steps, no call. Findings come back on your request within a week; a clean battery run earns the badge within 24 hours. What's included.
Self-test first, free: npx -y effectfence demo shows the double-charge on your own machine in ten seconds; hostile-facilitator run -- <your purchase command> runs the whole battery.