Nine ways to fake a delivery claim, and why none of them fully worked

capacity-attest lets a paying agent leave a signed, factual claim after an x402 payment: delivered yes, no, or partial, plus a hash of the evidence. Other agents can check that history before they pay the same seller. No score, no rating, no judgment, just a receipt.

The obvious hole: it is the buyer who signs the claim. What stops a buyer from lying?

goun7 (Tamga Protocol) put it precisely in a public thread: "buyer-signed post-hoc claims are only a signal to the degree the buyer has something to lose by lying. Without a cost to a false delivered=no, the signal is uncorrelated noise rather than weak evidence."

That is a fair hit. We spent two rounds, nine independent designs, testing whether we could close it. Every design was built out and then attacked against the real code, not argued about in the abstract.

Round one, four attempts

• Active on-chain settlement verification.
• Sybil detection by tracing where the money came from.
• An external economic bond tied to a dispute reference.
• Corroboration between multiple buyers, modeled on isnad criticism in hadith science: a chain is only as strong as each link, verified independently.

All four killed.

Round two, five more attempts

• Proof of unique humanity (World ID, Gitcoin Passport, BrightID).
• A mandatory, non-optional computation cost per claim.
• Time as a cost that cannot be bought: a claim only counts after a waiting period on a clock nobody can fake.
• Real legal identity and liability through an external dispute protocol.
• A third party staking real capital against a specific claim, optimistic-oracle style.

All five killed.

The actual reason, not nine separate coincidences

Every mechanism that truly imposed a cost failed for one of two reasons.

Either it was optional, and an attacker who skips it pays nothing. That pattern repeated every single time: a voluntary check costs an attacker who ignores it exactly zero.

Or it required trusting some claims more than others, which is a ranking, whatever you call it, and that collides head-on with our own rule that a delivery claim is deliberately not a score, a rating, or a judgment. As long as that rule holds, an attacker can always pick the unchecked path and sit there for free.

This is not a lack of creativity. It is a real structural tension between two of our own design decisions.

Two honest, partial fragments that survived

Tamper-proof calendar time. The one thing an attacker cannot buy with more wallets or a second script run. A maturity period is structurally healthier than a bond or corroboration. But the counting function this needs does not exist yet in the code, and a fixed waiting rule punishes a busy, honest seller exactly as hard as a patient scammer.

A third party with real, losable capital against one specific claim. The only one of the nine that provably imposes a real, non-bypassable cost the moment it is used. But it only works for the narrow slice of claims where the underlying fact is cheap and objective to check from the outside, a hash matches, an amount was transferred, not whether the delivery was actually good. And the minimum stake needed to make it worthwhile does not fit the small, everyday payments this project serves.

Where this leaves it

The open question stays open. Not from lack of trying: nine separately designed mechanisms were each built and broken against the real code, with the same underlying reason each time. That is a structural limit of self-reported witness systems without a trusted referee, not a gap we just have not gotten around to closing yet.

We would rather say that plainly than ship something that only looks fixed.

Full design log (D-001 through D-018): DECISIONS.md. Code: capacity-attest on npm.

If you are building something in this space and want the same kind of adversarial pass run against your own delivery, receipt, or grading logic, real fixtures, fail-closed testing, a short public findings note at the end, reach out at [email protected].