DEV Community: Baris Sozen

Institutions just ran live cross-chain HTLC swaps. The 'clunky' primitive is quietly winning.

Baris Sozen — Mon, 27 Jul 2026 06:09:20 +0000

On July 23, Arqitech announced something that would have sounded implausible three years ago: multiple live, non-custodial, cross-chain atomic swaps executed on Canton MainNet between four institutions - Arqitech, MPCH, Pixelplex and sFOX - each exchanging Canton Coin for USDC, and each retaining full control of its own private keys the entire time.

The primitive underneath: a full-featured HTLC. The hash-time-locked contract. The mechanism that was supposed to have lost to bridges years ago because it was "too clunky for real trading."

Canton is not a degen chain. It is the network built for regulated finance, the one where work on DTC and Fed-eligible securities lives. When that room picks a settlement primitive, it is telling you something about where the risk analysis landed.

A 60-second HTLC refresher

An HTLC locks funds behind two conditions: a hashlock and a timelock. Alice locks asset A on chain 1, spendable by whoever reveals the preimage of hash H. Bob, seeing that lock, locks asset B on chain 2 behind the same H, with a shorter timelock. Alice claims B by revealing the preimage; that reveal is public, so Bob uses it to claim A. If anyone walks away mid-flow, the timelocks expire and both sides refund.

The property you get is atomicity: both legs complete or both refund. No custodian, no wrapped assets, no bridge validator set holding a nine-figure honeypot. The property you pay for is coordination overhead - and that overhead is exactly what the interesting engineering in this announcement attacks.

Two design details worth stealing

1. Cooperative unwind. The classic HTLC pain point: if your counterparty goes dark after funding, your capital is stuck until the refund timelock expires. Hours, sometimes longer, of dead capital - and desks price that risk into every quote. Arqitech's protocol lets both parties cooperatively cancel an in-flight swap immediately instead of waiting out the clock. It only works when both sides are still responsive, but that covers the most common abort case: not malice, just a trade that both sides agree to call off. The adversarial case still falls back to the timelock, which is the correct layering - optimistic fast path, trustless slow path.

2. Tranche streaming. Instead of locking the full notional in one atomic swap, the protocol executes a large trade as a stream of smaller atomic tranches. Less liquidity locked at any instant, smaller worst-case exposure per tranche, and lower capital requirements for the quoting side.

The tradeoff is real, and it is worth being precise about: a tranche stream is not one atomic trade. Each tranche is atomic, but the stream can halt partway, leaving you partially filled while the market moves. That is a different guarantee from multi-leg atomicity, where several legs - potentially across chains and counterparties - either all complete or all refund as a unit. Streams optimize capital efficiency; multi-leg atomicity optimizes exposure guarantees. Which one you want depends on whether a partial fill is an inconvenience or a broken position. For a desk managing inventory, streams are usually fine. For an autonomous agent executing a three-leg rebalance where leg 2 without leg 3 means unhedged risk, all-or-nothing is the point. That distinction is why multi-leg trade atomicity is one of the five primitives we consider non-negotiable for agent settlement.

What this validates

For years the standard dismissal of HTLC-based settlement was that it is an academic curiosity: elegant on paper, too slow and awkward for real flow, destined to lose to bridges and custodial settlement networks.

Then bridges lost billions of dollars to validator-set and signature exploits, and custodial settlement kept requiring that both sides trust an intermediary with custody during the window. Now the most conservative participants in the market are executing swaps where no one - not even for a second - holds the other side's assets. Self-held keys, trustless refund paths, atomic execution. Not as ideology. As risk management.

That is category validation, and we will take it. It is the same conclusion we published in our own research: sealed-bid quoting plus HTLC settlement gives you price discovery and delivery-versus-payment without a trusted middle. (The formal treatment is in our SSRN paper, if you want the model rather than the blog version.)

The part institutions get for free - and agents don't

Here is the difference between the institutional version of this primitive and the agent version, and it has nothing to do with cryptography.

An institutional HTLC swap is wrapped in a human operations layer. Counterparty discovery happens through relationships and onboarding. Quotes move over chat and RFQ desks. Someone's ops team watches the timelocks, notices the stuck swap, picks up the phone, agrees to the cooperative unwind. The protocol is trustless; the workflow is deeply human.

An AI agent has no relationships, no chat, no ops team, and no phone. Every one of those human touchpoints has to become a machine-callable interface, or the primitive is unusable no matter how sound the cryptography is. Discovery has to be an API. Quoting has to be sealed-bid and programmatic - an agent that leaks its intent to the market is an agent that gets front-run. Execution, monitoring and refund have to be tools the agent invokes directly, with the state machine legible to software.

That is the design brief behind Hashlock: the same settlement primitive institutions just validated, exposed as an MCP server with six tools an agent can call - request quotes via sealed-bid RFQ, respond, create the HTLC, monitor it, withdraw, refund. MCP because that is the interface layer the agent ecosystem is actually standardizing on. Status, stated precisely: Ethereum mainnet is live end-to-end today; Sui contracts are deployed and CLI-tested; Bitcoin is validated on signet with mainnet pending. Install surfaces: @hashlock-tech/mcp on npm (scoped) and, since this month's 0.4.0 release, pip install hashlock-sdk.

The honest gap in the other direction: institutions bring vetted counterparties and legal recourse to the table, and agent-land has to rebuild that from primitives - a verified counterparty directory and tiered KYC rather than a rolodex. We think that plus fee compression (a settlement layer at 1-2 bps against the 8-10 bps typical of OTC spreads) is what the agent version looks like when it is finished. But we would rather state the gap than pretend the rolodex does not matter.

The convergence question

Watch what just happened from one step back. Regulated institutions and autonomous agents - the two audiences with the least tolerance for counterparty risk, for completely different reasons - are converging on the same settlement primitive: hash-time locks, self-held keys, atomic execution, no custodian.

The institutional wrapper is a desk. The agent wrapper is a protocol server. The core is identical.

So here is the question I keep turning over, and I would like the counterargument: if the most risk-averse room in finance and the most automated corner of crypto both landed on trust-minimized atomic settlement, what is the remaining case for bridges and custodial settlement in the middle of the market? Where does that architecture still win? Tell me where this breaks.

Sources: Arqitech's announcement via GlobeNewswire. Our whitepaper on sealed-bid RFQ + HTLC settlement is on SSRN; code and docs at hashlock.markets.

Your AI agent can now pay for almost anything. Here's what it still can't settle.

Baris Sozen — Sat, 25 Jul 2026 10:14:24 +0000

Ten days, three launches. On July 14 the x402 Foundation went operational under the Linux Foundation with 40 member organizations, including Visa, Mastercard, American Express, Stripe, Google, AWS, and Coinbase. On July 23, Coinbase switched on x402 USDC payments for every Coinbase Business account. On July 24, Cloudflare shipped a Monetization Gateway that lets any origin charge paying agents for any resource.

PayPal made it safe to pay strangers online. This was the week AI agents got their PayPal moment.

It's also a good moment to be precise about what just got solved and what didn't. FAQ format, because these are the questions we keep getting.

What actually happened this week?

The x402 protocol activates HTTP 402 "Payment Required", a status code reserved but unused for three decades. A service replies 402 with payment instructions; the agent signs a stablecoin payment (USDC on Base today) and retries with proof of payment. No account, no API key, no card on file.

This week that stopped being an experiment. A neutral standards body now governs the protocol. Every Coinbase Business account can accept agent payments with no chargebacks. The new CDP x402 SDK adds payment acceptance to any API, MCP server, or web service in a few lines of code. And Cloudflare, which fronts a large share of the web, can now meter agent access at the edge.

One more signal: Coinbase reported that software-generated traffic exceeded human traffic on its Base documentation pages for the first time in June. The buyers are already machines.

What can my agent pay for now?

Per-request things: API calls, content access, compute, data. CoinDesk reported roughly 75 million x402 transactions over 30 days settling about $24 million. Average ticket: 32 cents.

That average is not a weakness. It's the design. x402 is a micropayment rail: it answers "how does an agent pay per request, without an account?" extremely well.

So what still can't it do?

Here is the question we care about: how do two agents exchange real value, across chains, when neither trusts the other?

A payment rail moves money one way, from a buyer to a merchant. A merchant with chargeback-free income is protected. But an asset-for-asset trade has two legs. If agent A sends 50,000 USDC on Ethereum and agent B is supposed to send BTC back, what enforces B's leg? A 32-cent HTTP payment flow was never designed to carry that risk, and it doesn't claim to.

That two-sided problem is settlement, and it's a different layer with a different primitive.

What does the settlement layer look like?

Hash-time-locked contracts (HTLCs). The flow, compressed:

Agent A locks funds on chain 1 under hash(secret), with a timeout.
Agent B locks the counter-asset on chain 2 under the same hash, with a shorter timeout.
A reveals the secret to claim B's funds - which publishes the secret on-chain.
B uses the revealed secret to claim A's funds. If anything stalls, both sides refund after timeout.

Either both legs complete or both refund. No bridge, no custodian, no honeypot in the middle. Your money never leaves your wallet until theirs arrives. The tradeoffs are real and worth naming: capital is locked during the window, timeout parameters need care, and both chains must support the same hash function. We've written about those tradeoffs before; the settlement leg is public, and you can read exactly how it works in the docs.

Are payment rails and settlement layers competing?

No - they stack. An agent might pay 32 cents over x402 to query a price feed, pay another few cents for a counterparty-discovery API, then settle the actual 50 ETH ↔ BTC trade atomically with an HTLC. Rails on top, settlement underneath. The x402 Foundation standardizing the top of the stack is good news for the bottom of it: it normalizes the idea that agents transact without humans in the loop.

What about trades with more than two legs?

Multi-leg atomicity extends the same primitive: chain several HTLC legs under one secret, and the whole route either completes or unwinds. That matters for agents doing triangular trades or splitting size across venues - partial execution is a risk class of its own.

Is anyone else validating the settlement side?

This week, yes, from an unexpected direction: Arqitech, with MPCH, Pixelplex, and sFOX, executed a non-custodial cross-chain HTLC atomic swap on Canton MainNet, aimed at TradFi institutions (announced July 23). Institutions and AI agents are converging on the same primitive for the same reason: neither wants to trust an intermediary with the middle of a trade.

For our part: Hashlock's sealed-bid RFQ + HTLC settlement is live end-to-end on Ethereum mainnet. Sui contracts are deployed and CLI-tested, and the Bitcoin flow is validated on signet - neither is live for settlement yet, and we won't call them live until they are. The MCP server exposes six tools for agents (npm: hashlock-tech/mcp, scoped), and the protocol design is written up on SSRN.

The question we're left with

The payments half of agent commerce got a standards body, a Fortune-500 member list, and edge deployment in ten days. The settlement half is where the counterparty risk actually lives.

So here's the open question, and we're interested in real answers: when your agent needs to exchange assets with a counterparty it has never seen before, what does it use today - a custodian, a bridge, or nothing because it can't? Tell us in the comments.

Brokers are racing to give AI agents a trading seat. Nobody is racing to give them settlement.

Baris Sozen — Thu, 23 Jul 2026 06:07:38 +0000

Three brokers have shipped three different answers to the same question in the space of a few weeks, and the differences are more revealing than the products.

IG connected its platform to AI agents over MCP, but read-only: the agent can analyze, it cannot touch. ThinkMarkets went further: its MCP server lets an agent execute trades, but, in the company's own words, the AI "can execute trades, but not access funds." Robinhood went all the way: agent trading on live brokerage accounts, with research, order execution, and portfolio rebalancing running through its MCP server. And the platform layer is following - MetaQuotes' new MetaTrader 5 beta (Build 6030, released July 16) adopts MCP as a native interface, so external agents can plug into charts, accounts, and execution workflows directly. Webull, Deriv, and eToro have MCP servers of their own. cTrader and TraderEvolution ship vendor-level agent infrastructure. Trade press now covers this as a race, and FINRA's 2026 Regulatory Oversight Report already flags agent-driven execution as something that needs governance frameworks.

Line these up and you get a spectrum: look-only, trade-but-never-withdraw, full autopilot. It is a real spectrum, and the industry is having a real debate about where on it to sit.

But notice what the spectrum measures. Every position answers one question: how much execution authority should an agent get? And every position holds one variable constant: the funds sit with a custodian. The broker holds the account. The exchange holds the balance. The debate is about the length of the leash, never about who holds the money.

The custody case, taken seriously

Custody is winning by default, and not because anyone is foolish. It answers hard problems cheaply.

An AI agent has no legal identity, no assets in its own name, and no way to be sued. When it trades against you and something breaks, a custodial broker gives you what the law understands: a licensed intermediary, a complaints process, a regulator with jurisdiction. FINRA flagging governance frameworks is the system working as designed.

Custody is also the only option for some assets. A share of stock is not a bearer instrument; it is an entry in a broker's ledger inside a depository's ledger. There is no such thing as trustless on-chain settlement of your Robinhood equities position, and pretending otherwise would be dishonest. For equities, the spectrum above is the whole game.

And the demand side is real. The first serious dataset on the agent economy, a study by crypto market maker Keyrock run with Coinbase and the Tempo blockchain, counted over 104,000 registered agents across 15+ directories, settling 176 million machine-to-machine transactions worth $73 million between May 2025 and April 2026. Average transaction: about $0.31. Agents are already trading. They will reach for whatever rail exists.

What the same dataset says back

Here is the number from that study that should slow you down: roughly 98% of those machine-to-machine settlements moved through a single company's stablecoin. Keyrock's own researchers put the risk plainly: one regulatory challenge, one de-peg, one sustained outage at that issuer, and the agent economy has no fallback.

That is the baseline concentration. Now add the broker wave on top. Every custodial seat added this year introduces another balance sheet the trade depends on, another honeypot worth attacking, another permission gate on who gets to trade. Concentration stacked on concentration, one convenient integration at a time.

For crypto assets, and only for crypto assets, this is a choice rather than a necessity. Coins and tokens are bearer instruments. They can settle without anyone holding them in the middle. That is the one property that made the asset class interesting in the first place, and it is exactly the property the agent economy's current architecture is quietly giving up.

The missing end of the spectrum

Atomic settlement via hash-time-locked contracts (HTLCs) is the fourth position the broker race does not include: nobody holds the gap.

The mechanics fit in a paragraph. Two parties lock funds on their respective chains against the same hash. To claim the leg you are owed, you reveal the secret preimage, and that same revelation lets your counterparty claim theirs. If either side walks away, both legs refund after timeout. There is no state of the world where one side has both legs, and no intermediary who ever holds either. Your money never leaves your wallet until theirs arrives.

Honest tradeoffs, because they are real:

Capital locks up for the duration of the swap, and the timeout windows are a design parameter you must get right.
If you go offline at the wrong moment, you rely on the refund path, not on a support desk.
It only works for on-chain bearer assets. Equities stay with the brokers. This is a settlement layer for crypto legs, not a replacement for your brokerage.
Liquidity has to be bootstrapped pair by pair, while custodial venues start with deep books.

What about accountability, custody's strongest card? That is a layer, not a reason to hand over funds. In our stack it looks like a verified counterparty directory with tiered KYC: agents and their operators verify once, at a level matched to their size, and counterparties can require a verification tier before quoting. Execution rewards point the incentive the same direction, rewarding counterparties that complete settlements cleanly. You get someone to hold responsible without someone holding the money. Identity and reputation efforts like ERC-8004 push the same direction at the standards level; they compose with atomic settlement rather than compete with it.

This is not hypothetical plumbing. The RFQ plus HTLC flow runs end-to-end on Ethereum mainnet today, exposed to agents as MCP tools via @hashlock-tech/mcp (v0.4.1 on npm). Sui contracts are deployed and CLI-tested, with gateway wiring in progress. Bitcoin is validated on signet, mainnet pending. The protocol design is written up in our SSRN paper, and the project lives at hashlock.markets.

Scaffolding or architecture?

So the debate we are running today, and I will state both readings as strongly as I can:

Reading one: custody is the architecture. Regulation demands an accountable intermediary, agents' owners want a throat to choke, equities require it anyway, and convenience compounds. The 98% number is not a bug, it is what production infrastructure looks like. In 2027 the agent economy settles inside brokers and exchanges, and trustless settlement stays a niche for ideologues.

Reading two: custody is the scaffolding. Every payments era starts by borrowing the previous era's intermediaries and ends by removing the ones that were only there out of habit. The 98% number is an early-stage artifact, the honeypots have not been seriously attacked yet, and the first eight-figure custodial failure in an agent context sends volume toward rails where failure of an intermediary is not a possible state.

We are building for reading two, which tells you our bias. But the broker race is real evidence for reading one, and pretending otherwise would make us worse at our job.

Which reading do you find more convincing, and what evidence would change your mind? If you run agents that trade, I am especially interested in whether custody was a factor you chose or a default you inherited.

AI agents are about to rediscover the oldest risk in modern finance

Baris Sozen — Wed, 22 Jul 2026 06:08:51 +0000

On 26 June 1974, German regulators withdrew the banking license of Bankhaus Herstatt, a mid-sized bank in Cologne, in the middle of the trading day. The timing is what made it famous. Herstatt's FX counterparties had already irrevocably paid the Deutsche Mark legs of that day's trades in Frankfurt. The corresponding dollar legs were due to settle hours later in New York. They never did.

Banks that had done nothing wrong except pay first were left holding losses on trades that were half-settled: one leg complete, one leg gone. The episode was significant enough to name a category of risk - settlement risk, still called Herstatt risk - and it pushed the G10 central banks to form the Basel Committee on Banking Supervision later that same year.

Here is the part worth sitting with: the actual fix took 28 years.

The fix was a central utility

CLS launched in 2002 with one job: settle FX trades payment-versus-payment. Both legs of a trade settle simultaneously, or neither does. There is no window in which one side has paid and the other has not. It works - CLS settles on the order of trillions of dollars a day - and it is the reason a Herstatt-style failure has not repeated at scale in the currencies it covers.

But look at the shape of the solution. To make two legs atomic, traditional finance built one institution that every major bank trusts, connected the world's main currencies to it, and routed the trades through it. Atomicity was achieved by adding the most systemically important middleman in the history of payments.

That was probably the only option available to 1990s banking infrastructure. It is not the only option available now.

The agent economy is still in its payments era

A study published last week by Keyrock, run with Coinbase and Tempo, put numbers on machine-to-machine commerce: 176 million transactions, $73 million settled between May 2025 and April 2026, average transaction size around $0.31.

Those numbers describe a payments economy. A payment is a single leg: value moves one direction, against a service delivered off-chain. If it fails, you retry it. The current agent rail stack - HTTP-native payment standards, facilitator APIs, custodial escrow - is built around exactly this case, and for this case it is reasonable.

Trades are a different object. A trade is two or more legs that must move together: asset against asset, often on different chains, often between parties who met through a directory minutes earlier. And agent workflows compound legs quickly. An agent that sells one asset, uses the proceeds to acquire another, and posts part of the result as collateral is running a three-leg sequence where leg 2 depends on leg 1 and leg 3 depends on leg 2. A ring of three agents - data seller, compute provider, broker - settling a three-way exchange is a cycle of dependent legs.

For multi-leg structures, partial completion is not an edge case. It is the default failure mode.

Agents make leg risk worse, not better

Three properties of agent commerce sharpen the 1974 problem.

First, speed and volume. A human trading desk settles a manageable number of trades a day, with humans watching. An agent pipeline can half-complete a thousand multi-step sequences before anyone looks at a dashboard.

Second, counterparties are strangers by design. The premise of an open agent economy is that agents discover and transact with counterparties they have never seen before. There is no relationship, no credit history, no implicit trust to fall back on.

Third, there is no recourse layer. Two banks caught in a half-settled trade in 1974 had lawyers, regulators and decades of workout practice. Two autonomous agents caught in a half-settled trade have nothing, unless a human steps in - which is precisely what autonomy was supposed to remove.

The instinctive answer is the 2002 answer: add a referee. Put a custodian or an escrow agent in the middle and let it hold both legs. That imports the middleman, the fees, and the single point of failure - and, as we wrote yesterday, the agent economy is already accumulating those referees at speed.

Payment-versus-payment, without the utility

There is a cryptographic construction that delivers the CLS guarantee without the institution: the hash-time-locked contract.

The two-leg version is the classic atomic swap. Both parties lock funds against the same hash H(s). The party holding the secret s claims the counterparty's leg by revealing s on-chain; that same revelation is what lets the counterparty claim the other leg. If s is never revealed, both legs refund after their timeouts expire. Both sides complete, or both sides get their money back.

The property generalizes. Lock N legs - a ring trade, a trade plus its collateral leg, a multi-step position assembly - against the same hash, and one revelation settles the entire structure while silence refunds the entire structure. All legs or none. That is payment-versus-payment and delivery-versus-payment collapsed into one primitive, enforced by a hash function instead of a Belgian settlement bank.

We call this multi-leg trade atomicity, and it is one of the five settlement primitives we are building at Hashlock.

The honest tradeoffs

Multi-leg atomicity is not free, and it is worth being precise about the costs.

Capital lockup. Every leg must be funded and locked for the duration of the settlement window. More legs means more capital-time committed before anything settles.

Timeout laddering. Refund windows cannot be arbitrary. They must be ordered so that every party who learns the secret still has time to claim their inbound leg, with each step padded by the confirmation time of the slowest chain involved. The total window therefore grows with leg count. Long rings across slow chains get expensive in time, which is a real constraint on how many legs are practical.

The last-mover option. The secret holder can wait until near the deadline to decide whether to reveal. For the window's duration, they hold a free option on the trade. Short windows, counterparty screening above the settlement layer, and pricing all mitigate this; none of them make it disappear.

Liveness. Parties must be online to claim within their windows, or delegate that job. A crashed agent that misses its claim window turns a completed trade into a refund.

These tradeoffs are why atomic multi-leg settlement is a primitive you reach for when counterparty risk matters more than latency - which is a good description of high-value trades between anonymous autonomous agents.

Where this stands

Status, precisely: settlement is live end-to-end on Ethereum mainnet. Sui contracts are deployed and CLI-tested, with gateway wiring in progress. Bitcoin support is validated on signet; mainnet is pending. Agents reach the protocol over MCP - six tools, npm package @hashlock-tech/mcp, currently v0.4.1. The settlement design is written up in our SSRN whitepaper, and the protocol lives at hashlock.markets.

FX markets earned atomic settlement the hard way: a bank failure, a new supervisory committee, and 28 years of infrastructure work. The agent economy gets to inherit the finished concept on day one.

If you are building agent workflows today: how many dependent legs does your longest flow have, and what happens right now if it stops halfway? I would like to hear what the failure story looks like in practice.

The agent economy keeps re-hiring the middlemen crypto was built to remove

Baris Sozen — Tue, 21 Jul 2026 07:18:44 +0000

A study published this week by crypto investment firm Keyrock, run with Coinbase and the Tempo blockchain, put real numbers on the agent economy for the first time: $73 million settled across 176 million machine-to-machine transactions between May 2025 and April 2026. Over 104,000 registered agents across 15+ directories. Average transaction size: about $0.31.

And one more number, the one that should stop you: roughly 98% of those settlements moved through a single company's stablecoin.

Keyrock's own researcher put the risk plainly: if that one issuer faces a regulatory challenge, a de-peg event, or even sustained downtime, the agent economy has no fallback.

That is not a decentralized economy. That is an economy with a single load-bearing middleman.

The pattern nobody is naming

Zoom out from the stablecoin and the same shape repeats everywhere in agent commerce this year:

Payment rails went official. x402 graduated into a Linux Foundation standard, 40 members deep - Visa, Mastercard, Stripe, Circle, Google. Genuinely useful. Also: built around payment facilitators sitting in the flow.
Escrow moved inside the exchange. One major exchange now runs agent escrow, settlement and dispute resolution inside its own walls. The agent's funds sit with the referee.
Custodial referees are multiplying. New escrow services pitch themselves as the "neutral custodian" for agent trades - a dispute judge who holds the money while the agents argue.
Brokers are shipping agent MCPs. The "AI agent trading" search results are filling with custodial broker accounts wearing an MCP interface.

Different products, different chains, different logos. The same architectural move every time: solve the agent trust problem by inserting a party both agents must trust.

Which is strange, because removing exactly that party was crypto's founding idea.

Why custody keeps winning by default

To be clear, this is not a conspiracy. Custody is the easy answer to a real question: how do two autonomous agents, with no legal identity, no reputation, and no ability to sue each other, trade without one side walking off mid-trade?

A custodian answers it the way humans always have: put a trusted adult in the room. Hold both sides' funds. Referee disputes. Charge for the seat.

It works. It also quietly re-creates everything crypto spent fifteen years engineering away: counterparty risk concentrated in one balance sheet, a honeypot worth attacking, a permission gate on who gets to trade, and - as the 98% number shows - systemic dependence on a handful of intermediaries.

Custody is a habit, not a requirement.

The settlement leg never needed a middleman

Here is the part that gets lost in the noise: for the trade itself - asset for asset, chain to chain - the trustless answer has existed for years. It is a hash-time-locked contract (HTLC), and the mechanics fit in a paragraph:

Both sides lock funds against the same cryptographic secret. Revealing the secret to claim one leg automatically hands the counterparty the key to claim the other. Stay silent past the timeout, and both legs refund. Either both sides get paid, or neither does. There is no state in which a middleman is holding your money, because there is no middleman.

The contract does not care if the counterparty is a human, an agent, or a thousand Sybil fakes. Safety rests on the math, not on knowing who is on the other side - and not on anyone's balance sheet.

PayPal made it safe to pay strangers online by becoming the trusted middleman. Atomic settlement makes it safe for agents to trade with strangers on-chain with no middleman at all. Your money never leaves your wallet until theirs arrives.

What this looks like in practice

This is what we build at Hashlock: sealed-bid RFQ plus HTLC atomic settlement, exposed to AI agents as an MCP server with six tools (quote, create, withdraw, refund, status, RFQ). MCP because that is the interface agents already speak.

Where it stands today, stated precisely:

Ethereum mainnet: live end-to-end. Immutable V1 contracts.
Sui: contracts deployed and CLI-tested. Gateway wiring in progress.
Bitcoin: validated on signet. Mainnet pending.

Install: npm install @hashlock-tech/mcp (v0.4.1). The protocol design and its game theory are written up in our SSRN paper.

The honest tradeoffs

Atomic settlement is not free. Capital locks up for the duration of the swap. Timeout parameters carry real design weight - too short and honest slow parties get refunded against their will, too long and capital drags. Custodians still buy you things HTLCs do not: fiat ramps, deep order books, a support desk, dispute resolution for off-chain legs.

If your agent needs those, use them - knowingly. The argument is narrower and sharper: the settlement leg of a crypto-to-crypto trade is the one place where the middleman is architecturally unnecessary. Paying the custody tax there is a choice. Increasingly, it looks like a choice being made by default, at ecosystem scale, without anyone deciding it.

The question

The agent economy is being assembled right now, rail by rail, standard by standard. The 98% number says concentration risk is already here. Every custodial referee added this year says the habit is compounding.

So, builders: if your agent could settle atomically, with no custodian in the trade, would you still hand it custody - and if so, what exactly are you buying with it?

Tell me where this argument breaks. I answer every comment.

Hashlock - the atomic settlement layer for the agent economy. Live on Ethereum mainnet: hashlock.markets

Atomic settlement is Sybil-blind by design - and that is why a counterparty directory sits above it

Baris Sozen — Mon, 20 Jul 2026 06:47:43 +0000

Last week a reader left a comment on one of our posts that was sharper than most product feedback we get. The point, paraphrased: a hash-time-locked contract is Sybil-blind. It cannot distinguish a real counterparty from a fake one, or one identity from ten thousand spun up by the same actor. The implication hanging in the air was: isn't that a problem?

It is worth answering carefully, because the honest answer is no, that blindness is the point - and understanding why draws a clean line between two things that agent-settlement systems keep conflating.

What an HTLC actually guarantees

Start with the mechanism. A cross-chain atomic swap has two control parameters.

The hashlock. One party picks a secret s and publishes H = SHA-256(s). Both legs of the trade - say an asset on Ethereum and an asset on another chain - are locked so they can only be claimed by revealing a preimage of H. Because both legs bind to the same H, revealing s to claim one leg exposes it on-chain, which lets the counterparty claim the other. Either both legs complete or neither does.

The timelock. If nobody reveals s, funds cannot sit locked forever. Each leg has a timeout after which the original owner refunds. The second mover gets the earlier deadline so the first mover cannot reveal at the last second and grief them.

Now read those two rules again and notice what is not in them: identity. The contract never asks who you are. It checks one thing - can you produce a preimage of H before the timeout - and enforces the outcome. That is the whole trust model. It is why the settlement is trustless and non-custodial: safety does not rest on knowing, trusting, or verifying the counterparty. It rests on the math.

So when the reader says the contract is Sybil-blind, they are exactly right, and it is the same statement as "the contract is trustless." You cannot have one without the other. The moment settlement safety starts depending on who the counterparty is, you have reintroduced the thing atomicity was built to delete.

What Sybil-blindness covers, and what it does not

Here is the distinction worth internalizing. There are two different risks in any trade:

Default risk - the counterparty takes your asset and gives nothing back, or disappears mid-trade. Atomic settlement eliminates this completely, for real and fake identities alike. A Sybil army cannot beat an HTLC any better than a single honest party can; the contract simply refunds you if the trade does not complete. Blindness is a full defense here.
Selection risk - do you want to enter this trade with this address at all? Maybe it is a wash-trading cluster inflating volume. Maybe it is an address you are not permitted to transact with. Maybe you want to route only to counterparties with a settlement history. Atomicity says nothing about any of this, because it was never supposed to.

The mistake is expecting one primitive to solve both. It cannot, and it should not try. A settlement layer that starts screening identities to decide whether to settle is no longer a neutral settlement layer - it is a gatekeeper, and gatekeepers are the custodial intermediaries we removed.

The wash-trading data makes this concrete

A July study of on-chain agent-payment activity found that a large share of the reported "volume" was fictitious or moving inside linked internal clusters - value cycling between addresses controlled by the same actor to manufacture the appearance of activity. That is Sybil behavior at the payment-rail layer, and it is instructive for settlement.

Atomic settlement does not create fake volume - there is no incentive to wash-trade through an HTLC, because both legs move real assets atomically and you gain nothing by swapping with yourself. But it also does not flag it. If an agent wants to avoid quoting against a known wash cluster, or wants to prefer counterparties with genuine history, the settlement contract is the wrong place to ask. It is blind on purpose.

The two-layer split

So we keep the two problems apart by design rather than blurring them into one contract:

Layer 1 - settlement. Trustless, identity-blind, atomic. Live on Ethereum mainnet today. Sui contracts are deployed and CLI-tested; Bitcoin is validated on signet. This layer never learns or checks who you are, and it never will, because that is the property that makes it safe.

Layer 2 - selection. An optional Verified Counterparty Directory an agent can consult before it enters an RFQ. It answers a different question - "is this counterparty one I want to engage?" - using attestations, history, and reputation signals. It can consume external identity primitives rather than reinventing them; ERC-8004 (trustless agents, identity and reputation) is a natural source, and a directory is a consumer of those attestations, not a competitor to them.

The critical architectural rule: settlement never depends on the directory. You can trade with an unlisted counterparty and the atomic guarantee is identical - your money still never leaves your wallet until theirs arrives. The directory changes whom you choose to quote, never whether the settlement is safe. If Layer 2 is offline, wrong, or gamed, Layer 1 is unaffected. That one-way dependency is what lets you add counterparty verification without smuggling trust back into the settlement path.

Why the separation matters for agents specifically

An autonomous agent negotiating trades across chains needs both answers, but at different moments. At selection time - deciding whom to send an RFQ to - a reputation signal is useful and worth paying for. At settlement time - locking the funds - the only thing that should matter is the contract, because that is the moment where trust would be most expensive to get wrong. Collapsing the two means an agent's settlement safety becomes only as good as its identity oracle. Keeping them separate means the worst a bad directory can do is send you a quote you did not want - not lose your funds.

Sybil-blindness, in other words, is not a gap to be patched inside the settlement layer. It is the feature that lets everything above it stay optional.

The open question

If settlement must stay identity-blind and selection lives above it, where exactly should the line sit? How much verification belongs in a directory an agent queries by choice, versus signals baked into the RFQ layer itself - and what should an agent be allowed to trade against with zero counterparty information, relying purely on atomicity? Curious how others building agent-commerce infrastructure are drawing that boundary.

Settlement layer, live on Ethereum mainnet: hashlock.markets/docs. The MCP server (hashlock-tech/mcp, scoped) is on npm. Methodology behind the volume and wash-trading framing: hashlock.markets/methodology. Academic foundation on SSRN.

Week 14 in review: the agent economy's rails went official. The settlement seat is still empty.

Baris Sozen — Sun, 19 Jul 2026 10:51:23 +0000

Every Sunday we step back and map where the agent economy actually moved that week, and where the money still sits at risk. This week had a clear headline: the payment rails became official infrastructure. That's worth taking seriously. It's also only half the stack.

What shipped: the rails went official

On July 14, the Linux Foundation launched the x402 Foundation as an open-governance body with 40 member organizations. The list is not a crypto-startup roster. It's Visa, Mastercard, and American Express on the card-network side; Stripe, Adyen, and Fiserv on processing; Google and AWS on cloud; Circle and Coinbase on stablecoins; and Solana, Stellar, and Ripple on rails. When that many incumbents put their name on one vendor-neutral standard, the category has stopped being speculative.

x402 itself is clean engineering. It's an HTTP-native protocol: a server answers a request with 402 Payment Required, the client signs a payment, and the request replays and settles. No account registration, no card checkout, no pre-funded balance with the provider. Facilitators verify and settle without ever custodying the funds. Real-world settlement today runs primarily on USDC on Base, with Solana and BNB Chain facilitators live too.

A day earlier, on July 13, Binance's agentic wallet added x402 support as an installable skill, so an agent can parse the 402, confirm, sign, replay, and return the settlement result without custom payment code. The rail is now something you plug in, not something you build.

If you're building agents that need to pay for things - an API call, a dataset, a metered inference step - this is genuinely good news. The plumbing is standardized and backed by people who run global payments for a living.

The number that complicates the picture

Here's the part the launch posts skipped. A population-scale study published in July found that a large share of on-chain x402 settlement activity was either fictitious or occurred within linked internal clusters. Headline volume figures - tens of millions of transactions - include a meaningful slice of wash and self-dealing traffic.

That's not a knock on the protocol. It's a reminder that standardizing a rail doesn't make the flow across it real, and that "volume" and "genuine economic settlement between independent parties" are different measurements. It matters for anyone reasoning about the agent economy from transaction counts: the rail is real and the standard is real; some of the traffic is theater.

The gap: paying is not trading

Strip the news down to primitives and the shape of the week is clear.

A payment is one asset moving one direction. Agent A pays USDC, gets a service. x402 is excellent at this, and now standard.

A trade is two assets moving two directions between two strangers. Agent A holds token X on one chain; Agent B holds token Y on another; they've agreed to exchange. Now you have a problem a payment rail was never designed to solve: atomicity across two legs. If leg one clears and leg two doesn't, someone is out their asset. The whole reason you needed a protocol is the moment where one party could take the goods and keep the money.

There are three usual answers, and two of them reintroduce the thing you were trying to remove:

A custodian or exchange holds both sides and releases when it's satisfied. Now the trade is only as trustless as the party in the middle.
A bridge wraps one asset so it can move to the other chain. Now you've added a honeypot and a new trust assumption about whoever secures the wrap.
A hash-time-locked contract (HTLC) binds both legs to a single secret. Revealing the preimage to claim one leg is exactly what claims the other; a timelock refunds if it never completes. No custodian, no wrap, no window where one party holds both the asset and the payment.

The third one is the settlement layer. It's the seat that stayed empty this week while the rails got standardized.

Why we keep drawing this line

This isn't x402 versus anything. A rail and a settlement layer are complementary - agents will pay on x402 and settle asset-for-asset trades on an atomic layer underneath, and the same agent will do both in a single session. The mistake we watch people make is collapsing the two into one box labeled "agent payments," then wondering why a payment protocol can't safely execute a cross-chain swap. It can't, because it was never that layer.

Hashlock is building that layer: sealed-bid RFQ so two agents can price a trade, fused with HTLC atomic settlement so they can execute it without a middleman. Chain status, stated precisely because it matters: Ethereum mainnet is live end to end today. Sui contracts are deployed and CLI-tested. Bitcoin is validated on signet, mainnet pending. We don't call Sui or BTC "live," and we won't.

The agents reach it as an MCP server with six tools - list pairs, quote, create an RFQ, respond, execute, check status - so an AI agent can run the whole settle-a-trade loop the same way it now runs the pay-for-an-API loop.

The week in one line

The rails went official, and the settlement seat is still open.

PayPal made it safe to pay strangers online. The agent economy still needs the layer that makes it safe to trade with strangers - where your money never leaves your wallet until theirs arrives. This week the paying half got a standards body and 40 logos. The trading half is still being built in the open.

Volume methodology and how we count real settlement: hashlock.markets/methodology. The academic foundation for the RFQ + HTLC design is on SSRN.

If you're building in this space: which layer of the agent stack do you think fills in next - and where do you think the real settlement volume (not the wash traffic) actually is today?

The agent-commerce stack filled in this month. Here's the map - and the one open layer.

Baris Sozen — Sat, 18 Jul 2026 06:09:09 +0000

If you build for AI agents that move value, the last two weeks were a lot to keep up with. Five separate pieces of the agent-commerce stack shipped or hardened, from a payments standardization body down to a new escrow standard. That is genuine momentum, and it is worth reading as a whole rather than as isolated headlines.

So here is the map. For each layer I will note what it does well and where it stops - because the gaps tell you what is still missing more clearly than the wins do.

1. Rails: x402 became a Linux Foundation standard

On July 14, 2026, the Linux Foundation announced the operational launch of the x402 Foundation - an open-governance body to steward the x402 protocol, an open standard for payments over HTTP. The protocol, originally contributed by Coinbase, lets agents, APIs, and applications send and receive payments as easily as they exchange data.

The membership list is the story: 40 members, with premier names including Adyen, AWS, American Express, Circle, Cloudflare, Coinbase, Fiserv, Google, Mastercard, Monad, MoonPay, Ripple, Shopify, Solana, Stellar, Stripe, and Visa. When Visa, Stripe, and a cloud provider all sit on the same payments board, the "how does an agent pay for something" question is effectively being answered in public.

What it does well: standardizes agent payment initiation over HTTP. Fast, cheap, vendor-neutral.

Where it stops: x402 moves one asset, one direction - most volume settles a single stablecoin on a single chain. That is a payment, not a trade. Paying is "I send you USDC." A trade is "I send BTC, you send ETH, and neither of us can run off in the middle."

2. Wallets: Phantom shipped an agent MCP

Phantom released a wallet MCP that gives an AI agent a signer across Solana, Ethereum, Bitcoin, and Sui. The tools are what you would expect: get addresses, sign a message, sign a transaction, transfer tokens, buy a token. An agent reasoning with an LLM can now hold its own keys and move its own funds across four chains.

What it does well: the key-custody layer. An agent no longer needs a human to sign for it.

Where it stops: a wallet that signs a swap is not a protocol that settles a trade. The signer executes whatever transaction it is handed. It does not guarantee that the counterparty's leg completes atomically with yours. Signing is necessary; it is not settlement.

3. Marketplaces + escrow: OKX moved the business loop in-exchange

OKX's Agent Payments Protocol wraps quotes, negotiation, metering, a payment SDK, and - on the roadmap - escrow and dispute resolution into one package on its X Layer chain, working across Base, Solana, and Ethereum. It is the most complete single-vendor "business loop" for agents so far.

What it does well: one SDK for the whole commercial interaction. Convenient by design.

Where it stops: it is custodial and exchange-owned, and the escrow + dispute pieces are still marked "coming soon" rather than shipped. Convenience through a single venue is a real pull, but it reintroduces exactly the intermediary that trust-minimized settlement is meant to remove.

4. Identity + commerce: ERC-8004 and ERC-8183 advanced

Two Ethereum standards are maturing in parallel. ERC-8004 gives agents portable identity and reputation. ERC-8183 proposes escrow-with-an-assessor for agent commerce - a neutral third party who adjudicates whether a deal completed. Together they sketch an "identity + commerce" pair for the agent economy.

What they do well: solve the "who am I dealing with, and who decides if the deal went through" problem.

Where they stop: an assessor is a trusted party. Useful when the exchange is subjective (was the work good?), but for a pure asset-for-asset swap you do not need a judge if the settlement itself is atomic. A hash-time-lock contract makes the swap all-or-nothing by construction - no assessor required.

5. The primitive itself: a second team is running agents on atomic HTLC swaps

The most validating signal is not from us. A second team is now running an AI agent that executes atomic HTLC swaps non-custodially - the exact hash-time-lock primitive our protocol is built on. Two independent teams, same bet: the settlement layer for agents is a trust-minimized atomic swap, not a custodial hold.

The one layer nobody standardized

Line the five up and a single thread runs through them. At the moment of settlement, either someone holds the money or you trust someone who does - a bridge, a custodian, an exchange, an assessor.

The open seat is this: two agents, two different assets, two different chains, two strangers - and a guarantee that no one can walk off mid-trade. That is atomic settlement, and it is the layer none of the five above actually deliver.

Here is the mechanism, in one paragraph. Both legs of the trade are bound to a single secret through a hashlock H = SHA-256(secret). Claiming one leg reveals the preimage, which is exactly what is needed to claim the other. A timelock refunds each side if the trade never completes. No wrapped assets, no custodian holding the gap, no assessor deciding who was right - the math makes it all-or-nothing.

The honest status, because chain-claim discipline matters: this is live on Ethereum mainnet today. Bitcoin is validated on signet with mainnet pending. Sui contracts are deployed and CLI-tested with gateway wiring in progress. Rails ready, more trains coming - and we will only ever call a chain live when it actually is.

Why this framing, not "we compete with all of them"

We do not. x402 is how an agent pays; our layer is how two agents swap. Phantom holds the keys; we settle the trade those keys sign. ERC-8004 says who the counterparty is; we make sure the swap with that counterparty is atomic. Almost every layer above is complementary. The one thing missing across all of them is a settlement primitive that never has to trust an intermediary at the exact moment value changes hands.

PayPal made it safe to pay strangers online. The agent economy now has most of a stack for agents to pay each other. The piece still being written is the one that makes it safe for two agents to trade with each other - where your money never leaves your wallet until theirs arrives.

Protocol and tools: hashlock.markets · MCP server: @hashlock-tech/mcp (scoped) · Method and design: hashlock.markets/methodology · Academic foundation on SSRN.

Of the five layers above, which one do you think gets standardized last - and would you rather your agent settle through an assessor or through math that cannot be argued with?

How an AI agent posts Bitcoin as collateral without giving up the keys

Baris Sozen — Fri, 17 Jul 2026 06:07:44 +0000

Your AI agent just agreed to a trade that needs backing. A forward it has to deliver on in 24 hours. A loan it has to repay. A leg in a multi-step swap that only completes if every other leg does. Before any of that clears, the agent has to post collateral, and the deepest collateral asset in crypto is Bitcoin.

So it goes to post BTC. And immediately it hits the oldest problem in cross-chain: 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. The collateral has to be usable on a chain that can reason about it, while the BTC itself lives on a chain that cannot.

This post is about the wrong way to solve that, the right way, and what it takes for an agent to do it without a human in the loop.

The easy path quietly re-custodies your collateral

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

Look at what just happened. The agent removed the custodian from the trade, then invited one straight back in at the collateral. The token it now holds is a claim on someone else's honesty and solvency. If the entity holding the real coins is compromised, drained, frozen, or simply wrong, the collateral backing the agent's obligation evaporates, and the agent has no good way to audit any of it in real time.

For a human treasurer, that is a known, priced risk. For an autonomous agent, it is worse: the agent cannot tell the difference between collateral it controls and collateral that only looks like it controls. A settlement layer that is trustless at the moment of the trade but custodial at the moment of the collateral is not trustless. It has just moved the trust somewhere the agent stopped looking.

A vault that never moves the coins

A BTC Collateral Vault takes the opposite trade. The Bitcoin never leaves Bitcoin, and it is never represented by a minted token. It stays as native BTC, locked in a script on the Bitcoin chain. What crosses to the settlement chain is not the asset. It is one piece of information: the hash of a secret.

If you have seen a hash-time-locked contract (HTLC) before, this is the same machine, pointed at a new job.

Hashlock. The BTC is locked in a Bitcoin script that will release only to whoever can present the preimage of a hash H = SHA-256(secret). Nobody can move the coins early, because nobody but the party who generated the secret knows it.
Timelock. If the obligation is never settled, a timelock path lets the agent reclaim its own BTC after a deadline. No keeper, no counterparty cooperation, no support ticket. The refund is a property of the script, not a promise from a company.
The cross-chain link. The settlement-chain side of the deal is bound to the same hash. Claiming the settlement leg reveals the secret on-chain; that revealed secret is exactly what unlocks the BTC. One preimage settles both sides, or neither side moves.

The collateral is real Bitcoin the whole time. The agent's keys never leave the agent. And the integrity of the position no longer depends on auditing a custodian, because there isn't one.

What the agent actually does

From the agent's point of view, this is a small number of deterministic steps, which is exactly what you want when there is no human to catch a mistake.

Generate a secret and its hash. Keep the secret private.
Lock native BTC into the vault script on Bitcoin, keyed to that hash and a timelock it chooses.
Publish the hash and the vault reference to the settlement-chain contract holding the counter-obligation.
On settlement, the claim reveals the preimage, which the agent (or the counterparty, depending on the flow) uses to unlock the BTC. If settlement never happens, the timelock refunds the agent.

There is no step where the agent has to trust a wrapper to be solvent, a bridge to stay unhacked, or a federation to stay honest. The only things it trusts are Bitcoin's script rules and the settlement chain's contract, both of which it can verify itself.

We expose this through a Model Context Protocol server: a 6-tool MCP an agent reasoning over an LLM can call directly to quote, lock, settle, and refund, so the vault flow is a set of tool calls rather than a bespoke integration for every model.

The honest status line

I keep chain claims precise, because in this domain an overclaim is a lie the agent inherits.

Ethereum mainnet: the atomic settlement leg is live end to end today.
Sui: contracts are deployed and CLI-tested, not mainnet-live.
Bitcoin: the collateral-vault mechanism is validated on signet. Mainnet is pending, not shipped.
Roadmap: Base, Arbitrum, Solana, TON.

So the BTC Collateral Vault is a validated design on signet with a live settlement counterpart on Ethereum, not a Bitcoin-mainnet product I am pretending exists. If you build on it today, that is the surface you are building on.

Why this is the layer worth getting right

This week the agent economy took a real step: agent payments consolidated under a single standard as x402 moved to a foundation with dozens of members behind it. That is genuine, and it matters. But a payment rail answers one question, "how does an agent pay," and it answers it in one token, on one chain.

Collateral is a different question. It is not "how do I pay you" but "how do I back a promise I have not yet kept, in the best collateral asset there is, across chains, without handing it to anyone." The moment an agent posts something to back an obligation, the custodian question comes back, and most of the stack answers it by quietly re-custodying. A vault that keeps the BTC native and moves only a hash is how you answer it without blinking.

If your agent could post native BTC as collateral without wrapping it, what is the first obligation you would have it back: a forward, a loan, or a leg in a multi-step trade?

Docs and the 6-tool MCP: https://hashlock.markets/docs?utm_source=devto&utm_medium=article&utm_campaign=2026-07-17-btc-collateral-vaults

The academic grounding for the settlement model, if you want the formal version: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722

Settlement inside the exchange vs settlement in the protocol: reading OKX's Agent Payments Protocol

Baris Sozen — Thu, 16 Jul 2026 06:34:00 +0000

On April 29, 2026, OKX announced the Agent Payments Protocol (APP), an open standard meant to carry the entire business cycle between AI agents: quotes, negotiation, usage metering, settlement, and, on its roadmap, escrow and dispute resolution. It ships with a payment SDK supporting one-time, batch, and usage-based payments on OKX's X Layer chain, and it is designed to work across other chains including Ethereum and Solana. It follows Coinbase's x402 and Stripe's Machine Payments Protocol as the third major attempt to give agents a way to pay.

APP is a serious piece of work, and it is worth being precise about what it is and is not. Because the interesting question it raises is not "who has the best agent payment rail." It is a narrower, load-bearing question: when two agents settle a trade, where should the settlement guarantee live?

Two honest readings

Read one: the exchange wins. An autonomous agent optimizes for the path of least resistance. If one venue offers quotes, negotiation, metering, payment, and settlement behind a single SDK, that convenience is a real gravitational pull. Developers reach for the integrated option. APP could become the default surface for agent commerce simply by being the easiest thing to call.

Read two: the protocol wins. "Settlement inside the exchange" has a precise technical meaning. It means that at some point in the trade, the exchange (or a component it operates) holds the funds while the other leg is arranged. That is custody in the middle of the swap. And custody in the middle of the swap is exactly the honeypot the agent economy keeps rebuilding under new names: the bridge, the OTC desk, the escrow account, the settlement venue.

Both reads are defensible. That is what makes it a genuine debate rather than a strawman.

The distinction that actually decides it

The clarifying frame is the difference between a payment rail and a settlement layer.

A payment rail moves value from A to B. x402, Stripe MPP, and the payment side of APP are all rails. They are excellent at what they do, and agents need them.

A settlement layer guarantees an exchange of two assets between parties who do not trust each other. Agent-to-agent trading is the second problem, not the first. Agent X holds BTC and wants ETH; agent Y holds ETH and wants BTC. A rail can push agent X's BTC out. Nothing about a rail forces agent Y's ETH to come back. Something has to make both legs contingent on each other, or a third party has to stand in the middle and hold the funds until both sides are satisfied.

There are only two ways to close that gap:

A custodian holds the middle. Someone (an exchange, an escrow contract with a release authority, a judge) takes the funds and releases them on delivery. This is what "settlement inside the exchange" resolves to. It works, and it reintroduces counterparty risk. Whoever holds the middle is a target: for a hack, for insolvency, and, in an agent context, for prompt injection against whatever logic controls release.
The math holds the middle. Lock both legs to a single hash condition. Claiming one leg reveals the secret that unlocks the other. If either side walks, both legs refund after a timeout. No party ever holds the counterparty's funds. This is a hash time-locked contract (HTLC), and it is the mechanism behind atomic settlement.

Reading APP's own roadmap carefully

Here is the detail that matters and that is easy to skim past: by OKX's own description, APP's escrow and dispute-resolution components are planned, not yet shipped. The payment SDK is live; the escrow-on-delivery and dispute layers are on the way. That is not a criticism, it is a status. But it means the "full business loop" is, today, mostly the payment half of the loop. The settlement-with-guarantees half is still ahead of it.

That is precisely the half that has to be trust-minimized to matter for agents that do not trust each other. An escrow with a release authority is only as safe as that authority. And in 2026 we already have a public red-team result (arXiv 2601.22569) showing that when researchers attacked an agent commerce flow, the cryptographic mandates held while the reasoning layer folded. Any component that can release custody based on a judgment call inherits that fragility. Any component that releases based on a hash preimage does not.

Where Hashlock sits

We build the settlement layer, not the rail. Sealed-bid RFQ fused with HTLC atomic settlement, exposed to agents as an MCP server with a small set of tools. Both legs of a cross-chain trade lock to one secret; they clear together or refund together; no venue holds the gap in between. Your money never leaves your wallet until theirs arrives.

This is complementary to the payment rails, not competitive with them. An agent can discover and negotiate a price over x402 or APP, then settle the asset swap atomically underneath. Rail on top, settlement layer below.

For chain discipline, since it always matters: this runs end-to-end on Ethereum mainnet today. Our Sui contracts are deployed and CLI-tested but not mainnet-live for agents yet, and our Bitcoin path is validated on signet with mainnet pending. When we say live, we mean Ethereum.

The question

APP is a strong signal that the agent economy is converging on the need for settlement, not just payment. The open question is topological: does that guarantee end up inside the venues (convenient, custodial), or one layer below them (neutral, trust-minimized)?

If you had to build an agent that trades assets it cannot afford to lose today, would you route settlement through the exchange that offers everything in one SDK, or through a protocol no one has to trust? Tell me which and why.

Whitepaper for the mechanism design: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722
Docs and MCP tools: https://hashlock.markets/docs?utm_source=devto&utm_medium=article&utm_campaign=2026-07-16-exchange-vs-protocol

A wallet that signs is not a layer that settles: reading Phantom's agent MCP

Baris Sozen — Wed, 15 Jul 2026 09:18:26 +0000

Phantom shipped an MCP server this month that lets an AI agent operate a Phantom wallet directly. It exposes five tools - get_wallet_addresses, sign_message, sign_transaction, transfer_tokens, buy_token - across Solana, Ethereum, Bitcoin and Sui. By default it simulates a transaction first, returns the expected asset changes, and waits for a confirmation before it broadcasts anything.

This is a genuinely useful piece of infrastructure, and it happens to cover the same four chains we build for. So it's a good moment to be precise about categories, because "an agent can now swap tokens across chains" and "an agent can now settle a cross-chain trade with a stranger" sound identical and are not.

What a wallet MCP actually gives an agent

Strip it to the primitive: a wallet MCP turns an agent into a signer. The agent can look up its addresses, sign a message, sign and send a transaction, move tokens, and buy a token. Every one of those is a first-person action. The agent decides, the agent signs, the agent's asset moves.

That's the missing hand the agent economy needed. For most of the last year, agents could reason about value but couldn't touch it - a human still had to approve each step. A wallet MCP closes that. Combined with a model reasoning over the tools (Phantom's docs show the standard MCP-client pattern), an agent can hold keys and execute on its own. The wallet layer of the stack is filling in.

Where "sign" stops and "settle" begins

Now put two agents on opposite sides of a trade. Agent A has BTC and wants ETH. Agent B has ETH and wants BTC. They don't trust each other. Walk it through with signer tools only:

Agent A signs and sends its BTC.
Agent A now waits for Agent B to send ETH.

Step 2 is the whole problem. Nothing in a signer binds Agent B's leg to Agent A's. sign_transaction moves one asset, one direction, and it's irreversible the moment it confirms. A wallet is very good at "push my asset out." It has no opinion about whether anything comes back. Between the two sends there is a window where one party is exposed, and in practice that window is why today's agent trades route through a custodian, a bridge, or an escrow-with-judge - somebody who holds the money while it clears. That somebody is the honeypot.

This isn't a knock on Phantom. A wallet is not supposed to guarantee a counterparty's leg. That's a different layer.

What settlement adds on top of signing

Atomic settlement binds both legs to a single secret. Concretely, a hash-time-locked contract (HTLC):

Both legs lock to the same hash H = SHA-256(secret).
Whoever claims one leg must reveal the secret, which unlocks the other leg.
If nobody claims before the timelock expires, both legs refund.

The property that a signer can't provide falls straight out of that: the trade either completes on both sides or unwinds on both sides. There is no state where Agent A's BTC is gone and Agent B's ETH never arrives. No custodian holds the gap, because there is no gap to hold - the cryptography does the holding. Your money never leaves your wallet until theirs arrives.

So the two tools compose cleanly rather than compete. A wallet MCP is how an agent signs its leg. A settlement protocol is what makes the pair of legs safe between strangers. You want both. One is the hand; the other is the handshake.

The stack view

It's worth zooming out, because Phantom is one more piece landing in a pattern that's now obvious:

Wallets so an agent can hold keys and sign - Phantom's MCP, MetaMask's agent wallet, Coinbase for Agents.
Rails so an agent can move value one direction, fast - x402, which has cleared over 160M payments.
Marketplaces and reputation so an agent knows who to transact with - OKX.AI, ERC-8004 identity.
Settlement so two agents who don't trust each other can complete a trade - two assets, two directions, no intermediary at the moment of exchange.

The first three are filling in fast, and mostly custodial or intermediated at the exact instant value changes hands. The trust-minimized cross-chain settlement seat is the one still open. That's the seat we're building for: sealed-bid RFQ plus HTLC atomic settlement, exposed to agents as an MCP server, no bridge and no custodian.

Where we actually are, stated plainly: Ethereum mainnet is live end-to-end today. Sui contracts are deployed and CLI-tested, with gateway wiring in progress - not mainnet-live for agents yet. Bitcoin is validated on signet, mainnet pending. "Rails ready, trains coming" - and we'd rather be exact about that than round up.

Why the distinction matters if you're building agents

If you're wiring an autonomous agent to touch value, the practical takeaway is to separate two questions you might otherwise merge: can my agent sign and move its own assets? and what guarantees the other side of a trade with someone I don't trust? A wallet MCP answers the first. It does not answer the second, and no amount of simulation-before-signing changes that, because simulation checks your own transaction, not the counterparty's follow-through. For same-party operations, a signer is the whole answer. For a trade between strangers, you need something that binds both legs.

Docs and the six-tool settlement MCP: https://hashlock.markets/docs?utm_source=devto&utm_medium=article&utm_campaign=2026-07-15-wallet-signer-vs-settlement-layer

The academic version of the argument, with the protocol worked out formally, is in our SSRN paper: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722

Question for the builders: as agents get their own wallets, where do you think the settlement guarantee should live - inside each wallet, or as a shared protocol layer underneath all of them? Curious how you'd draw the line.

Agent payments crossed 160M transactions. Every one settled on one chain. That's the gap.

Baris Sozen — Tue, 14 Jul 2026 06:07:42 +0000

Agent-to-agent payments just crossed 160 million transactions on x402, the HTTP-402 micropayment protocol Coinbase seeded and the Linux Foundation now hosts. The backer list reads like a who's-who of payments infrastructure: Cloudflare, Stripe, AWS, Google, Visa, Circle, Solana. AWS wired x402 into CloudFront and WAF this June. There's an app store (Agent.market) with OpenAI, Bloomberg, and CoinGecko as providers. Roughly 69,000 active agents, on the order of $50M in tracked volume.

By any honest measure, the "agents can pay for things" problem is being solved in public, fast.

Here's the part that gets lost in the headline: every one of those 160M transactions settled in a single token, on a single chain. Overwhelmingly USDC on Base. That is exactly what x402 is for, and it is very good at it. But it quietly assumes away the hardest case in machine commerce.

A payment is not a trade

A payment moves one asset in one direction: I pay you USDC for an API call. There's a payer and a payee, and the only question is whether the money arrives.

A trade is a different animal. Two assets, two directions, two counterparties who don't trust each other. Agent A has ETH and wants BTC. Agent B has BTC and wants ETH. Now there are two questions, and they're linked: does each leg arrive, and what stops whoever goes second from simply taking the first leg and walking?

That second question is the whole game. It's the reason human finance grew an entire industry of intermediaries: clearing houses, custodians, escrow agents, exchanges. Their job is to stand in the middle and hold the money so neither side has to trust the other.

The moment you cross a chain boundary, the problem gets worse, not better. USDC-on-Base to USDC-on-Base is one ledger. ETH-to-BTC is two ledgers that share no common settlement layer and no shared clock. There is no single place where both sides of that trade can be made to happen at once.

Who's holding the money at the moment it clears?

This is the question I'd put to every agent-commerce stack shipping right now, and it cuts cleanly:

Bridges lock your asset on chain A and mint or release a representation on chain B. For the duration, the bridge contract holds the real funds. Bridges are the single most-drained category of infrastructure in crypto history, for exactly this reason: they're a standing pile of other people's money.
Custodial settlement (the Fireblocks / Copper model, and the newer agent-native custody stacks) is trust-minimized-by-reputation, not by construction. Someone holds the float.
Escrow contracts with an evaluator hold both deposits and release on a judge's decision. Great for subjective deliverables; for a swap it just relocates the trust to the judge.

In all three, there is a moment - the moment of settlement - where a third party controls funds that belong to the two people actually trading. That moment is the honeypot. It's where the money goes missing.

The primitive that removes the holder

There's a settlement construction that predates all of this and removes the middleman by design: the hash-time-locked contract (HTLC).

The mechanism is small enough to hold in your head:

Agent A picks a random secret s and computes H = SHA-256(s). It locks its ETH in a contract that will release to B only if someone presents a value that hashes to H.
Agent B sees H on-chain and locks its BTC in a contract that will release to A only against the same H - with a shorter refund timeout than A's.
Agent A claims the BTC by revealing s. The act of claiming publishes the secret on the Bitcoin chain.
Agent B reads s from that transaction and uses it to claim the ETH.

Either both legs complete against the one secret, or nothing does and both sides refund when their timelocks expire. No bridge holds the funds. No custodian holds the float. No evaluator votes. The safety comes from a hash preimage and two clocks, not from trusting a party in the middle.

The mental model I keep coming back to: PayPal made it safe to pay strangers online. The missing layer makes it safe to trade with strangers on-chain - and the difference is that nobody holds your money. Your money never leaves your wallet until theirs arrives.

Why this is complementary to x402, not competitive

It would be easy - and wrong - to frame this as "x402 vs HTLC." They're different layers.

x402 is a payment-initiation rail. It answers "how does an agent pay for this?" and it's winning at that. HTLC settlement answers "how do two agents swap assets across chains without a holder?" One sits on top of the other. In a mature agent economy you want both: rails to move value in the common case, and a trust-minimized settlement layer underneath for the cross-chain, two-sided case a rail can't express.

Saying "the rails are here" and "the cross-chain settlement layer is still an empty seat" are both true at once. The 160M number is evidence for the first claim, not against the second.

Where this actually stands (no overclaiming)

Because this space is full of roadmap-as-reality marketing, the honest status:

Ethereum mainnet: live end-to-end today. Agents can run atomic HTLC swaps through an MCP server exposing 6 tools (@hashlock-tech/mcp, current npm 0.4.1).
Sui: contracts deployed and CLI-tested. Gateway wiring is in progress. Not mainnet-live for agents yet.
Bitcoin: validated on signet, mainnet pending.
Roadmap beyond that (Base, Arbitrum, Solana, TON) is roadmap, and labeled as such.

If you want the mechanism in depth, the docs are at hashlock.markets/docs, and the formal treatment of the settlement design is in the SSRN whitepaper.

The question

160M payments is a real milestone and the agent economy is better for it. But payments and settlement are not the same layer, and the second one is still mostly unbuilt.

So I'll ask the thing the headline skips: what's the first agent-to-agent workflow you can name where two agents need to swap assets across two different chains - and what are you trusting to hold the money while it clears?