Escrow vs x402: How AI Agents Should Pay Each Other

#ai #api #crypto #agents

Two agents need to exchange money and they have never met. The design question is not "how do they pay?" It is "what happens when the work does not arrive?"

x402 answers the first question: pay for this request, right now. Escrow answers the second: hold the money until the seller proves the work, then release, refund or dispute it. OpenClawCash is built on escrow, and the whole flow is four API calls.

The short answer

Use x402 when an agent buys something small and instant: one API call, one search, one inference. The payment and the response happen together, and there is nothing to dispute.
Use escrow when an agent buys work that takes time or can go wrong: a report, a design, a trade, a delivery. The buyer's money waits until the seller proves delivery, and the buyer keeps a way out.

What x402 does

x402 is a payment protocol built on the HTTP status code 402 Payment Required. A server answers a request with a price, the agent pays in stablecoins, and the server returns the resource. No account and no API key on the seller side, which suits tiny frequent payments and metered APIs.

What it does not have is a step between paying and receiving. Payment settles as the request is made: no built-in proof of delivery, no refund path, no dispute. For a one cent API call that is fine. For a job that runs for an hour and can fail, it is not.

What escrow does

An OpenClawCash escrow moves through fixed states:

pending_funding -> funded -> proof_submitted -> released / refunded / disputed

The seller agent creates a payment request with an amount, a token, a network, a funding deadline and a dispute window:

curl -X POST ${BASE_URL}/api/agent/checkout/payreq \
  -H "Content-Type: application/json" \
  -H "X-Agent-Key: occ_your_api_key" \
  -H "Idempotency-Key: checkout-create-001" \
  -d '{
    "walletId": "Q7X2K9P",
    "amount": "1000000"
  }'

The response carries what the rest of the flow needs: id, escrowId, a dedicated escrowAddress, and state: "pending_funding". The money goes to that escrow wallet, created for that one request, not to the seller.

The buyer agent funds it from a wallet it controls. When the settlement token balance is already there, quick pay is one call:

curl -X POST ${BASE_URL}/api/agent/checkout/escrows/es_d4e5f6/quick-pay \
  -H "Content-Type: application/json" \
  -H "X-Agent-Key: occ_your_api_key" \
  -H "Idempotency-Key: quick-pay-001" \
  -d '{ "walletId": "Q7X2K9P" }'

The seller then submits proof, a hash plus a URL to the deliverable:

curl -X POST ${BASE_URL}/api/agent/checkout/escrows/es_d4e5f6/proof \
  -H "Content-Type: application/json" \
  -H "X-Agent-Key: occ_your_api_key" \
  -H "Idempotency-Key: proof-submit-001" \
  -d '{ "proofHash": "sha256:...", "proofUrl": "https://example.com/proof/123" }'

And the buyer releases, which moves the funds to the seller's payout wallet:

curl -X POST ${BASE_URL}/api/agent/checkout/escrows/es_d4e5f6/release \
  -H "Content-Type: application/json" \
  -H "X-Agent-Key: occ_your_api_key" \
  -H "Idempotency-Key: escrow-release-001" \
  -d '{}'

GET /api/agent/checkout/escrows/:id reads the result back: state, funding transaction, release or refund transaction, proof and dispute fields.

Why escrow, and what is still rough

The jobs agents take are work, not just calls: research, content, trades, data pulls. They take minutes or hours and they can fail, and a payment that cannot be taken back is the wrong tool for work that has not happened yet.

Recourse is a safety feature: escrow gives a buyer agent a way out, the same way spending limits give it a ceiling. Funding is checked against the buyer wallet's per-transaction, daily, weekly and monthly limits like any other payment, and a blocked attempt is logged. Refund is a seller action back to the buyer's funding address, and a dispute is a buyer action.

Two things to know before you build on it. Escrow funds sit in a wallet OpenClawCash creates and holds for that request until release or refund, the same hosted model as every OpenClawCash wallet, and it is not a smart contract. And OpenClawCash does not speak x402 today: if you need x402, pair a wallet that supports it with OpenClawCash.

Side by side

	x402	OpenClawCash escrow
Best for	tiny, instant purchases such as API calls	work that takes time or can fail
When the seller gets paid	immediately, with the request	when the buyer releases after proof
Proof of delivery	none built in	seller submits proof before release
Refund	none built in	refund path in the flow
Dispute	none built in	the buyer can open one
Who holds the funds meanwhile	nobody, the payment settles at once	a dedicated escrow wallet held by OpenClawCash
Spending limits	depends on the wallet paying	checked against the buyer wallet's limits
Networks	stablecoins on supported chains	Ethereum mainnet, Polygon and Solana, plus Sepolia for testing

See it work

Two independent agents settled a real escrow on Ethereum mainnet, from request to release: two agents, one escrow. For the seller and buyer walkthrough, read the escrow 2.0 guide, and for every route above, the public docs.

This post is a rewritten version of Escrow vs x402: How AI Agents Should Pay Each Other, which carries the full FAQ.

DEV Community