Escrow for machine payments
Recourse gets the money back.
An agent pays for an API call, and the response is empty, stale, or quietly wrong. The money is already gone. Recourse holds the payment in escrow, settles the argument inside a trusted enclave, and refunds the buyer when the seller broke a promise it published.
The missing step
x402 is a clean way for an agent to pay for an HTTP request. It works, and it has one hole: the money moves before anyone has looked at what came back.
x402 today
Request
agent calls the API
402
price quoted
Pay
money leaves the agent
Response
whatever comes back
No recourse
the money is already gone
Settlement is final the moment it happens. There is no step that asks whether the response was worth paying for.
With Recourse
Request
agent calls the API
402
price + SLA hash
Pay
into escrow, not the seller
Deliver
response + signed receipt
Verify
checked against the SLA
Release
clauses held
Refund
a clause broke
One extra step, and the money waits behind it. Everything else — the header, the facilitator, the seller's code — is unchanged.
A human notices and stops buying. An agent making a thousand calls an hour does not notice, has no refund path, and keeps paying until somebody reads a log. These are the six the demo service can produce on demand — every one is caught by a clause the seller published in advance.
✕ Wrong value
"bid": -1
caught by clause 2 · $.bid > 0
✕ Out of tolerance
"spreadBps": 900
caught by clause 4 · ≤ 50
✕ Stale data
"asOf": 40s ago
caught by clause 5 · freshness
✕ Missing field
no "ask"
caught by required field
✕ Not even JSON
<html>…
caught by malformed body
✕ Wrong type
"bid": "cheap"
caught by clause 2 · not numeric
See it work
Both of these are replays of payments that actually happened on testnet. Every hash is on a public explorer — the pacing is theatre, the facts are not.
Lifecycle
The seller publishes a machine-checkable SLA and quotes its hash in the 402. The buyer refuses to pay for terms that do not match their own advertised hash.
Settlement goes to a contract on Hedera, not the seller. The buyer binds that deposit to the exact terms on-chain, and the seller checks the binding before doing any work.
A signature over the response hash comes back with the data. The hash is fixed by the seller and the bytes come from the buyer, so neither side can fabricate the evidence later.
The buyer posts a bond. A Chainlink CRE enclave re-reads the payment from chain, pulls the evidence over confidential HTTP, and evaluates the SLA deterministically.
Only the payment id, outcome and reason code leave the enclave. CCIP carries them to Hedera, where the escrow pays the winner. Once adjudication starts, the attested verdict and the settlement run without either party controlling the outcome.
The uncontested path never touches an oracle. Funds sit for a short window, the seller withdraws, and the whole exchange costs one extra contract call. Adjudication is the exception, and only the exception pays for it.
Built on
Each holds up a different third of the system, so none of them is a logo bolted onto a project that would work without it.
Verified on testnet
Not a mockup. These are real payments, a real enclave verdict, and money that actually moved.
The seller returned a negative bid. Reason 102 is offset 100 plus clause 2 — numeric.gt on $.bid. The refund names a published promise, not an opinion. The bond came back too, because the buyer was right.
All five clauses held, so there was nothing to dispute. The window lapsed and the seller withdrew in a single call — no oracle, no adjudication, no cross-chain hop. This is the common case, and it is deliberately the cheapest one.
Verdict to refund
~18 min
mostly Sepolia finality
Guarantees
The seller fixes the hash by signing it; the buyer supplies the bytes. A dispute is only judged on merit once the two agree, so no witness has to be paid and neither party has to be trusted.
An enclave result is attested and verified by consensus, which requires the same input to produce the same output every time. So the model helps author the SLA up front, and the enclave enforces a contract both sides already signed.
The workflow binary is handed to the enclave and is auditable by anyone. Only the disputed payload stays sealed. That is the right way round: you should be able to check the rules and still keep your data private.
If no verdict ever arrives, anyone can settle the payment after a timeout and the buyer is made whole. Every state has a way out, including the one where the adjudicator itself fails.
If you are building one, the buyer on the other end has no way to get its money back today. Closing that takes one change to where the payment goes.