Escrow Needs a Judge. Atomic Settlement Doesn't. Most Agent Stacks Are Buying the Wrong One.

In June, Kustodia shipped something the agent-payments stack genuinely did not have, and their CEO described the gap better than anyone else has:

"x402 solves the payment event, when an agent pays for a service call in milliseconds. But when an AI agent commits to a contract that takes hours or days to complete - a data processing job, a software module, a research deliverable - who holds the payment? Who releases it when both sides confirm the work is done? That custody layer didn't exist. We built it."

• Rodrigo Jimenez, Kustodia, June 4, 2026

He's right about the gap. He's right that x402, AP2, and Stripe's machine payments all solve payment initiation and stop there. And their answer is coherent: a smart contract on Arbitrum that, in their words, "acts as the referee, holding the funds impartially, releasing them only when the programmatic release conditions are met," exposed to agents as MCP tools covering the full lifecycle - create, hold, release, dispute.

That's a real product solving a real problem. It is also not the problem we solve, and the difference is not marketing. It's structural.

The word "escrow" is currently doing two completely different jobs in agent infrastructure, and a lot of teams are wiring up the wrong one because both jobs sound the same in a sentence.

The one-line test

Can the contract verify the release condition without asking anyone?

Everything follows from the answer.

Class A - deliverable for payment. An agent commissions a research report, a data pipeline run, a rendered asset. Payment goes in. Then someone has to decide: was the work delivered? A contract cannot look at a research report and form an opinion. Something outside the contract has to say yes or no - a human, an oracle, a verifier agent, a dispute process. That something is a judge. You can make the judge fast, programmatic, and non-custodial, and Kustodia has clearly worked hard at exactly that. You cannot make it not exist. Class A has an irreducible third branch: release, refund, and someone decides which.

Class B - asset for asset. An agent trades 40k USDC for 0.5 ETH with a counterparty it has never met. There is nothing to judge. The release condition is "did the other asset actually arrive?" - and that is a question the chain answers by itself. In a hash-time-lock, revealing the preimage to claim one leg is what unlocks the other. The proof of payment and the payment are the same event. There is no third branch, because there is nothing left to arbitrate: either both legs settle, or the timelock expires and both sides reclaim what they put in.

Class A can't get rid of the judge. Class B can't usefully have one. A referee with authority over an atomic swap is not a safety feature - it's a new attack surface bolted onto a mechanism that was already complete.

The trust surface you inherit

This is the part worth being honest about, in both directions.

If you're in Class A, you are choosing a judge, and you should look straight at it. Who or what decides? What is the appeal path when an agent disputes at 3am? And - the question almost nobody asks - can the rules change while your funds are inside? Kustodia states its contracts are UUPS-upgradeable, which "preserves existing escrow balances and transaction history during upgrades." For their problem that is arguably the correct call: arbitration logic is genuinely hard, bugs will be found, and being able to fix one without stranding live balances is worth a lot. But upgradeability means an admin key with authority over the logic sitting above your money. That's a trade, not a flaw. Just price it.

If you're in Class B, the honest tradeoffs are different and they are not small. Capital sits locked for the duration of the timeout. Timeout parameters across two chains with different finality assumptions are awkward to tune and easy to get subtly wrong. The party who moves second holds a free option and can walk away, costing you time and locked capital even though it costs you no principal. And the refund path is not magic - somebody's wallet has to be online to broadcast the reclaim.

What you get in exchange for those tradeoffs is narrow and specific: no one, including us, can decide to keep your money. Our own V1 mainnet contracts are immutable. That is a constraint, not a boast - it means a bug ships to V2 rather than getting patched under you, which is exactly why the audit gate exists before V2 goes anywhere near mainnet.

I wrote about where the judge is unavoidable in more detail in Who Arbitrates the Arbiter?. The short version: the judge isn't the enemy. Buying a judge for a problem that doesn't have one is.

The live proof, from this month

The Class B claim - the guarantee lives in the script, not in the operator - stopped being theoretical in August.

Boltz, a non-custodial Bitcoin swap service, suspended all swaps on August 3 after months of AI-assisted attacks, with the line that should be pinned above every settlement design doc: attackers "iterate faster than a team our size can find and patch." Ten days later, on August 13, all three founders stepped down and handed control to a group identified only as veteran Bitcoiners. The amount Boltz itself lost has not been disclosed. As of late August the service is still offline.

Now list what changed in those ten days: the threat model, the operating team, the ownership, the capital, the roadmap, the ability to answer questions about losses. Every operational layer turned over.

User funds lost: zero.

Not because the team was heroic - they were, by their own account, losing a race - but because custody was never on their servers to begin with. It was in Bitcoin script: a hashlock and a timelock, worst case a refund. The operational layer was replaced wholesale and the script layer did not move.

That is the entire argument for Class B, delivered as a dated news story instead of a whitepaper diagram. And it cuts at us too, so let's say it plainly: we run a coordinator. If ours went dark tomorrow the same way, no new trade could start, and every open leg would refund by timelock. That's the guarantee - not that our service is unkillable, but that killing it costs you time, not principal.

Three questions before you wire anything

1. Is the release condition self-proving? If the chain can answer it (did the asset arrive?), you want atomic settlement and a judge is dead weight. If it can't (was the work good?), you need a judge and pretending otherwise just hides one.
2. Who can change the rules while your funds are inside? Upgradeable contract, admin multisig, pausable? Fine - but know it, and know who holds the key.
3. What happens when the service dies? Not "if it's hacked" - when it goes dark, gets sold, or the founders walk. Does the worst case degrade to denial-of-service, or to loss?

Most agent stacks are answering question 1 by accident, question 2 never, and question 3 with optimism.

Where we sit

Hashlock is a settlement layer, not a payment rail and not an arbitration service. Sealed-bid RFQ for price discovery without information leakage, fused with HTLC atomic settlement, exposed to agents as an MCP server with 6 tools. The pitch in one line: PayPal made it safe to pay strangers online; we make it safe to trade digital assets with strangers on-chain - except nobody holds your money. Your money never leaves your wallet until theirs arrives.

Status, stated precisely because vague status claims are how this industry loses trust: the settlement leg runs live end-to-end on Ethereum mainnet today. Sui contracts are deployed and CLI-tested with gateway wiring still in progress - not live. The Bitcoin HTLC path is validated on signet, with mainnet pending. Base, Arbitrum, Solana, and TON are roadmap, not shipped.

For the Class A problem - "did the deliverable arrive and was it acceptable?" - we are not your answer, and you should go look at the people building referees. Just be sure that's the problem you actually have.

Docs and the MCP server: https://hashlock.markets/docs?utm_source=devto&utm_medium=article&utm_campaign=2026-08-26-escrow-vs-atomic
The protocol design is written up in full on SSRN.

So which one are you actually building? If you've wired escrow into an agent flow recently, I'd like to know which class your release condition falls into - and whether you checked before you picked.