A useful thing happened in agent infrastructure this June: several teams shipped "escrow layers for AI agents" - production MCP tools that let an agent run a full commit -> hold -> complete lifecycle without a human anywhere in the loop. An agent can now park value with a contract or service, wait for the other side to deliver, and release on completion. That is genuinely new, and it solves a real problem.
It is also worth being precise about, because "escrow" and "settlement" get used as if they were one thing. They are not. There are two structurally different ways to make a trade your agent does at 3am trustworthy, and the difference is exactly who holds the money while the trade is in flight.
Model one: held custody
In the held-custody model, a third party - a smart contract escrow, a custody service, a payment facilitator - takes the funds, holds them, and releases them when a condition is met. The condition can be anything you can express: a delivery confirmation, an evaluator's attestation, a timeout, a multi-sig approval.
This is the right tool for a large class of agent commerce. If your agent is paying a merchant, buying a dataset, or hiring another agent to do a unit of work, the hard question is subjective: did the thing actually get delivered, and was it any good? A hash function cannot see that. A custodian can - it gives the trade a place to pause while something or someone checks. The new agent-escrow tooling is built around exactly this shape: a job, a held balance, a release on completion. For agent-to-merchant payments riding on rails like x402, held custody is the honest primitive.
The cost is equally concrete. A held balance is a honeypot. Someone controls the funds between commit and complete, which means someone can freeze them, lose them, misconfigure the release condition, or get drained. You have added a trust assumption and a liveness dependency - the custodian has to be online, solvent, and honest at release time. That is often an acceptable price for the ability to arbitrate subjective delivery. But it is a price.
Model two: no custody at all
The second model deletes the custodian. In an atomic swap built on hash-time-locked contracts (HTLCs), both legs of a trade are locked to a single hash preimage. Reveal the preimage and every leg unlocks together; never reveal it and every leg refunds. There is no escrow account, no release decision, and no point in time where a third party is holding the money. The trade clears as one unit or it unwinds completely.
This is the right tool for the other large class of agent activity: two non-trusting agents exchanging assets, often across two chains - ETH for BTC, one chain's token for another's. Here the risk that matters is not "was the work good," it is "one leg lands and the other doesn't, and somebody just got robbed." Atomicity removes that failure mode by construction. No custodian means no honeypot, no freeze, no liveness dependency on a third party staying honest. The trade is safe because of how it is shaped, not because of who is watching it.
The honest limit is the mirror image of model one's strength: atomicity can only settle things that are assets moving on a ledger. It cannot judge subjective delivery, it cannot stream a payment against partial work, and it cannot rule on a dispute that lives off-chain. If your trade needs a referee, an HTLC has no referee to offer.
Where each one wins
Put plainly:
- Held custody wins when delivery is subjective, off-chain, or unfolds over time - agent-to-merchant payments, hiring an agent for work, anything where "did you actually deliver" is a real question someone has to answer.
- No custody wins when the trade is a clean, two-sided exchange of on-chain assets - especially across chains, where a bridge or a custodian would otherwise be the single biggest point of failure.
These are not competitors so much as different layers of the same stack. A mature agent economy will use both: held custody where a trade needs judgment, atomic clear-or-refund where it needs none. The mistake is using one where the other belongs - putting a custodian in the middle of a clean ETH-for-BTC swap (now you have a honeypot you never needed), or trying to atomically settle a subjective deliverable (now you have a primitive that literally cannot see the thing in dispute).
What we're building, stated honestly
Hashlock is the no-custody side of that stack: sealed-bid RFQ fused with HTLC atomic settlement, exposed to agents through an MCP server with six tools, so an agent can quote, match, and settle a cross-chain trade where no one - including us - ever holds the funds. The chain status, without rounding up: Ethereum mainnet is live end-to-end; Bitcoin is signet-validated with mainnet pending; Sui contracts are deployed and CLI-tested with gateway wiring in progress. We are not claiming BTC or Sui mainnet, and a comparison post is a bad place to fudge maturity.
The academic backing for the settlement design lives in the SSRN whitepaper if you want the formal version: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722. The MCP server and tools are open at https://github.com/Hashlock-Tech/hashlock-mcp, published as hashlock-tech/mcp (scoped) on npm.
The interesting question for builders is not which model is "better" in the abstract - it's where the boundary sits for your agent's flows. If you're wiring up agent trades right now: which of your trades genuinely needs someone to hold the money mid-flight, and which ones are clean enough that a custodian is just risk you could cryptographically remove?
More on the settlement design: https://hashlock.markets/methodology?utm_source=devto&utm_medium=post&utm_campaign=2026-06-11-custody-or-not
Top comments (0)