Two agents agree on a trade. The buyer's funds go into a contract. The seller's side is pending. Now answer one question: who decides when the money comes out?
That question sounds procedural. It is actually the entire design of a settlement layer, and this week the agent-economy ecosystem answered it four different ways without quite noticing it was answering the same question.
Signal 1: x402 volume collapsed, and Cloudflare built on it anyway
x402 settlement volume is down roughly 93% year-to-date. The seven-day average sits near $41,800, with the most recent provisional daily figure around $28,400. That is a long way from the late-2025 surge, which in hindsight looks like it was mostly testing rather than sustained demand.
At the same time, Cloudflare launched its Monetization Gateway on July 1, letting customers charge for webpages, APIs, datasets, and MCP tools, priced and enforced at the network edge, with usage metered and payments settled in stablecoins over x402.
Those two facts are not in tension. They tell you where the protocol actually is: speculative volume drained out, infrastructure adoption went up. A rail that a CDN embeds at the edge is not a dead rail. It is a rail moving from demo phase to plumbing phase, which is a downgrade in narrative and an upgrade in seriousness.
Note what the Cloudflare integration prices, though: access. You pay, you get the API call. Delivery and payment are effectively simultaneous because the deliverable is a HTTP response. There is no gap in which anyone needs to decide anything.
Signal 2: the IMF wrote it down
The IMF published a note on how agentic AI will reshape payments (Note 2026/004). Whatever your view of the analysis, the existence of the document is the signal. Institutions do not write notes about categories they consider hypothetical. The agent economy has moved from "interesting if true" to "modeled by people who set policy."
Signal 3: Kustodia shipped escrow as MCP tools, with a sharp thesis
Kustodia made its agent escrow infrastructure generally available, exposing the full escrow lifecycle as MCP tools so an agent can create an escrow, lock funds, monitor for delivery confirmation, and release payment without a human authorizing each step.
Their framing of the gap is worth quoting in substance, because it is correct: payment protocols including x402, AP2, and Stripe's machine payments handle payment initiation, but none of them provide a mechanism for holding funds between an agent's commitment to deliver and confirmed completion.
That is the gap. Their answer is: hold the funds, and give someone the release decision.
Signal 4: ERC-8183 named the decider
ERC-8183 formalizes a Job primitive with three parties, identified only by wallet address: Client (creates the job and locks the reward), Provider (does the work and hashes the deliverable on-chain), and Evaluator (reviews, then pays or refunds). A job moves Open → Funded → Submitted → Terminal, where Terminal is Completed, Rejected, or Expired.
The standard is careful not to say what an Evaluator is. It can be an LLM, a ZK circuit, a multisig, a DAO. That flexibility is the point. But structurally, the standard encodes a role whose job is to make a judgment call about whether funds move.
The shared assumption
Escrow with a release decision. An Evaluator that pays or refunds. Dispute handling in agent payment protocols. Different vocabularies, same architecture: a third role in the loop whose function is to decide.
And for most of what these protocols target, that is the right architecture. I want to be precise about this rather than score a point.
If the deliverable is work, as in "did this agent write code that passes the spec", "did the freelancer ship the design", "was the dataset what was promised", then there is no cryptographic proof of quality. Quality is a judgment. Somebody has to make it. An escrow contract with an Evaluator is not a compromise there; it is the correct primitive, and pretending otherwise would be dishonest. ERC-8183 and Kustodia are solving a real problem well.
Where the decider becomes a dependency instead
The picture changes when the deliverable is the asset transfer. Agent A sends ETH, Agent B sends the other leg. Nothing needs to be judged. There is no quality dimension. The only question is whether both legs happened.
At that point, an Evaluator stops being a necessary component and becomes a liability surface. The Evaluator can be slow. It can be unavailable. It can be captured, coerced, or simply wrong. And every agent in the system now inherits a trust assumption it did not ask for: not "will the counterparty perform" but "will the adjudicator adjudicate correctly."
Hash time-locked contracts remove that role rather than improving it. The release condition is a hash preimage. Reveal the secret and claim your leg, and the act of claiming publishes the secret that lets the counterparty claim theirs. Miss the timeout and both sides refund. There is no dispute path because there is nothing to dispute. The state machine has exactly two exits and neither of them requires a human, a committee, or a model to have an opinion.
That is what we build at Hashlock Markets: sealed-bid RFQ for price discovery without information leakage, fused with HTLC atomic settlement. Six MCP tools, so an agent calls it the same way it calls any other tool. No bridge, no custodian, no adjudicator.
Chain status, stated precisely: Ethereum mainnet is live end-to-end. Sui contracts are deployed and CLI-tested, with gateway wiring in progress, not live. Bitcoin is signet-validated with mainnet pending.
The honest limitations
HTLCs are not free and I would rather you hear the tradeoffs from us:
- Timeout risk. Locks expire. Get the timelock ordering wrong across two chains with different block times and you can create a window where one side is exposed.
- Capital lockup. Funds are immobilized for the duration of the lock. On a slow leg, that is real opportunity cost.
- Both legs must be on-chain. If one side of the trade is a promise about the physical world or about work quality, no hash solves that. Go get an evaluator.
- Liveness assumptions. The claiming party has to actually claim within the window. An offline agent can refund itself into a missed trade.
The design claim is narrow on purpose: for the subset of agent commerce where value moves against value, the release decision can be made by math instead of by a role. Outside that subset, escrow is the better tool and we would rather say so than oversell.
The question worth asking before you pick
When you are wiring settlement into an agent, ask what the deliverable actually is. If it is a judgment, you need an Evaluator and you should choose a good one. If it is an asset transfer, ask why there is a decider in your architecture at all, and what happens on the day that decider is unavailable.
Which one is your agent actually doing? And if it is the second one, what is your adjudicator's downtime plan?
Links
- Hashlock Markets: https://hashlock.markets/methodology?utm_source=devto&utm_medium=article&utm_campaign=2026-08-15-who-decides-release
- MCP server (npm, scoped): hashlock-tech/mcp - https://www.npmjs.com/package/@hashlock-tech/mcp
- GitHub: https://github.com/Hashlock-Tech/hashlock-mcp
- Whitepaper (SSRN): https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722
Sources for the signals above
- x402 volume decline and Cloudflare Monetization Gateway: CryptoPotato, The Defiant
- IMF Note 2026/004, How Agentic AI Will Reshape Payments: IMF
- Kustodia agent escrow MCP tools: Cointelegraph
- ERC-8183 Agentic Commerce: eips.ethereum.org
