Hash-chained revenue: why your agent payments need provenance

Every x402 settlement you have ever seen was, until recently, opaque. The
merchant told you what they earned and you either trusted them or did not.
For a capital-management tool that is not a trust model, it is a trust crisis:
drift and opacity are the two failure modes the ecosystem has not admitted.

Drift happens silently. A rounding change in a fee, a replayed request, a
transaction that settles twice — each one quietly breaks the ledger and nobody
can see where. Opacity is worse: even a perfectly accurate revenue number is
unfalsifiable if the reader cannot inspect the entries that produced it. The
fix is not a better dashboard. It is a data structure.

The P31 revenue ledger records every settlement with a SHA-256 prev-hash link,
so each row commits to the entire history before it. Any edit to an old entry
changes every subsequent hash. The chain is cheap, dependency-free, and
provable in a single HTTP round-trip.

{
  "entry_id": "0x9f1a…",
  "settlement_usdc": 0.02,
  "prev_hash": "a31c…",
  "sha256": "5d2b…",
  "audit": "/audit/verify?hash=5d2b…"
}

The verify endpoint is public and unforgiving. GET
/api/revenue/verify-chain returns {"valid":true} only when every prev-hash
link matches and the chain is contiguous. Each revenue row carries an audit
link (/audit/verify?hash=…) so a single settlement can be checked on its own.

None of this needs a blockchain. A hash chain over Cloudflare Workers + D1 is
fast, free to operate, and gives agents the same provenance a block explorer
gives a ledger. That is the point: provenance should be a property of the
record, not a feature you pay for.