Stablecoins solved settlement. A USDC transfer clears on a public chain in seconds, and anyone can read the transaction back from an RPC endpoint. That is real, and it is genuinely new.
But settlement is not the same as accountability. The on-chain record proves that value moved between two addresses. It does not prove why it moved, who or what authorized it, what policy context applied, or what evidence existed at the moment of intent. As autonomous agents begin to pay for services on their own, that missing context is exactly where disputes, compliance questions, and unclear liability will land.
A log is a claim. A receipt is proof.
Today, most of the story around a payment lives in the initiating system's own logs. That works right up until it matters — a chargeback dispute, an AML review, an agent that paid the wrong counterparty, an audit that asks you to reconstruct what your system believed at the time. A record a party keeps about itself is a claim. Proof is something an independent party can verify without trusting, or even involving, the party that produced it.
That is the distinction a receipt exists to close. Receipt Relay signs the facts around a payment event into an independently verifiable record, with an honest label for how strong the evidence actually is.
What a stablecoin payment receipt should bind
A useful payment receipt does not need to hold funds or touch the transfer. It needs to bind the context that the chain record leaves out:
- Intent — what the payer meant to do, at the moment they meant to do it.
- Actor — which agent, wallet, or human authorized it.
- Policy context — the limits, approvals, or rules that applied.
- Evidence tier — how the event was witnessed, stated plainly rather than dressed up.
- Settlement state — the claimed or verified status of the transfer itself.
Honest evidence tiers, not one flat "verified"
The most important design choice in Receipt Relay is that it does not pretend every receipt is equally strong. It signs at explicit proof-state tiers:
- Self-attested — Hive signs the transfer claim exactly as you describe it. For USDC and Circle, this is what is available today: Circle and USDC are receipt schemas on the event endpoint, not a live Circle call. Hive signs the payment intent you state; it does not contact Circle.
- Relay-observed — Hive itself made the HTTP call and signed hashes of the request and response, so the receipt reflects what Hive actually saw.
- Chain-verified — when you supply a transaction hash, Hive reads the transfer back from a public RPC and binds that confirmation into the receipt. Chain verification requires the supplied tx hash and public-chain lookup; it is not assumed.
Proof that is searchable and exportable
A receipt is only useful if you can find it and hand it to someone later. The Hive Ledger is a searchable index of signed receipts with a public verifier: anyone can check a receipt offline against Hive's Ed25519 public key, without asking Hive for permission. As the ledger puts it, the ledger is convenience — the receipt is proof.
Individual receipts can be grouped into signed proof vectors (R3Pv), which report verification depth, the weakest proof boundary in the group, a healing state, and a routing recommendation in one object. For audit, you can assemble an evidence bundle today from the public index plus the offline verifier; a one-click signed bundle export is a next-stage target.
When a payment goes wrong, be honest about recovery
Not every bad payment can be undone, and a receipt layer that pretends otherwise is worse than none. Payment Healing models recovery as distinct states rather than a single undo button: prevented before submission, quarantined in reversible escrow, clawed back through issuer or token authority where that exists, counter-acted by an offsetting transaction, or — when a transfer is already final — evidence-only, producing a recovery receipt for a human, issuer, or regulator to act on.
The honest boundary matters: Hive does not claim that broadcast, finalized transactions on public blockchains can be reversed. At v0 this is receipt and observability only — no funds move. Issuer-side integration is on the roadmap, not live today.
Where agentic payments already run on-chain proof
For agent-to-agent commerce, x402 Checkout shows the settled end of the same story: a live USDC quote on Base, a non-custodial payment you submit from your own wallet, and on-chain proof verified against Base — never faked. Hive never holds your keys or funds. Where a payment settles on chain and you can supply the proof, the receipt can earn its chain-verified tier; where it cannot, the receipt says so.
Settlement tells you the money moved. A receipt tells you why it moved, who authorized it, and what evidence backed it — in a form anyone can verify without trusting your dashboard.
Stablecoins made payments fast and final. Receipts make them accountable. As more of that flow is initiated by agents rather than people, the systems that can prove the context around a transfer — not just the transfer — will be the ones regulators, counterparties, and customers are willing to trust.
See how Receipt Relay signs payment intent, evidence, and settlement state into an independently verifiable record — with honest tiers and offline verification.