DEV Community: Baris Sozen

Escrow with a judge vs atomic locks: where agent trades actually need each

Baris Sozen — Thu, 09 Jul 2026 06:08:49 +0000

In January, three researchers built a shopping agent on Google's Agent Payments Protocol (AP2), the standard designed to make agent-led purchases safe through cryptographically verifiable mandates. Then they attacked it with nothing more exotic than adversarial text. The paper, "Whispers of Wealth" (arXiv 2601.22569, revised May 2026), reports that simple prompt injections reliably subverted the agent: one attack steered which products the agent ranked and bought, another exfiltrated sensitive user data. The part of the stack that failed was not the cryptography. The mandates verified exactly what they were designed to verify. What folded was the layer that exercises judgment.

Hold that result in mind, because the agent economy is currently pouring money into judgment.

Everyone is hiring a referee

Look at what shipped in the last few months for agent-to-agent commerce, and a single pattern repeats: put the money in escrow, and let a judge decide when it comes out.

ERC-8183 formalizes it: funds sit in an escrow contract while an Evaluator - an agent or a human - decides whether the deliverable meets the spec before releasing payment. It is the pattern Virtuals' Agent Commerce Protocol runs on. Circle has piloted an escrow agent for USDC flows. Kustodia and Nava (which raised $8.3M) are startups built on the same shape. And on July 1, BNB Chain and AWS launched agents that bank themselves - agents deployed to Amazon Bedrock AgentCore with their own wallets, identity, and payment stack from birth. Even the category label is contested now: at least one project has declared itself an "MCP Settlement Standard" from a landing page.

That is five separate, serious teams independently converging on the same component: a referee who holds the money.

The referee exists for a good reason

Before arguing against the judge, steelman him. Most agent-to-agent commerce today is hiring: one agent pays another for work. Write this code. Produce this research. Render this video. The deliverable is subjective. No contract can verify "the code is good" on-chain, so someone with judgment has to look at the output and decide whether it earns the payment. Escrow-plus-Evaluator is a reasonable answer to that problem, and the teams building it are not naive. For services, some referee - human juror, AI evaluator, reputation-weighted panel - is probably unavoidable.

The question is what happens when the same pattern gets applied to the other kind of commerce: trading. Two agents exchanging assets. USDC for ETH, tokenized T-bill for stablecoin, asset on one chain for asset on another.

What the red-team result means for judges

An Evaluator is judgment with release authority. The Whispers of Wealth result generalizes uncomfortably well: any component that uses contextual reasoning to decide whether money moves is a prompt-injection surface, and the injection does not need to be sophisticated. The AP2 agent was not beaten by a cryptographic break. It was beaten by words.

Now give that component custody. A compromised trading agent with standing credentials can lose everything it controls - we wrote about the six-figure Morse-code drain in May. An escrow judge is one step better: the blast radius is the escrowed amount. But the judge is also a single choke point that both sides must trust, that can be manipulated by either side, and that adversarial agents will probe continuously, at machine speed, forever. Security economics 101: the value locked behind a discretionary decision grows, and the cost of attacking discretion stays flat.

The judge-free lane

For asset trades, there is a structural alternative, and it is older than most of this cycle: make the chain itself the verifier. Hash-time-locked contracts work like this:

Agent A locks asset X, spendable only with the preimage of hash H, refundable after timeout T1.
Agent B sees A's lock and locks asset Y under the same hash H, with a shorter timeout T2.
A reveals the secret to claim Y - which publishes the secret on-chain.
B uses the revealed secret to claim X. Both legs clear, or both refund after timeout. There is no state where one side has both assets.

No referee, because there is nothing to judge: "did the asset arrive" is exactly the question a blockchain answers natively. Delivery verification is objective, so discretion - the injectable layer - is removed from the settlement path entirely. A fully compromised agent can lose at most the one trade in front of it, never a standing account, and no third party ever has custody.

This is what we build at Hashlock: sealed-bid RFQ price discovery fused with HTLC settlement, exposed to agents as an MCP server with tools covering the full lifecycle - create_rfq, respond_rfq, list_open_rfqs for discovery, create_htlc, withdraw_htlc, refund_htlc for settlement. It runs end-to-end on Ethereum mainnet today, driven entirely by MCP tool calls. Sui contracts are deployed and CLI-tested with gateway wiring in progress, and Bitcoin is validated on signet with mainnet pending. Package: hashlock-tech/mcp (scoped), v0.4.1.

Honest limits of the math camp

Atomicity is not free, and pretending otherwise would repeat the escrow camp's mistake in mirror image. Capital is locked for the duration of the settlement window. Timeout parameters are a real design problem: too short risks stranding a leg, too long hands the counterparty a free option to wait out price moves before revealing. And the mechanism only settles what a chain can verify - it has nothing to say about whether delivered code is good code. Atomic locks do not replace Evaluators for services. They replace them for assets.

The comparison, plainly

Dimension	Escrow + Evaluator	Atomic locks (HTLC)
Delivery verification	Judgment (agent/human)	The chain itself
Custody during trade	Escrow contract + judge authority	Stays with each party until settlement
Prompt-injection surface	The judge's reasoning	None in the settlement path
Compromised-agent blast radius	Escrowed amount, judge-dependent	The single trade in front of it
Subjective deliverables (services)	Handles them	Cannot
Objective deliverables (assets)	Adds an unnecessary trusted party	Native fit
Capital efficiency	Escrow locked until judgment	Locked for the settlement window
Cross-chain	Wrapped/bridged or single-chain	Native, same hash on both chains

The boundary this table draws is the actual debate: not "which one is right" but where the border sits. If escrow-plus-judge becomes the standard for hiring and then expands by default into asset trades, agents inherit a discretionary custodian in exactly the place they least need one. If the border holds, the two camps are complementary layers of the same economy - judges for work, math for assets.

The deeper methodology behind our side of the border is in the whitepaper on SSRN, and the settlement flow is documented at hashlock.markets/docs.

So here is the question for the people building agents right now: when your agent trades an asset with a stranger's agent, do you want a referee whose reasoning can be whispered at, or a lock that cannot be argued with? And if you are in the escrow camp - what is the mechanism that keeps the Evaluator safe from the same injection that beats the agents it referees?

AI agents have a spec for paying and a spec for hiring. The spec for trading is missing.

Baris Sozen — Wed, 08 Jul 2026 07:35:19 +0000

On June 23, Circle published the official USDC specification for the Machine Payments Protocol. The mechanics are elegant: an agent calls an MPP-enabled endpoint, the server answers with HTTP 402 Payment Required, the agent signs an EIP-3009 USDC authorization and retries, and Circle Gateway verifies and settles - batched, with a crosschain profile, no API keys, every request attributable to a wallet address. It's part of the Agent Stack Circle has been assembling since May, and it already has its first USDC-backed derivative (USDCx on Stacks) building against the spec.

A few months before that, ERC-8183 - "Agentic Commerce," proposed by Virtuals Protocol and the Ethereum Foundation's dAI team - specified a different verb. Not paying: hiring. A Client agent posts a job and locks the budget in on-chain escrow; a Provider agent does the work and submits proof; an Evaluator confirms the deliverable before funds release or refund. BNB Chain shipped the first live implementation, the BNBAgent SDK, bundling ERC-8004 identity, escrow, and decentralized arbitration into one framework - on testnet now, mainnet planned.

So in the space of a few months, machine commerce got two of its three verbs standardized.

Machines can pay - and that lane is getting crowded. MPP joins x402, which Chainalysis has reportedly tracked past 100 million agentic payments on Base, with a foundation member list that reads like a who's-who of TradFi and cloud. Google's AP2 handles the intent-and-mandate layer above. Stripe has been reported working with Cross River Bank on bank-grade single-use cards so agents can spend autonomously, and Mastercard spent June pitching "Agent Pay for Machines." Card networks don't build for markets they think are hypothetical.

Machines can hire: ERC-8183, with an implementation you can run today.

The third verb - trade - has no spec. And it's the verb where the money is at risk in a way the other two never are.

Why trading is the hard one

Look at the structure of each interaction, not the branding.

A payment is one leg. Value moves in a single direction against a service that has already been rendered or is about to be. The failure mode is small and bounded: you paid for an API call that didn't return. MPP is well-designed precisely because it embraces this - sub-penny amounts, batched settlement, optimistic trust. For pay-per-call, that's the right trade-off.

A hire is subjective. Did the research report actually answer the question? Is the generated code any good? Someone has to judge, which is why ERC-8183's Evaluator role exists and why it's the most interesting part of the standard. The escrow-plus-judge pattern is essentially arbitration rebuilt on-chain - and for subjective deliverables, a judge genuinely earns its place. There is no cryptographic test for "the essay was good."

A trade is two-sided and objective. Two parties exchange asset for asset - ETH for USDC, BTC for ETH - and the entire risk is simultaneity. Whoever moves first hands the other side a free option. There is nothing subjective to evaluate: either the counterparty's asset verifiably arrived or it didn't, a fact a contract can check without any judge at all.

Run a trade through the pay-spec and you've recreated settlement risk: one side authorizes a transfer, then waits and hopes. (A solver or card issuer front-paying and reconciling later looks atomic from the user's seat - but underneath, someone's balance sheet is holding the risk.) Run it through the hire-spec and you've placed an Evaluator - trusted, bribable, censorable - in the middle of something a hash comparison could have verified. Custodial rails solve it by becoming the intermediary. Bridges solve it by pooling everyone's assets into what history keeps demonstrating is a honeypot.

Every one of those imports a trust assumption that the trade itself doesn't require.

What a trade spec would have to define

If someone sat down to write the missing standard, the requirements list falls out of the structure:

Price discovery without information leakage. An agent that broadcasts "I need to sell 50 ETH" has already moved the price. Sealed-bid RFQ - quotes committed before any are revealed - is the machine-native answer, and it's also where agents quietly beat humans: a machine can genuinely not leak its order flow.

Atomic execution. Both legs lock to the same cryptographic condition. The secret that claims one leg is, by construction, the proof that unlocks the other. Both legs clear or neither does. This is the hash-time-locked contract, a primitive that has existed since roughly 2013 - the spec race is new, the answer is not.

Automatic refund. If the trade doesn't complete inside its window, both sides get their funds back without anyone's permission. No stuck states, no support tickets, no judge.

Asymmetric timeouts. The subtle one: the two legs cannot expire at the same moment, or the party who reveals the secret can be front-run at the boundary. Any serious spec has to encode the timeout ordering, not leave it to implementers.

Verification as a layer, not a custodian. Knowing who you're trading with (ERC-8004-style identity, counterparty directories) belongs above settlement - informing the decision to trade, never holding the assets.

The demand side isn't hypothetical

Agents are already trading. ClawBank's "Manfred" was reported by CoinDesk in May as the first autonomous company filing with its own EIN, bank account, and crypto wallet. Olas's Polystrat agent reportedly cleared 4,200+ prediction-market trades in its first month. Whatever the exact numbers, the direction is unambiguous - and every one of those agents is settling through custodial accounts or standing credentials, meaning each one carries the "compromised agent forfeits everything it holds" blast radius we wrote about yesterday.

The rails for paying and hiring are being standardized in public, at speed, by well-funded teams. The rails for trading are the gap.

Where this runs today

We've been building in that gap. Hashlock Markets fuses the two halves a trade spec needs - sealed-bid RFQ for price discovery, HTLC settlement for execution - behind six MCP tools: RFQ creation and response, HTLC lock, withdraw, refund, and status. Any MCP-capable model can drive the full trade lifecycle from the agent's own wallet, published as the scoped npm package @hashlock-tech/mcp.

Chain status, stated plainly: Ethereum mainnet is live end to end. Sui contracts are deployed and CLI-tested with gateway wiring in progress. Bitcoin is validated on signet with mainnet pending. So today, "live" means Ethereum. The V1 contracts are immutable and went through a five-layer verification pipeline - Slither, Halmos symbolic execution, Echidna fuzzing, Stryker mutation testing, and a runtime invariant monitor. The formal treatment is in our SSRN paper.

To be clear about the map: none of the specs above are competitors. An agent in 2027 will plausibly pay for its API calls over MPP, hire a specialist over ERC-8183, prove its identity over ERC-8004 - and settle its asset trades atomically underneath all of it. Different verbs, different layers. The stack is being assembled in public, one spec at a time, and the trading layer is the one still written in working code rather than standards prose.

What a trade spec would not fix

Honesty section. Atomic settlement bounds what a compromised or confused agent can lose to the single trade in front of it - it does not make the agent smart. A valid-but-dumb trade (wrong price, wrong size) still executes; sealed bids and per-trade caps shrink that risk without zeroing it. Funds locked in a pending trade are unavailable until completion or refund - capital efficiency is a real cost. And key custody is its own layer: no settlement design rescues a stolen signing key.

The open question

If the trade spec does get written, where should it live - as an ERC, as a de-facto MCP tool-shape convention, or as a Circle-style method registry with multiple implementations? And what would it take for you to hand an agent real value against it?

Docs and the live protocol: hashlock.markets/docs - MCP server source: GitHub

One tweet drained an AI agent's wallet. A smarter agent wouldn't have saved it.

Baris Sozen — Tue, 07 Jul 2026 10:26:56 +0000

In May, an X user posted a message in Morse code, asked an AI to translate it, and walked away with six figures from a wallet he didn't own.

The mechanics, as reported by CCN and Giskard, were almost embarrassingly simple. The attacker put "drain the wallet" into Morse code and asked Grok to decode it in public. The Bankr trading bot wired to that account treated the decoded text as an instruction and complied. Reports put the losses between $150,000 and $200,000, and the incident now sits in the OECD AI incident registry.

The write-ups that followed mostly reached the same conclusion: better filters. Detect exotic encodings. Sandbox translations. Scan tool descriptions for injected instructions. All of that is useful. None of it is the point.

Agents will always be trickable

The attack surface of an LLM agent is language itself. Every message it reads - a tweet, a tool description, a document it was asked to summarize - is a potential instruction, and the set of ways to smuggle an instruction past a filter is unbounded. Morse code worked in May. Base64 has worked. Unicode confusables have worked. Whatever the scanners catch next quarter, the quarter after that produces something they don't.

This is an arms race with a structural asymmetry: the attacker needs one encoding that slips through; the defender needs to anticipate all of them. Arms races like that are worth running - you should absolutely filter - but you should not build a financial system whose safety depends on winning one.

The real vulnerability was standing credentials

Ask a different question about the May incident: not "how was the agent fooled" but "why could decoded text move money at all?"

Because the agent held live credentials with standing spending power. A hot wallet it could sign from without limits. In other setups it's an exchange API key with withdrawal rights, or a custodial account the agent operates end to end. In every one of those designs, each message the agent reads is one social-engineering step away from everything the agent holds. Compromise the reasoning, inherit the account.

That's the number that should worry you. Not can my agent be fooled - yes, it can, and so can its successor. The number is what a fooled agent forfeits. Call it the blast radius.

Most agent-trading setups today have a blast radius of "the entire balance." That is a choice, not a law of nature.

Shrinking the blast radius is a settlement problem

Here is the structural alternative. Instead of giving the agent an account it can spend from, give it a primitive where money is locked to a cryptographic condition: a hash-time-locked contract (HTLC). The agent's funds move into a contract that will release them to the counterparty only when the counterparty's asset has verifiably arrived - the same secret that claims one leg unlocks the other. If the trade doesn't complete inside a fixed window, both sides are refunded automatically. Both legs clear, or neither does.

Now replay the Morse-code attack against that design. The attacker fully compromises the agent mid-trade. What can the injected instruction actually reach? Not the account - there isn't one. Not the counterparty's leg - it's locked to the same condition. The worst realistic outcome is that a trade in flight fails to complete and unwinds to a refund. There is no standing pool of credentials to drain, because each trade is its own locked box with its own expiry.

PayPal made it safe to pay strangers online by absorbing fraud risk onto its own balance sheet. The equivalent for autonomous agents is not a smarter fraud model - it's settlement where fraud has nothing to grab. Your money never leaves your wallet until theirs arrives.

What atomic settlement does not fix

Honesty section, because this design is not magic:

A compromised agent can still be talked into initiating a valid-but-dumb trade - wrong price, wrong counterparty, wrong size. Atomic settlement bounds the loss to that one trade, and the surrounding machinery narrows it further (sealed-bid RFQ price discovery makes "trade at an absurd price with my accomplice" harder; counterparty verification and per-trade size caps shrink it again) - but bounded is not zero. Judgment risk survives.

Capital lockup and timeout risk are real trade-offs. Funds committed to a trade are unavailable until it completes or refunds, and timeout windows have to be chosen carefully - the two legs can't expire symmetrically or the party revealing the secret can be front-run.

And if the attacker steals the agent's signing key rather than injecting a prompt, that's a different layer of the stack - key custody and policy signers - which no settlement design substitutes for.

Where this runs today

Everything above is live end to end on Ethereum mainnet through six MCP tools - RFQ creation and response, HTLC lock, withdraw, refund, and status - published as the scoped npm package hashlock-tech/mcp. Any MCP-capable model can drive the full lifecycle from the agent's own wallet. Sui contracts are deployed and CLI-tested with gateway wiring in progress, and the Bitcoin flow is validated on signet with mainnet pending - so today, "live" means Ethereum. The V1 contracts are immutable and went through a five-layer verification pipeline (Slither, Halmos symbolic execution, Echidna fuzzing, Stryker mutation testing, plus runtime invariant monitoring). The protocol design is written up in an SSRN paper if you want the formal treatment.

Docs and the live protocol are at hashlock.markets; the MCP server source is on GitHub.

The audit worth running this week

List every credential your agent holds. Next to each one, write down the maximum a single malicious message could move through it. If any line on that list says "everything," that line is your real security roadmap - ahead of the next filter update, ahead of the next model upgrade.

What did your list say? I'm genuinely curious how people are bounding this today - spend caps, policy signers, per-session wallets, something else? Comments open.

Six MCP tools, one trade: walking an AI agent from RFQ to refund

Baris Sozen — Fri, 03 Jul 2026 07:48:57 +0000

Most writing about agent commerce stays at the layer-diagram altitude: rails here, settlement there, trust boundaries in between. Useful, but abstract. Today let's go to ground level and walk through what actually happens - call by call - when an AI agent trades with a stranger and no custodian is anywhere in the loop.

The whole lifecycle fits in six MCP tools. Any MCP-capable model can drive them; there's no SDK to integrate and no signing service to trust. The package is hashlock-tech/mcp (scoped) on npm, and everything below runs end-to-end on Ethereum mainnet today.

Phase 1: Price discovery - three tools

create_rfq is where a trade starts. The taker's agent broadcasts a request-for-quote: pair, size, direction, expiry. The important design decision is that the RFQ is sealed-bid - responding makers can't see each other's quotes. For human OTC desks that's a nicety. For agents it's load-bearing: an autonomous maker that can observe competing quotes will shade its price against them in milliseconds, every time, forever. Sealed bids force every maker to quote their true price.

list_open_rfqs is the maker side of discovery. A market-making agent polls open RFQs, filters by pair and size, and decides what to quote. This is the tool that turns a settlement protocol into a two-sided market - flow has to be findable.

respond_rfq submits the quote. The taker's agent collects responses until expiry, picks the best one, and moves to settlement. Notice what has not happened yet: no funds have moved, no approvals granted, no counterparty trusted. Price discovery is informationally rich and financially inert - exactly the property you want before an unattended agent commits capital.

Phase 2: Settlement - two tools, one secret

create_htlc locks the first leg. The taker commits funds into a hash-time-locked contract: a hashlock (only the holder of a secret preimage can claim) plus a timelock (after the window, the funds refund to sender). Committed, not transferred. The maker then locks the mirror leg on the other chain against the same hash.

withdraw_htlc is the claim. When the taker withdraws the maker's leg, the act of claiming reveals the preimage on-chain - which is precisely what the maker needs to claim the taker's leg. One secret clears both legs. There is no state of the world where one side has both assets and the other has neither. That's what "atomic" means when it isn't a marketing word: not "fast," not "a solver front-paid and will reconcile later" - a cryptographic guarantee that the trade completes on both legs or on neither.

No judge decides the trade is complete. Completion is the reveal of the secret. Compare that with escrow-and-evaluator designs, where a third party rules on whether obligations were met - a human institution rebuilt in Solidity.

Phase 3: The unwind - the tool nobody advertises

refund_htlc is the sixth tool and, for autonomous operation, the most important one. If the window lapses - the counterparty vanished, the quote went stale, the agent crashed mid-flow - the timelock returns the funds. Nobody to petition, no support ticket, no dispute process. The failure mode of the entire system is "you get your money back."

That property is worth dwelling on, because it's the difference between a protocol you can demo and a protocol you can leave running. An unattended agent will eventually hit every failure mode that exists. If any of those failure modes is "funds are stuck pending a human decision," you don't have autonomous settlement - you have supervised settlement with extra steps.

The forward extension

Here's where the primitive gets more interesting than a spot swap. Nothing in the HTLC construction says the settlement window must be now. Stretch the timelock and the same six calls bind a forward: two agents agree a price today, both legs commit today, and the claim window opens at T+24h (or T+7d). Between agreement and settlement, no custodian holds margin, no clearinghouse guarantees performance, no credit desk evaluates counterparty risk. If both sides show up, one preimage clears both legs. If one side no-shows, the other's refund path executes.

This is the gap payment rails don't address. x402, AP2, AWS's new AgentCore Payments preview - these move one known asset, one direction, right now, and they're getting genuinely good at it. But a rail cannot bind a two-sided, cross-asset obligation that settles later. That takes a settlement primitive, and the rails will eventually need one underneath them.

Where this runs today

Chain-claim honesty, because the agent economy has enough overclaiming already: Ethereum mainnet is live end-to-end - everything in this walkthrough works there now. Sui contracts are deployed and CLI-tested, with gateway wiring in progress. Bitcoin is validated on signet, mainnet pending. The protocol design is documented in our SSRN paper (https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722) for those who want the formal treatment.

Docs and the full tool reference: https://hashlock.markets/docs?utm_source=devto&utm_medium=article&utm_campaign=2026-07-03-forward-tool-walkthrough - GitHub: https://github.com/Hashlock-Tech/hashlock-mcp

Here's the question I keep coming back to: of the six tools, five get all the attention, but refund_htlc does the work that makes unattended operation possible. If you're building agents that touch value - what does your stack's failure mode look like? Stuck funds and a ticket queue, or a timelock that hands the money back?

Payment rail or settlement layer? Why the agent economy will have to tell them apart

Baris Sozen — Thu, 02 Jul 2026 20:31:50 +0000

Every few weeks the agent-commerce space gets a new "settlement layer for the agent economy." Look closely and most of them are payment rails wearing the word "settlement." The distinction sounds pedantic. It isn't. It decides whether an autonomous agent trading value across chains has to trust an intermediary - or doesn't.

So here's a question worth arguing about, and I'll give you the honest case for both sides.

In the next 12 months, do agent payment rails - x402, AP2, and their kin - absorb cross-chain settlement entirely, or does settlement stay a permanently separate layer beneath them?

Two different questions

A payment rail answers: who fronts the money, and how does the request-to-pay flow? x402 is a clean example - it revives HTTP 402, attaches a stablecoin payment to a request, and lets an agent pay for a resource inline. AP2 (Google's Agent Payments Protocol) sits a layer up, handling mandates and intent, and uses x402 as one of its payment rails. This is genuinely good infrastructure. It makes "an agent pays for a thing" a solved problem.

A settlement layer answers a different question: how does value actually clear between two parties who don't trust each other, with no one holding the funds in between? That's not about routing a payment. It's about the moment of exchange - agent A has an asset on Ethereum, agent B has one on Bitcoin, and both need to end up on the correct side without a custodian, a bridge honeypot, or a referee deciding the deal is done.

Those are different jobs. The interesting question is whether one layer swallows the other.

The honest case that rails absorb settlement

This isn't a strawman - there's a real argument here.

x402 already batches stablecoin settlement and now runs across multiple chains. AP2 rides it as a payment rail. The x402 Foundation, now under the Linux Foundation, pulled in Google, Visa, AWS, Circle, and Anthropic. When a standard gets that much institutional gravity and a stablecoin like USDC as its settlement asset, the path of least resistance is for the rail to just keep expanding scope downward. Why would an agent developer bolt on a separate settlement primitive when the rail they already integrated can front the money, reconcile it, and call that "settled"?

If most agent commerce is agent-pays-merchant - a subscription, an API call, a data purchase - then a rail with a stablecoin and a big enough consortium probably is enough. Settlement becomes a feature of the rail, not a layer of its own.

The honest case that it stays separate

Now the other side.

A payment rail decides who fronts the money. Atomic settlement decides how value clears with nobody fronting anything. Those are different trust models, and you can't collapse one into the other by adding features.

Look at what "settlement" usually means on the rail side: a solver or facilitator front-pays, the user gets their outcome immediately, and the books get reconciled behind the scenes. That's atomic from the user's point of view - but underneath, someone took counterparty risk, held funds, and had to be trusted to reconcile honestly. For agent-to-merchant payment, that's fine. For two agents swapping value-for-value across chains, it reintroduces exactly the intermediary the whole design was supposed to remove.

Atomic settlement via hash-time-lock contracts (HTLCs) works differently. Two parties lock their respective legs. Revealing a single cryptographic secret unlocks both sides at once; if the secret never appears, both legs refund on a timeout. No one fronts anything. No one holds both sides. "Complete" isn't a status a facilitator sets - it's a condition the contract can verify or refund. That's a primitive, and primitives tend not to get absorbed by the conveniences built on top of them. HTTP didn't absorb TCP.

Why the answer matters for what you build

If you believe rails absorb settlement, you build for a world where integrating x402/AP2 is the whole story and cross-chain trust-minimization is a niche.

If you believe settlement stays separate, you treat the rail and the settlement layer as complementary: the rail is how an agent expresses "pay for this," and the settlement layer is the primitive that rail calls when the trade is value-for-value across chains and neither side should hold the other's funds. In that world x402 and AP2 aren't competitors to a settlement layer - they're clients of it.

This is the layer we work on at Hashlock: sealed-bid RFQ for price discovery fused with HTLC atomic settlement, exposed to agents as an MCP server with six tools. The analogy we keep coming back to: PayPal made it safe to pay strangers online, with PayPal sitting in the middle. A settlement layer aims to make it safe to trade with strangers on-chain with no one in the middle - your money never leaves your wallet until theirs arrives.

One honesty note, because it matters in this category: it's easy to overclaim reach. To be precise about our own status - Hashlock is live end-to-end on Ethereum mainnet; the Sui contracts are deployed and CLI-tested with gateway wiring in progress; the Bitcoin path is signet-validated with mainnet still pending. Rails ready, more trains coming.

Where I land - and where you might not

My bias is on the table: I think settlement stays a separate layer, because "who fronts the money" and "how value clears trustlessly" are questions you can't merge without quietly bringing back a middleman. But the rails-absorb-it case is real, and if agent commerce turns out to be overwhelmingly agent-to-merchant payments, I could be wrong about how big the separate layer needs to be.

So I'll ask you the same thing I'm asking myself: in 12 months, does the rail swallow settlement, or does settlement stay its own layer underneath? If you think the rail wins, what's the mechanism that makes a solver-fronted rail actually trust-minimized? I'd genuinely like the strongest version of that argument.

More on the settlement-layer approach: https://hashlock.markets/?utm_source=devto&utm_medium=article&utm_campaign=2026-07-02-rail-or-layer

Whitepaper (SSRN): https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722

Who decides an AI agent's trade is 'complete'? Escrow needs a judge. Atomic settlement doesn't.

Baris Sozen — Tue, 30 Jun 2026 06:48:33 +0000

A new standard for autonomous-agent commerce now has a live implementation, and it's worth reading closely - not because it competes with atomic settlement, but because it draws the line between two settlement philosophies more clearly than anything I've seen so far.

The standard is ERC-8183, the Agentic Commerce Protocol, launched earlier this year by the Ethereum Foundation's dAI team and Virtuals Protocol. The implementation is BNB Chain's BNBAgent SDK, which the team describes as the first live build of the spec (shipped on testnet in March 2026, mainnet pending). If you build for AI agents, both are worth understanding on their own terms. They're also the clearest mirror I've found for explaining what "atomic settlement" actually means.

What ERC-8183 does

ERC-8183 models commerce as a job with an escrowed budget. There are three roles:

a Client who posts the job and funds it,
a Provider who performs the work,
an Evaluator - a designated third party who decides whether the work was completed.

The job moves through four states: Open → Funded → Submitted → Terminal. The client funds the budget into escrow. The provider submits a deliverable. Then the evaluator - and only the evaluator - attests that the job is complete (or rejects it), and the escrow releases accordingly. If the job expires, the client gets refunded.

This is a sensible design for a real class of problems. A lot of agent "commerce" is genuinely work-for-hire: do a task, produce a deliverable, get paid if it's acceptable. Acceptability is subjective, so you need someone to judge it. ERC-8183 makes that judge a first-class role and standardizes the lifecycle around it. BNBAgent SDK goes further and routes disputes through UMA's data-verification mechanism, adding an arbitration layer the base spec deliberately leaves out.

So far, so reasonable. The interesting part is the assumption baked into the shape of it: someone has to decide that the deal is done.

What atomic settlement removes

Now hold that model next to a hash-time-locked contract (HTLC), the primitive behind atomic cross-chain settlement.

In an HTLC swap, two parties each lock their side of the trade into a contract keyed to the hash of a secret. When the secret is revealed to claim one leg, that same secret mathematically unlocks the other leg. Either both legs settle, or - if the timeout passes without a reveal - both refund. There is no in-between state where one party is paid and the other is waiting.

The thing to notice: no one marks this trade "complete." There is no evaluator, no referee, no attestation step. "Complete" is not a verdict that a trusted party hands down. It's a consequence of the secret being revealed on-chain. The contract can't be talked into releasing funds early, and it can't be persuaded to withhold them. Completion is the cryptography.

That difference - judge vs. no judge - is the whole story, and it maps onto what kind of transaction you're doing:

	ERC-8183 escrow + evaluator	HTLC atomic settlement
Best fit	Subjective work-for-hire (was the task done well?)	Objective value-for-value swap (did asset A move for asset B?)
Who holds funds	Escrow contract, mid-job	No one holds the other side's funds at any point
Who decides "done"	Designated evaluator (third party)	Nobody - secret reveal settles or timeout refunds
Trust assumption	Evaluator is honest/available	Hash function + timeout logic
Failure mode	Evaluator is wrong, captured, or offline	Timeout risk; capital locked during the window

Neither column is "better" in the abstract. They answer different questions. If the deal is "I'll pay you to write me a report and someone has to judge the report," you want an evaluator. If the deal is "I'll give you X if you give me Y, simultaneously, no take-backs," you don't want a judge anywhere near it - a judge is just a new party who can fail, get captured, or go offline while your funds sit in escrow.

Why this matters for the agent economy

Most of the agent-payment infrastructure shipping right now - escrow protocols, payment facilitators, custodial settlement rails - is converging on a model where something in the middle holds funds and someone signals release. That's the right shape for merchant payments and for work-for-hire. It is the wrong shape for two agents swapping assets across chains, because it reintroduces exactly the counterparty and custody risk that on-chain settlement was supposed to delete.

The honest framing isn't "escrow bad, atomic good." It's: escrow holds, atomic settles, and an agent trading value-for-value with a stranger doesn't need a referee in the loop to do it. When an AI agent trades with another agent it has never met, the question that actually matters is not "who decides this is complete?" - it's "can this complete without anyone deciding?" For a clean asset swap, it can.

Where this is real today, and where it isn't

Being precise about claims is part of the point here, so: Hashlock's atomic settlement is live end-to-end on Ethereum mainnet. Sui contracts are deployed and CLI-tested with gateway wiring in progress; Bitcoin is signet-validated with mainnet still pending. The MCP server exposes six tools that let an agent run sealed-bid RFQ price discovery and HTLC settlement directly - no bridge, no custodian, no evaluator. Same discipline I'd ask of any protocol: testnet is not mainnet, and "deployed" is not "live."

If you want the mechanics, the protocol is on the web at hashlock.markets, the MCP package is hashlock-tech/mcp (scoped) on npm, and the academic write-up of the design is on SSRN.

The open question

Both models are going to ship, and both will find their users. The interesting fork is which one becomes the default mental model for "agent commerce." If the default is "post a job, fund escrow, wait for the evaluator," we've rebuilt the gig economy on-chain with a judge in every transaction. If the default for value-for-value swaps is "lock, reveal, settle - or refund," we've actually removed the middleman instead of renaming it.

When two of your agents trade value-for-value across chains, do you want a third party deciding it's complete - or do you want it to just clear with no one in the middle? Curious where people land on this.

Who gets to decide what the agentic economy becomes?

Baris Sozen — Mon, 29 Jun 2026 06:07:37 +0000

This isn't an explainer. It's a proposal, and an invitation.

Here is the thing almost nobody says out loud: the agentic economy is not a future event we are waiting for. It is being designed right now, in ordinary engineering decisions that almost no one is voting on. When one company decides how an AI agent proves it's allowed to spend money, that's a constitutional decision. When another decides whether two agents need a custodian in the middle to trade, that's a constitutional decision. When a third decides that "identity" means one mandatory gate everyone passes through, that's a constitutional decision too. None of them feel like that in the moment. They feel like Tuesday.

The defaults being set this quarter — how agents pay each other, who holds the assets while a deal settles, what counts as identity, who is allowed to participate — will be very hard to unset. Defaults calcify. The first answer that ships and works becomes the answer everyone integrates against, and ten years later it's just "how it works," and no one remembers it was a choice.

Why this can't only be a boardroom decision

Large institutions are good at a specific thing: shipping a working default fast and getting everyone to adopt it. That's genuinely valuable. It's also exactly why the early defaults tend to encode their assumptions — that there must be an intermediary, that the intermediary should be them, that trust is a gate you own rather than a property the system can guarantee. Not because anyone is a villain. Because that's the shape of the world they already live in, and people build what they know.

The problem is that "how machines transact with each other" is too important to inherit by accident from whoever shipped first. It touches who can participate in the economy, what a small player is allowed to do without permission, and whether the rails are open or rented. Those are public questions wearing an infrastructure costume.

So the future is being shaped now — fine. The question is whether we shape it, in the open, or whether we wake up to a set of defaults we never got to argue with.

The proposal

We're building in this space — an open settlement layer where agents trade asset-for-asset without a custodian in the middle (Ethereum mainnet live end-to-end; Sui contracts deployed and CLI-tested; Bitcoin signet-validated). But this post is deliberately not about our stack, because a manifesto that's secretly a product pitch isn't a manifesto.

The proposal is smaller and bigger than a product: let's make the design arguments in public, on the record, where anyone can join — not in private roadmaps.

Concretely, I want to use this thread as one of those rooms. Below are the open questions I think the agentic economy is quietly answering for us. I have opinions on all of them. I'd rather hear yours.

Custody. When two agents settle a trade, does anyone need to hold both sides in the middle — or can the contract itself be the only thing you trust? When is an intermediary actually doing necessary work, and when is it just collecting rent on a problem cryptography already solved?
Identity. Is identity a single gate everyone passes through, or a dial you turn up only when the situation needs it? Should a $40 swap between two bots require the same proof as a regulated million-dollar flow?
Participation. Who is allowed to execute, route, and earn in this economy? Is it permissionless by default with higher tiers for special cases, or permissioned by default with exceptions?
Incentives. In a network with no custodian collecting fees, what pays the agents who actually do the work of clearing trades — and how do you fund that without quietly reinventing the middleman?
The one nobody's naming. What's the constitutional decision being made right now that isn't on this list, because everyone's treating it as settled when it isn't?

What I'm actually asking you to do

Not "leave a comment." Propose something. Pick one of those questions — or better, the one I missed — and put your answer on the record. Disagree with me. Steal the framing for your own post and link it back. Tell me which default you think is already quietly winning and why that's good or bad.

If a few dozen people who actually build this stuff argue these out in public, that's already more open deliberation than most of these decisions are getting. That's the whole idea: not a community we own, a conversation no single institution owns. The comments are the room. Bring an argument.

The future of how machines handle money is being written in defaults this year. Let's at least make sure some of them were argued over in daylight.

Where we keep our own working notes and on-chain accounting, if you want to see one team's attempt: https://hashlock.markets/methodology?utm_source=devto&utm_medium=article&utm_campaign=2026-06-29-agentic-economy-manifesto — and the longer-form argument behind our approach is on SSRN: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722

Your move. Which one of these do we have wrong?

Can an AI agent post Bitcoin as collateral without giving up the keys?

Baris Sozen — Fri, 26 Jun 2026 11:19:20 +0000

This is the Friday product note - less about the mechanism in isolation, more about the decision an agent actually faces.

All week the argument in the agent-economy timeline was about settlement: when two agents strike a trade, does it complete through a custodian holding both sides, or atomically with no one holding either? Collateral is where that argument stops being abstract. The moment an agent has to post something to back an obligation - a forward to deliver, a loan to repay, a leg in a multi-step trade - it has to answer a very specific question: after I post this, who can move it?

For Bitcoin, the usual answer is "someone other than your agent." That is worth slowing down on.

The easy path quietly re-custodies your collateral

Bitcoin is the deepest collateral asset in crypto, and the obvious thing to want is to post native BTC. The problem is that Bitcoin the chain cannot run the contract logic a collateralized position needs - no expressive contracts, no objects, no state machine watching the position over time. So the collateral has to be usable on a chain that can reason about it, while the BTC lives on a chain that can't.

The standard fix is to wrap it: hand the real Bitcoin to a custodian, federation, or bridge contract, and receive a token on the destination chain. Now your agent can use that token as collateral anywhere that chain's contracts run.

It has also, without meaning to, done three things:

Converted a bearer asset into a claim against an intermediary.
Contributed to a honeypot - the locked BTC pile behind every wrapped token is a single standing target.
Made its collateral's integrity depend on something it has no good way to audit: the ongoing solvency and honesty of whoever holds the real coins.

This is the same trap the week's settlement debate kept circling. You can remove the custodian from the trade and still let one walk back in at the collateral - and an agent that can't tell the difference is exactly the agent that gets hurt by it. A trustless settlement layer that sits on custodial collateral isn't trustless; it has just moved the trust somewhere the agent stopped looking.

The product: post the Bitcoin, keep the Bitcoin

A collateral vault takes the opposite trade. The BTC never leaves Bitcoin and is never represented by a minted token. It stays as native BTC, locked in a script on the Bitcoin chain. What crosses chains is one piece of information - the hash of a secret - not the asset.

From the agent's side, the shape is simple enough to reason about as a few tool calls rather than a pile of cross-chain plumbing:

The collateral is locked into a P2WSH output on Bitcoin whose redeem script is a hash-time-lock: a hashlock path spendable by revealing a preimage, and a timelock path spendable by the depositor after a block-height deadline.
The obligation it backs lives on Sui, where our Move contracts are deployed. That contract is written so the outcome of the obligation controls who learns the preimage, and when.
Bitcoin Script can't read Sui state and Sui can't read Bitcoin's UTXO set, but both can agree in advance on one hash. The preimage of that hash is the single key that resolves the position on both chains at once.

A vault has exactly three ways to end, and all three are mechanical:

Perform. The obligor delivers - reveal-to-claim publishes the secret, and the BTC settles to whoever the performance entitles.
Default. The hashlock path routes the BTC to the counterparty as the agreed remedy. No chasing anyone through courts or reputation.
Silence. If the position is abandoned, the timelock returns the BTC to the depositor after the deadline - enforced by Bitcoin consensus, not by anyone's cooperation.

In every path the BTC was native Bitcoin the whole time, and no third party ever had the unilateral ability to move it. That is the entire product claim, and it is a narrow, checkable one.

What it deliberately is not

A vault is not a margin account, and pretending otherwise would be the easy oversell. Bitcoin Script has no price feed, so a vault cannot do a continuous margin call - it resolves on performance, default, or a deadline, not on a price crossing a threshold. For discrete obligations (a forward with a fixed date, a fixed-term loan, a bonded commitment) that's fine, because the obligation is discrete too. For a position that genuinely needs real-time mark-to-market, this is the wrong tool, and we'd rather say so than smuggle an oracle into the design.

The honest status, stated plainly

Because this is a product note and not a launch, the status report matters more than the pitch:

The Bitcoin P2WSH HTLC is validated on signet - Bitcoin's test network - with mainnet pending.
The Sui contracts are deployed and CLI-tested, with gateway wiring in progress.
The only place atomic settlement is live end-to-end today is Ethereum mainnet.

So a BTC collateral vault is a design we're building toward, exposed through our MCP server (hashlock-tech/mcp, scoped - six tools) so an agent reasons about the position instead of the script-level mechanics. MCP is the open protocol Anthropic introduced for connecting models to external systems; a vault is just another set of tool calls on that surface. But it is not a button you can press this morning, and the npm package is at a 0.4.x patch line - no new version to announce. The coarse part of the tradeoff is real, too: Bitcoin's ~10-minute blocks make timeout windows coarse, the cross-chain deadlines have to be conservative by construction, and collateral sits locked and idle for the life of the position. Those are the costs of deleting the custodian. We think they're worth paying for the class of positions a vault is built for. They are still costs.

The question

Wrapped BTC made Bitcoin usable everywhere by making it custodial everywhere. The bet behind a collateral vault is that an agent can keep most of that usefulness - Bitcoin backing an obligation on a chain that can actually reason about it - without the custodian, by moving a hash instead of the coins.

So, for anyone building agent-side collateral logic: when your agent posts Bitcoin as collateral, do you actually know who can move those coins? If the honest answer is anything other than "only the agent, and only along paths it agreed to in advance," what is that trust buying you?

Hashlock Markets - atomic settlement for the agent economy. Sealed-bid RFQ + HTLC settlement, fused into one operation. No bridges, no custodians.

Protocol: https://hashlock.markets/?utm_source=devto&utm_medium=referral&utm_campaign=2026-06-26-btc-collateral-vaults
MCP server (source): https://github.com/Hashlock-Tech/hashlock-mcp
The underlying mechanism design is written up in a working paper on SSRN: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722

Escrow or atomic: which settlement model does the agent economy actually standardize on?

Baris Sozen — Thu, 25 Jun 2026 07:19:51 +0000

If you've watched the agent-payments space over the last few months, you've seen two settlement models harden into place, and they are not the same thing wearing different names. One is custodial escrow with dispute resolution. The other is trustless atomic settlement. Most of the noise treats them as interchangeable "settlement layers." They aren't. They solve different problems, they fail in different ways, and they cost different things. This post is an attempt to lay the tradeoffs out honestly - including where atomic settlement is the worse choice - so you can reason about which one ends up underneath autonomous agents.

Two models, stated plainly

Escrow + dispute resolution. A trusted party (or a contract acting as one) takes custody of one or both legs of a trade, holds them, and releases according to rules. If something goes wrong, an arbiter adjudicates. This is the model most agent payment rails are converging on, and it's the model a major exchange shipped recently in its agent payments protocol: quote → negotiate → escrow → settle → dispute.

Atomic settlement. No one takes custody. Both legs are locked against a shared cryptographic secret. Revealing the secret clears both legs simultaneously; if the secret is never revealed, a timeout refunds both sides. The canonical primitive here is the hashed timelock contract (HTLC): funds are locked behind hashlock = H(secret) plus a timelock, and the only two terminal states are "both legs settled" or "both legs refunded."

The one-sentence difference: escrow asks you to trust that the holder behaves; atomic settlement removes the holder.

What escrow gets right (the honest case for it)

It would be dishonest to wave escrow away. It has real advantages, and pretending otherwise is how you lose technical readers:

It ships today and it's legible. Escrow maps onto how commerce already works. Product, ops, and legal teams understand "funds held, then released."
No liveness assumption on the counterparty. Atomic swaps need both parties (or their agents) to be online to complete the reveal within the timeout window. Escrow doesn't - the custodian is the always-on party.
No capital locked waiting on a secret. In an HTLC, your funds sit locked for the duration of the timeout. That's an opportunity cost, and for high-frequency agent flows it's a real one.
A human can intervene. When a trade is genuinely ambiguous - wrong item, fraud, a bug - an arbiter can untangle it. Pure atomicity has no "undo."

If you're optimizing for time-to-market and human-recoverable failure modes, escrow is a reasonable answer.

What escrow can't do

Here's the structural limit. Escrow answers exactly one question: "will my money be held safely?" It never answers the other one: "who am I actually trading with?" A custodian can hold funds flawlessly and still release them to a counterparty that misrepresented itself. Custody integrity and counterparty integrity are different problems, and escrow only touches the first.

And escrow reintroduces the precise thing autonomous agents were supposed to eliminate: a trusted middle. A middle that can be hacked, frozen, subpoenaed, or simply go offline. Every "escrow agent" is a honeypot proportional to the value flowing through it. The more the agent economy scales, the larger that honeypot grows. Dispute resolution is downstream evidence of this: if settlement were atomic, there would be nothing to escrow and nothing to dispute, because both legs clear or neither does.

What atomic settlement costs (the honest case against it)

Atomic settlement is not free, and anyone selling it as a no-tradeoff upgrade is overselling:

Capital lockup. Funds are immobilized for the timeout window. Choose timeouts too long and capital efficiency suffers; too short and you risk failed swaps under congestion.
Liveness. Both sides must act within the window. For agents this is usually fine (they're always-on by design), but it's a real assumption, not a free lunch.
Timeout and griefing surface. A counterparty can lock a swap and walk, costing you the lockup window even though you get refunded. Mitigations exist (collateral, reputation), but they add design weight.
Operational complexity. Secret management, cross-chain timeout coordination, and refund paths are more moving parts than "send to escrow."

The honest framing is a risk swap, not a strict dominance: atomic settlement removes custody risk and counterparty-release risk, and in exchange takes on lockup cost and a liveness assumption.

Why the "who are you?" gap is the deciding factor

Notice that escrow's blind spot - counterparty identity - is also atomic settlement's blind spot if you stop at the HTLC. Atomicity guarantees the mechanics are honest (the swap can't be half-completed), but it doesn't tell an agent whether the address on the other side is who it claims to be.

That's why the interesting design isn't "HTLC vs escrow" in isolation. It's atomic settlement composed with a verified counterparty layer: the math removes the custodian and the trade only proceeds against a counterparty whose identity/reputation is attestable. Now both questions are answered - "is my money safe?" by the atomicity, and "who am I trading with?" by the directory - without anyone holding the funds. Identity/reputation registries like ERC-8004 are complementary infrastructure here, not competitors.

So which one wins?

I'm not going to pretend this is settled. Escrow has momentum, distribution, and the easier integration story. Atomic settlement has the cleaner trust model and no honeypot, but it asks builders to absorb lockup and liveness costs.

My structural bet is that escrow is the placeholder and atomic settlement is the destination - because the value flowing through agent-to-agent trade makes every custodial honeypot a growing liability, and the marginal cost of trust-minimization keeps falling as tooling matures. But that's a bet, and the strongest counterargument - "convenience always wins at scale, and a good-enough custodian beats a perfect protocol nobody integrates" - deserves a real answer, not a dismissal.

Where we stand on the building side: Hashlock's atomic settlement is live end-to-end on Ethereum mainnet, exposed to agents through an MCP server with six tools (create_rfq, respond_rfq, create_htlc, withdraw_htlc, refund_htlc, get_htlc). The MCP server is on npm as @hashlock-tech/mcp. We've written up the longer argument and the academic grounding below.

Site: https://hashlock.markets/?utm_source=devto&utm_medium=article&utm_campaign=2026-06-25-escrow-or-atomic
GitHub: https://github.com/Hashlock-Tech/hashlock-mcp
Whitepaper (SSRN): https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722

One honest question to close on: for autonomous agents specifically, does the always-on, no-human-in-the-loop nature of agents make the liveness cost of atomic settlement basically free - and if so, does that tip the whole tradeoff? What's the strongest case for escrow staying the default? I'd genuinely like to be argued out of my bet.

Escrow is not a settlement layer: reading OKX's Agent Payments Protocol

Baris Sozen — Wed, 24 Jun 2026 06:08:12 +0000

A major exchange just published an Agent Payments Protocol: an open standard for AI agents to quote, negotiate, escrow, settle, and resolve disputes, with the Ethereum Foundation, Uniswap, Solana, Sui, and Paxos among its launch partners. If you have been arguing that settlement is the real prize in the agent economy, this is the loudest confirmation yet. When a top-five exchange races to own the layer underneath agent commerce, the thesis is no longer contrarian.

So this post is not a takedown. It is a map. The interesting question is not whether settlement matters - that is now settled - but what kind of settlement the agent economy actually needs, and which parts of the new protocol are genuine progress versus a familiar trust model wearing new words.

Read the feature list literally

Quote, negotiate, escrow, settle, dispute. Four of those five are unambiguous wins for autonomous commerce. The fifth - dispute resolution - is the tell.

Think about what a dispute is. It is a state where the two parties disagree about what should happen to the money, and a third party has to decide. The protocol needs a dispute mechanism precisely because, at the moment of settlement, the funds are sitting somewhere held by someone, under conditions that can be contested. That is escrow: a trusted middle holds value until conditions clear, and an arbiter adjudicates when they do not.

Escrow is a real improvement over the default agent payment pattern, which is closer to "send the money and trust the other side to deliver." Escrow at least removes the naive version of counterparty risk. But it does so by adding a custodian and an arbitration process, not by removing the need for trust. The trusted middle is still there. You have moved the risk, not eliminated it.

Here is the contrast in one line: if settlement were atomic, there would be nothing to escrow and nothing to dispute.

What atomic settlement actually means

A payment asks one question: did the money move? A trade asks a harder one: did both sides happen, or neither? The risk in any trade lives in the gap between the two legs - the window where one party has performed and the other has not.

A hash-time-locked contract (HTLC) closes that gap with cryptography instead of an intermediary. The mechanism, stripped down:

Two parties agree on a trade. One generates a secret and publishes its hash.
Each party locks their funds in a contract on their respective chain, redeemable only by revealing the preimage of that hash, and only before a timeout.
Revealing the secret to claim one leg mathematically exposes it for the other leg. So either both legs clear on the same secret, or neither does.
If anyone stalls, the timeouts expire and both sides are refunded.

There is no point in this flow where one party holds both legs, and no point where a third party holds either. There is nothing to escrow because the contract itself enforces the swap. There is nothing to dispute because the outcome is binary and determined by whether a secret was revealed in time - not by anyone's judgment.

This is not magic, and it is not free. Honest tradeoffs: capital is locked for the duration of the timeout window; there is a liveness requirement (a counterparty who vanishes makes you wait out the timeout before you recover funds); timeout ordering has to be correct, or you hand the claiming party a free option; and cross-chain swaps require compatible hashing between the two chains. These are real engineering constraints. But none of them is a trust constraint. You are trading custody risk for capital-efficiency and liveness costs - a very different bargain.

The question escrow structurally cannot answer

There is a second gap, and escrow does not touch it.

Escrow answers "will my money be held safely until conditions clear?" It never answers "who am I actually trading with?" An escrow agent can hold funds flawlessly and still release them to a counterparty that turns out to be a Sybil, a drained shell, or an agent impersonating a reputable one. Holding the money correctly and routing it to the right party are two different problems. Custody solves the first. It is silent on the second.

For human-mediated commerce this is usually handled out of band: a person vetted the counterparty before the agent ever ran. That does not generalize to the whole promise of autonomous agents, which is transacting with parties no human pre-approved.

The settlement-layer answer is to make counterparty identity a first-class, verifiable property rather than an assumption. A verified counterparty directory lets an agent check who is on the other side before it commits funds - and atomic settlement guarantees that once it does commit, the trade either completes against that party or unwinds entirely. The two compose: identity answers "who," atomicity answers "did both sides happen." Escrow, on its own, answers neither cleanly.

Where this leaves the map

Stack the recent launches and a pattern appears. Payment rails (x402, AP2) move value one direction. Payment facilitators bolt escrow and dispute resolution on top so a stranger cannot simply run off with it. Each layer adds a trusted middle to compensate for the fact that the layer below could not settle two-sided value on its own.

Trustless atomic settlement sits underneath all of them. It is complementary, not competitive - the rails decide what and when; atomic settlement decides whether both sides actually happened, with no one holding the money in between. A major exchange shipping escrow is the strongest signal so far that this layer is worth owning. It is also a reminder of what escrow leaves on the table.

For the record on where the implementation actually is: this is live end-to-end on Ethereum mainnet today. Sui contracts are deployed and CLI-tested with gateway wiring in progress, and Bitcoin is signet-validated with mainnet pending. The MCP server exposes the whole flow - quoting, locking, claiming, refunding - as six tools an agent can call directly.

If you want the mechanism in depth: the protocol is at hashlock.markets, the MCP package is hashlock-tech/mcp (scoped) on npm and GitHub, and the design rationale is written up in the SSRN whitepaper.

When a major exchange calls escrow-plus-arbitration a "settlement layer," is that the destination - or the placeholder until trustless settlement ships underneath it? What would it take to move your agents off escrow?

AI agents already settle millions a month - almost none of it atomically

Baris Sozen — Tue, 23 Jun 2026 12:35:37 +0000

Here is a number that should reframe how you think about the agent economy: in roughly one year, AI agents moved about $73M across 176 million machine-to-machine transactions on a single exchange, at an average of around $0.31 per transaction, across 100k+ registered agents.

Read that again. Agents are not "coming." They are already transacting, at scale, in production, right now. The interesting question is no longer whether autonomous software moves money. It is what those transactions are trusting - and what happens the first time that trust is misplaced.

Payments scaled. Settlement did not.

Almost all of that volume runs on payment rails. A payment rail does one job, and does it well: it moves a unit of value in one direction. Agent pays a service. Agent tips an API. Agent settles a micro-invoice. At thirty-one cents a pop, the failure modes are invisible - if a transaction goes wrong, you are out pocket change, and you move on.

The problem is that a payment and a trade are not the same operation.

A payment asks one question: did the money move?

A trade asks a harder one: did **both* sides happen - or neither?*

When your agent pays for something, there is one transfer and one direction of risk. When your agent trades - my asset for yours, your stablecoin for my token, one chain's value for another's - there are now two transfers that must both complete, or both not. The risk lives in the gap between them. One side sends; the other side is supposed to send back. On a payment rail, "supposed to" is doing an enormous amount of load-bearing work.

The hidden assumption

Every one of those 176 million transactions made an assumption that nobody had to state out loud: the counterparty will deliver. Between parties who already trust each other - a company and its own agents, two services under one operator - that assumption is fine. It holds because the trust was established off-chain, by humans, before the agent ever ran.

But the entire promise of the agent economy is the opposite of that. It is agents transacting with counterparties they have never met and have no reason to trust. Strangers. The moment you remove the pre-existing relationship, "the other side will deliver" stops being a safe default and becomes an open position. You are extending credit, or trusting a custodian to hold both sides, or hoping a bridge validator set behaves. At $0.31, nobody audits that. At scale, with real size, with adversarial counterparties, someone eventually doesn't pay - and the rail has no answer, because settling atomically was never its job.

What atomic settlement actually means

"Atomic" is not a marketing adjective here. It is a precise property: an operation either completes entirely or has no effect at all. There is no intermediate state where one party holds both legs.

The mechanism that delivers this for cross-party value exchange is the hash time-locked contract (HTLC). Stripped to its essentials:

Two parties agree on a trade and a shared hash. One party knows the secret (the preimage); the other only knows the hash.
Both parties lock their funds into contracts that say: "release to whoever reveals the preimage before the timeout; otherwise refund the original owner."
When the secret is revealed to claim one leg, that same revelation makes the other leg claimable. Both legs clear from a single act.
If either side stalls, the timeout fires and everyone is refunded. No fund is ever stranded.

No custodian holds the money. No bridge operator signs off. No API key sits in memory waiting to be leaked. The contract itself is the escrow, and the only thing being trusted is math: a hash preimage that either exists and clears both sides, or doesn't and refunds both. That is the entire point of the primitive. Your money never leaves your wallet until theirs arrives.

The honest tradeoffs

Anyone who tells you atomic settlement is free is selling something. The real costs:

Capital lockup. Your funds are locked for the duration of the timeout window. That is a genuine opportunity cost, and it is the price of removing the counterparty assumption.
Liveness requirement. If a counterparty vanishes mid-swap, you do not lose funds - but you do have to wait out the timeout to get your refund.
Timeout ordering. The party that reveals the secret has an information advantage; if the two timeouts are set in the wrong order, you can hand the claiming party a free option. Getting this right is the non-negotiable part of the engineering.
Hash compatibility. Cross-chain swaps need a hash function both chains support (SHA-256 vs Keccak), which constrains which pairs settle natively.

These are real, and they are the reason atomic settlement is not the right tool for every transaction. For a thirty-one-cent payment to a trusted service, a payment rail is correct - the overhead is not worth it. But for a two-sided trade with a counterparty you cannot vouch for, those tradeoffs are exactly what you want to pay for. They are the cost of not needing to trust the other side.

Why this matters now, not later

The temptation is to file this under "future problem." The $73M number is the argument against that. The volume is already here. The rails are already carrying it. The only reason the trust gap hasn't bitten hard yet is that the average transaction is too small to bother attacking and the counterparties are mostly still trusted by relationship rather than by protocol.

Both of those conditions are temporary. Transaction sizes are going up. The counterparty graph is getting wider and more anonymous. Somewhere on that curve, "almost none of it settled atomically" flips from a footnote to an incident. The teams that have a settlement answer before that point will not have to retrofit one after it.

If you are building agents that will eventually trade with someone their operator never met, the trust model of your settlement layer is not a detail to defer. It is a property you should be able to state out loud today.

Where to dig in

How we measure and define settlement volume: hashlock.markets/methodology
The MCP server and tools (six of them) so an agent can request quotes and settle atomically: github.com/Hashlock-Tech/hashlock-mcp
The protocol itself: hashlock.markets (sealed-bid RFQ + HTLC atomic settlement, live end-to-end on Ethereum mainnet; Sui contracts deployed and CLI-tested; Bitcoin signet-validated with mainnet pending)
The academic foundation, if you want the formal version: SSRN whitepaper

Question for the comments: the agent economy already settles millions a month. When do you think the first real trust-failure forces the switch from "assume the counterparty pays" to "settle so it doesn't matter" - and what's actually holding that switch back today?

What does your AI agent actually trust when it trades through a CEX?

Baris Sozen — Mon, 22 Jun 2026 13:12:53 +0000

A wave of "AI agents can now trade" tooling shipped this quarter. Kraken put out a CLI described as a crypto trading tool for AI agents. Alpaca shipped an MCP server. deBridge, Bybit, and others expose their functionality to agents the same way. The interfaces are genuinely good — clean, well-documented, and easy for an autonomous agent to call.

But "an agent can call it" and "an agent can rely on it" are different claims. When an agent fires a trade through one of these tools, it isn't just sending a request. It's accepting a trust model. And that trust model is usually invisible in the tool's README.

This post is a mechanism-level diff: what a custodial exchange tool requires you to trust, versus what hash-time-locked (HTLC) atomic settlement requires. No marketing — just where the trust sits in each design, including the honest costs of the trustless path.

What a custodial CEX tool asks an agent to trust

Wrap a centralized exchange in a CLI or an MCP server and you get a great developer surface on top of an unchanged settlement model. Three trust assumptions come along for free:

1. Custody. The exchange holds the assets, not the agent. The agent's "balance" is a database row the exchange controls. Trades are internal ledger updates. This is fast and cheap — until withdrawal time, when the database row has to become a real on-chain transfer. Everything between deposit and withdrawal is the exchange's promise.

2. API key authority. An agent trading programmatically holds an API key. That key is a bearer credential to act on the account. The blast radius of a leak is the whole permission scope of the key — and agents leak secrets in ways humans don't: logs, prompt context, tool-call traces, misconfigured environments. You can scope keys (no-withdrawal, IP allowlists), and you should, but you're narrowing the blast radius, not removing the bearer-credential model.

3. Solvency. The deepest one. Internal balances are only as good as the exchange's ability to honor withdrawals. That assumption has failed publicly and repeatedly. An agent reading a healthy balance has no on-chain way to verify the assets backing it actually exist and are unencumbered.

None of these are bugs in the CLI or the MCP server. They're properties of routing settlement through a custodian. The tooling modernized the interface. The counterparty risk is the same one human traders have carried for a decade.

This matters more for agents than for humans because the whole point of an autonomous agent is acting without a human in the loop for each decision. A human notices a withdrawal freeze and a paused exchange. An agent keeps trading against numbers that may no longer be real.

What HTLC atomic settlement asks an agent to trust

A hash-time-lock contract takes a different position: don't trust a balance sheet, trust a cryptographic primitive and a timeout. The mechanism:

Agent A picks a secret s and computes h = hash(s).
Agent A locks funds in a contract that releases to Agent B only on presentation of a preimage matching h, with a refund to A after timeout T_A.
Agent B locks the matching side, releasing to A on the same h, with a refund to B after a shorter timeout T_B < T_A.
A claims B's funds by revealing s. That revelation is public, so B uses the same s to claim A's funds.
If anything stalls, both sides refund after their timeouts. No partial state where one leg clears and the other doesn't.

The trust diff is the point. There is no custodian holding funds mid-trade — the contract is the escrow. There is no bearer API key whose leak drains an account — claiming requires the preimage, and the refund path is time-bounded and unconditional. There is no solvency assumption — the assets are locked on-chain in the contract, visible and verifiable, not sitting in an exchange's books.

The honest tradeoffs

HTLCs are not free, and pretending otherwise is exactly the marketing this post is trying to avoid:

Capital lockup. Funds are locked for the duration of the swap. A custodial internal transfer is instant; an atomic swap costs you the timeout window.
Timeout risk and the free-option problem. Parameters have to be chosen so the claiming party can't reveal late and grief the counterparty. Get T_A and T_B ordering wrong and you create an exploitable asymmetry.
Liveness requirement. A party that locks funds and disappears forces the counterparty to wait out the timeout for a refund. Atomicity guarantees you don't lose funds; it doesn't guarantee speed.
Hash and chain assumptions. Cross-chain HTLCs depend on compatible hash functions across both chains and on each chain's finality. SHA-256 vs Keccak choices matter for compatibility.

So the diff isn't "custodial bad, trustless good." It's a different bill. A CEX tool charges you counterparty risk in exchange for instant internal settlement and no capital lockup. HTLC settlement charges you capital lockup and timeout latency in exchange for removing the custodian, the bearer key, and the solvency bet.

Why the agent case tips the scales

For a human doing occasional trades on an exchange they've used for years, the custodial bill is often fine. For an autonomous agent transacting with counterparties it has never met, at machine speed, without a human watching each trade, the calculus shifts. The failure mode of custodial trust is silent: the numbers look right until they don't. The failure mode of HTLC settlement is loud and bounded: worst case, you wait out a timeout and get your funds back.

That's the design bet behind building settlement as a native protocol rather than a wrapper. Hashlock exposes HTLC atomic settlement through an MCP server with 6 tools — create_htlc, get_htlc, withdraw_htlc, refund_htlc, swap_quote, swap_execute — so an agent calls it with the same ergonomics as a CEX tool, but inherits a different trust model underneath. Settlement is live end-to-end on Ethereum mainnet; Sui contracts are deployed and CLI-tested, and the Bitcoin path is signet-validated with mainnet pending.

The interface convergence is real — everything is becoming an MCP tool an agent can call. The question that doesn't go away is what sits behind the call.

So here's the one I'd put to anyone building agent trading infra: for a fully autonomous agent, is custodial counterparty risk an acceptable cost for instant settlement — or is the capital-lockup price of atomicity the one worth paying? Where's your line?

Code and docs: https://github.com/Hashlock-Tech/hashlock-mcp · https://hashlock.markets/docs?utm_source=devto&utm_medium=article&utm_campaign=2026-06-22-cex-vs-native
The trust-model argument in full (SSRN whitepaper): https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722