DEV Community: Baris Sozen

The Free Option Hiding Inside Every Atomic Forward (and What It Costs to Close It)

Baris Sozen — Mon, 17 Aug 2026 10:08:22 +0000

Seven years ago today - 17 August 2019 - Runchao Han, Haoyu Lin and Jiangshan Yu filed ERC-2266, "Atomic Swap-based American Call Option Contract Standard." It is still marked Last Call in the EIP repository. Its motivation section contains the sentence that anyone building forward settlement on hash-time-locked contracts eventually has to reckon with:

the HTLC-based Atomic Swap has optionality. More specifically, the swap initiator can choose to proceed or abort the swap for several hours, which gives him time for speculating according to the exchange rate.

We wrote up how an atomic forward works a while back: keep the hashlock, keep the timelock, add a third knob that gates the claim path so it is only valid inside a window [forward_start, timeout). Two parties fix terms at T+0 and settle at T+24h, and no custodian holds the gap in between.

That post covered the mechanism. This one covers what the mechanism costs. It is the harder half, and it is the half most settlement writeups skip.

The asymmetry

Recall who does what in a two-leg swap.

The initiator picks a random secret s, publishes H = SHA-256(s), and funds their leg. The participant sees H, funds their leg against the same hash, and waits. Both legs can only be claimed by revealing s.

Now notice: only one party knows s. The initiator can reveal it and complete the trade, or sit on it and let both legs time out and refund. The participant cannot force completion either way. They can only wait.

For the entire duration of the claim window, the initiator holds a right without a corresponding obligation. That is the textbook definition of an option. The strike is the agreed exchange rate. The expiry is the timeout. And the initiator paid nothing for it.

Han, Lin and Yu formalized this in On the optionality and fairness of Atomic Swaps; the observation itself traces back to a January 2019 lightning-dev thread that ERC-2266 cites. The conclusion is unambiguous: an HTLC atomic swap is an American call option with a premium of zero.

Why spot gets away with it and forwards do not

A ten-minute spot swap has this same defect. Almost nobody prices it, and for good reason - the option is worth very little over ten minutes.

Use the standard at-the-money approximation for option value, V ≈ 0.4 · σ · S · √T, where σ is annualized volatility, S is notional, and T is time to expiry in years. Take σ = 60%, a plausible annualized figure for a liquid crypto pair, and hold everything else fixed:

Claim window	T (years)	Option value as % of notional	In bps
10 minutes	1.90e-5	0.105%	~10 bps
1 hour	1.14e-4	0.256%	~26 bps
24 hours	2.74e-3	1.256%	~126 bps

The scaling is √T, so the ratio between the 10-minute case and the 24-hour case is √144 = 12. Twelve times the free optionality, from the single design change that makes a forward a forward.

Two caveats, stated plainly. This approximation ignores drift, skew, and the fact that a real counterparty has to actually be watching and willing to act. And 60% annualized vol is an assumption, not a measurement - halve it and every number in that table halves. The level is illustrative. The √T scaling is not; it is a property of the model, and it holds whatever σ you plug in.

The uncomfortable comparison is the one against our own usual argument. We spend a lot of words on custodial settlement pricing counterparty risk at roughly 8-10 bps versus atomic settlement compressing toward 1-2 bps. If a 24-hour forward hands one side ~126 bps of unpriced optionality, that gap is not the dominant term. The optionality is. Anyone selling you atomic forwards on the fee argument alone is selling you the wrong number.

Three ways to close it, each with a real cost

1. Charge a premium. This is ERC-2266's answer, and it is the most principled one. The initiator deposits a premium alongside their asset. The participant redeems that premium if they participate honestly and the initiator then walks away; the initiator gets it back only if the participant never participates at all. The option stops being free, so the arbitrage stops being free.

Cost: you now have three locked balances instead of two, and you have to price the premium. Pricing it correctly means agreeing on volatility - which means an oracle, or a negotiation, or a hardcoded table that will be wrong. ERC-2266 specifies the mechanism and leaves the pricing to you. That is honest of it, and it is also the hard part.

2. Shorten the window. Option value falls as √T, so cutting a 24-hour forward to 4 hours removes about 59% of the free optionality. Cheap, requires no new contract logic.

Cost: you gave up most of the reason to want a forward. If the agent needed T+24h because its treasury rebalances daily, a 4-hour window does not serve it.

3. Bond the initiator. Require slashable stake, forfeited on non-reveal. Economically similar to a premium, but the collateral is posted once against a reputation rather than per-trade. This is the direction our Execution Rewards primitive points, and it composes with a verified counterparty layer - a bonded, identified initiator has more than one trade at risk.

Cost: it only works against counterparties who have something staked. For an anonymous one-shot counterparty it does nothing, and "agents can trade with strangers" is supposed to be the point.

None of the three is free. That is the actual finding.

Four things we are not going to hide

Beyond optionality, an atomic forward carries constraints that a custodial forward does not:

Capital lockup for the full window. Both legs sit idle from T+0 to settlement. The counterparty risk you removed is paid for in opportunity cost, and over 24 hours on a large notional that is not nothing.
Both legs must be on-chain. HTLCs cannot bind a leg that settles in a bank account. Anything with a fiat leg needs a different instrument.
Liveness. Someone has to be online inside the window to reveal and to claim. An agent that crashes at hour 20 of a 24-hour forward gets a refund, not a settlement. That is safe, but it is not the outcome anyone wanted.
Timeout ordering eats the window. The second mover needs an earlier refund deadline than the first mover, with enough margin to survive a fee spike or a reorg near the deadline. Those safety margins come out of the usable claim window, so the window you advertise and the window you actually get are not the same number.

Where this actually stands

Forward Settlement is a designed primitive in our roadmap, not a shipped product. We are not going to describe it as live, because it is not. What is live: Ethereum mainnet, end-to-end. Sui contracts are deployed and CLI-tested but not live. Bitcoin is signet-validated with mainnet pending. The MCP server (hashlock-tech/mcp (scoped), currently 0.6.0) exposes six tools against what is actually running.

The reason to publish the cost analysis before the feature is that the analysis is what determines whether the feature is worth building the way we sketched it. If we cannot answer "who pays for the optionality," a forward is a nicer-sounding version of a worse trade.

Mechanism writeup and the academic grounding: hashlock.markets/methodology · SSRN whitepaper · github.com/Hashlock-Tech/hashlock-mcp

If you were writing the settlement layer an autonomous agent trades through: premium, shorter window, or slashable stake? And what would you want the agent to be able to see about that choice before it agrees to the trade?

Your Agent Locked the Payment. Who Decides When It Gets Released?

Baris Sozen — Sat, 15 Aug 2026 06:07:33 +0000

Two agents agree on a trade. The buyer's funds go into a contract. The seller's side is pending. Now answer one question: who decides when the money comes out?

That question sounds procedural. It is actually the entire design of a settlement layer, and this week the agent-economy ecosystem answered it four different ways without quite noticing it was answering the same question.

Signal 1: x402 volume collapsed, and Cloudflare built on it anyway

x402 settlement volume is down roughly 93% year-to-date. The seven-day average sits near $41,800, with the most recent provisional daily figure around $28,400. That is a long way from the late-2025 surge, which in hindsight looks like it was mostly testing rather than sustained demand.

At the same time, Cloudflare launched its Monetization Gateway on July 1, letting customers charge for webpages, APIs, datasets, and MCP tools, priced and enforced at the network edge, with usage metered and payments settled in stablecoins over x402.

Those two facts are not in tension. They tell you where the protocol actually is: speculative volume drained out, infrastructure adoption went up. A rail that a CDN embeds at the edge is not a dead rail. It is a rail moving from demo phase to plumbing phase, which is a downgrade in narrative and an upgrade in seriousness.

Note what the Cloudflare integration prices, though: access. You pay, you get the API call. Delivery and payment are effectively simultaneous because the deliverable is a HTTP response. There is no gap in which anyone needs to decide anything.

Signal 2: the IMF wrote it down

The IMF published a note on how agentic AI will reshape payments (Note 2026/004). Whatever your view of the analysis, the existence of the document is the signal. Institutions do not write notes about categories they consider hypothetical. The agent economy has moved from "interesting if true" to "modeled by people who set policy."

Signal 3: Kustodia shipped escrow as MCP tools, with a sharp thesis

Kustodia made its agent escrow infrastructure generally available, exposing the full escrow lifecycle as MCP tools so an agent can create an escrow, lock funds, monitor for delivery confirmation, and release payment without a human authorizing each step.

Their framing of the gap is worth quoting in substance, because it is correct: payment protocols including x402, AP2, and Stripe's machine payments handle payment initiation, but none of them provide a mechanism for holding funds between an agent's commitment to deliver and confirmed completion.

That is the gap. Their answer is: hold the funds, and give someone the release decision.

Signal 4: ERC-8183 named the decider

ERC-8183 formalizes a Job primitive with three parties, identified only by wallet address: Client (creates the job and locks the reward), Provider (does the work and hashes the deliverable on-chain), and Evaluator (reviews, then pays or refunds). A job moves Open → Funded → Submitted → Terminal, where Terminal is Completed, Rejected, or Expired.

The standard is careful not to say what an Evaluator is. It can be an LLM, a ZK circuit, a multisig, a DAO. That flexibility is the point. But structurally, the standard encodes a role whose job is to make a judgment call about whether funds move.

The shared assumption

Escrow with a release decision. An Evaluator that pays or refunds. Dispute handling in agent payment protocols. Different vocabularies, same architecture: a third role in the loop whose function is to decide.

And for most of what these protocols target, that is the right architecture. I want to be precise about this rather than score a point.

If the deliverable is work, as in "did this agent write code that passes the spec", "did the freelancer ship the design", "was the dataset what was promised", then there is no cryptographic proof of quality. Quality is a judgment. Somebody has to make it. An escrow contract with an Evaluator is not a compromise there; it is the correct primitive, and pretending otherwise would be dishonest. ERC-8183 and Kustodia are solving a real problem well.

Where the decider becomes a dependency instead

The picture changes when the deliverable is the asset transfer. Agent A sends ETH, Agent B sends the other leg. Nothing needs to be judged. There is no quality dimension. The only question is whether both legs happened.

At that point, an Evaluator stops being a necessary component and becomes a liability surface. The Evaluator can be slow. It can be unavailable. It can be captured, coerced, or simply wrong. And every agent in the system now inherits a trust assumption it did not ask for: not "will the counterparty perform" but "will the adjudicator adjudicate correctly."

Hash time-locked contracts remove that role rather than improving it. The release condition is a hash preimage. Reveal the secret and claim your leg, and the act of claiming publishes the secret that lets the counterparty claim theirs. Miss the timeout and both sides refund. There is no dispute path because there is nothing to dispute. The state machine has exactly two exits and neither of them requires a human, a committee, or a model to have an opinion.

That is what we build at Hashlock Markets: sealed-bid RFQ for price discovery without information leakage, fused with HTLC atomic settlement. Six MCP tools, so an agent calls it the same way it calls any other tool. No bridge, no custodian, no adjudicator.

Chain status, stated precisely: Ethereum mainnet is live end-to-end. Sui contracts are deployed and CLI-tested, with gateway wiring in progress, not live. Bitcoin is signet-validated with mainnet pending.

The honest limitations

HTLCs are not free and I would rather you hear the tradeoffs from us:

Timeout risk. Locks expire. Get the timelock ordering wrong across two chains with different block times and you can create a window where one side is exposed.
Capital lockup. Funds are immobilized for the duration of the lock. On a slow leg, that is real opportunity cost.
Both legs must be on-chain. If one side of the trade is a promise about the physical world or about work quality, no hash solves that. Go get an evaluator.
Liveness assumptions. The claiming party has to actually claim within the window. An offline agent can refund itself into a missed trade.

The design claim is narrow on purpose: for the subset of agent commerce where value moves against value, the release decision can be made by math instead of by a role. Outside that subset, escrow is the better tool and we would rather say so than oversell.

The question worth asking before you pick

When you are wiring settlement into an agent, ask what the deliverable actually is. If it is a judgment, you need an Evaluator and you should choose a good one. If it is an asset transfer, ask why there is a decider in your architecture at all, and what happens on the day that decider is unavailable.

Which one is your agent actually doing? And if it is the second one, what is your adjudicator's downtime plan?

Links

Hashlock Markets: https://hashlock.markets/methodology?utm_source=devto&utm_medium=article&utm_campaign=2026-08-15-who-decides-release
MCP server (npm, scoped): hashlock-tech/mcp - https://www.npmjs.com/package/@hashlock-tech/mcp
GitHub: https://github.com/Hashlock-Tech/hashlock-mcp
Whitepaper (SSRN): https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722

Sources for the signals above

x402 volume decline and Cloudflare Monetization Gateway: CryptoPotato, The Defiant
IMF Note 2026/004, How Agentic AI Will Reshape Payments: IMF
Kustodia agent escrow MCP tools: Cointelegraph
ERC-8183 Agentic Commerce: eips.ethereum.org

What It Actually Takes to Let an AI Agent Click 'Connect' Instead of Copying an API Key

Baris Sozen — Fri, 14 Aug 2026 09:54:49 +0000

Yesterday we shipped @hashlock-tech/mcp v0.6.0. The headline feature is a hosted remote MCP server with one-click OAuth. The less glamorous but more important part is what had to ship alongside it: rate limiting and an untrusted-input flag, both landed the same day as the OAuth work. This post is about why those three things are one release, not three.

The problem with "just run the server locally"

Until this release, using Hashlock's MCP tools meant installing the package, running the stdio server, and configuring credentials by hand. That's a fine workflow for a developer testing tool calls in Claude Desktop. It's a bad workflow for an agent that needs to onboard a new counterparty, or for a team that wants to point five different agent frameworks at the same settlement backend without redistributing a secret to each one.

A hosted endpoint fixes the distribution problem. It creates a new one: now the endpoint is public, and "public MCP server that can trigger on-chain settlement" is a phrase that should make you nervous.

One header does the heavy lifting

The one-click part of "one-click OAuth" comes down to a single HTTP header. When an unauthenticated client hits the endpoint, it gets a 401. Previously that 401 was a bare bearer challenge: useful to a human reading logs, useless to a client trying to self-serve.

As of this release, the 401 carries resource_metadata in the WWW-Authenticate header, per RFC 9728 (OAuth 2.0 Protected Resource Metadata). An MCP client that understands this can fetch the metadata document, discover the authorization server, dynamically register itself, and run the OAuth 2.1 + PKCE flow, all without a human copying an API key into a config file.

The pointer comes from an MCP_PUBLIC_URL environment variable. If it's unset, the header degrades gracefully back to the old bearer challenge rather than advertising a wrong origin. Small detail, but it's the difference between "breaks obviously" and "breaks silently by pointing clients at a URL that doesn't exist."

Why the security commits aren't optional extras

We could have shipped OAuth alone and called it a feature release. We didn't, because making the endpoint public changes the threat model in two specific ways.

First: an unauthenticated endpoint needs its own rate limit. The API already rate-limits per API key, but that protection only activates once a credential is presented. Before this release, nothing stood in front of the endpoint itself. The new limiter buckets by API key when one is sent, and by client IP otherwise, so callers behind a shared NAT don't all share one bucket. The IP is read from the right-most entry in X-Forwarded-For, not the left-most: the left-most value is exactly what a caller would spoof and rotate to defeat the limit, which is the same finding our API's existing limiter already accounts for. It's in-memory with an opportunistic sweep, which is correct for a single container and would need a shared store if this ever runs scaled out. Default ceiling is 240 requests/minute, configurable via MCP_RATE_LIMIT_MAX.

Second: counterparty chat needed an explicit untrusted-input flag, not just a code comment. Hashlock's negotiation flow lets counterparties exchange messages as part of a trade. The stdio server carried a warning about this in a source comment, which is exactly as useful as a warning nobody reads, because it never reaches the model. Thread messages are the one field in the entire protocol that an adversarial counterparty fully controls. Left unflagged, text smuggled into a chat message is a real prompt-injection vector: it could push an agent to accept terms it shouldn't, or worse, to claim a leg before the counterparty has actually funded theirs. Claiming early reveals the hash preimage, which lets a bad-faith counterparty take the other leg and refund their own, turning an atomic swap into a one-sided loss. The fix ships the warning in both the tool result and the tool description, so it reaches the model at the point where it matters instead of sitting in a comment only a human reads.

Both of these commits are co-authored by Claude Opus 5 (1M context) in the git history, worth naming because it's a concrete instance of an AI model doing security review on the settlement paths it's also capable of calling, not a hypothetical.

What changed under the hood

For anyone tracking the release mechanically: server.json's registry version moved from 1.5.1 to 1.6.0, and packages[0].version tracks package.json directly, which the registry publish workflow verifies before anything goes out. Before this release, npm and the MCP Registry both sat at 0.5.1, a version that predates the hosted server, the OAuth flow, the rate limiter, and the untrusted-input notice entirely. Anyone who installed from npm got the stdio server with none of these fixes, security-relevant ones included.

What this doesn't change

To be precise about scope: this release is protocol and transport infrastructure. It doesn't add a new chain. Hashlock's HTLC settlement is live end-to-end on Ethereum mainnet; Sui contracts are deployed and CLI-tested with gateway wiring in progress; Bitcoin is validated on signet with mainnet pending. The hosted MCP endpoint makes it easier to reach those settlement paths. It doesn't change which chains are live.

Where this leaves things

The honest framing here is "rails ready, trains coming." A hosted MCP endpoint with one-click OAuth removes a real piece of onboarding friction for agents that want to hold their own keys instead of trusting a custodian with them. It doesn't yet tell you how many agents are actually connecting through it. That's a metric we'll have real numbers on in future updates, not this one.

If you're building an agent that needs cross-chain settlement without a custodian in the loop: what's the actual blocker right now? Local server setup, OAuth support in your MCP client, or something further upstream, like counterparty discovery?

Docs: https://hashlock.markets/docs?utm_source=devto&utm_medium=blog&utm_campaign=2026-08-14-hosted-mcp-oauth
GitHub: https://github.com/Hashlock-Tech/hashlock-mcp?utm_source=devto&utm_medium=blog&utm_campaign=2026-08-14-hosted-mcp-oauth
npm: https://www.npmjs.com/package/@hashlock-tech/mcp
SSRN: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722

Custodial Settlement or Atomic Settlement: What Does the Agent Economy Actually Need?

Baris Sozen — Thu, 13 Aug 2026 06:17:56 +0000

Every AI agent that needs to move value across chains eventually runs into the same open question: who do you trust to make sure the other side of the trade actually happens? Two architectures are answering that question right now, and they answer it in almost opposite ways.

Custodial infrastructure: BitGo, Fireblocks, Copper

BitGo launched an MCP server in March 2026, joining Fireblocks and Copper in offering agents a familiar answer: give the agent API-scoped access to a regulated custodian, and let the custodian hold the keys, enforce policy, and absorb the operational risk. This is real infrastructure, not a stopgap. It brings insurance, compliance tooling, and a legal entity an institution can point to if something goes wrong. For a team that needs an audit trail a regulator will accept today, that's not a small thing.

The tradeoff is structural, not a matter of execution quality. An agent using custodial rails isn't verifying that a trade settled - it's trusting that the custodian's internal ledger matches reality, and that the custodian will honor a claim if it doesn't. That trust is usually well placed. But it's still trust, extended to a party the agent has no independent way to audit in real time, one instruction at a time, thousands of times a day.

Atomic settlement: HTLC on Ethereum mainnet

Hash-time-locked contracts take a different approach to the same problem: instead of routing trust through a custodian, remove the point in the flow where trust is required at all. Both parties lock funds in a smart contract. A cryptographic secret reveals atomically - either both legs settle or both refund after a timeout. There's no moment where one side can walk away with the other's funds, and there's no ledger to audit because the outcome isn't recorded by a party, it's enforced by the contract itself.

Hashlock runs this model live on Ethereum mainnet today: sealed-bid RFQ for price discovery, HTLC for atomic settlement, no bridge and no custodian in the flow. (Sui contracts are deployed and CLI-tested, gateway wiring in progress. Bitcoin is signet-validated, mainnet pending. Only the Ethereum mainnet claim is "live end-to-end" - worth being precise about, since the two models being compared here are both real infrastructure, not one shipped product versus one roadmap slide.)

What atomic settlement doesn't solve on its own

Removing counterparty risk from the settlement mechanics doesn't answer a different question custodians also handle: how does an agent know who it's even trading with before it commits capital? A custodian's onboarding process does double duty - it verifies identity and it backstops the trade. HTLCs backstop the trade. They don't verify identity.

This is the gap a verified counterparty directory is built to close - a registry an agent can check before entering a trade, so it has some basis for confidence in who's on the other side, independent of whether that party is KYC'd by a bank. The settlement guarantee doesn't depend on the directory being perfect or complete; HTLC atomicity holds regardless of who the counterparty turns out to be. The directory just gives an agent a reason to enter the trade in the first place, rather than screening blind. This primitive is architecture, not a claim about an existing user base - we don't have agent customers running through it at volume today. Rails ready, trains coming.

An emerging industry signal

This tension between custody and cryptographic finality isn't just a Hashlock talking point. The Agentic Risk Standard (ARS) - a joint research effort from Google DeepMind, Microsoft Research, Columbia, Virtuals Protocol, and t54 Labs - proposes three vault types for agent transactions: fee escrow, collateral, and reimbursement payout. That's a research group outside the Hashlock ecosystem independently converging on the idea that agent settlement needs collateral structures beyond raw custodial trust. It's a signal worth taking seriously, not proof that any specific implementation - ours included - is the final answer.

Being honest about both sides

Custodial settlement wins on legal recourse. If a trade goes wrong and someone needs to be held accountable in a way a court recognizes, a regulated custodian is built for exactly that. Atomic settlement wins on verifiability - the agent doesn't have to trust anyone's word, including ours, because the guarantee is enforced by the contract, not asserted by a party. Atomic settlement also has real costs of its own: capital sits locked for the duration of the swap, settlement is bounded by block time rather than instant, and the model depends on both parties actually acting within the timeout window.

Neither architecture makes the other obsolete. They're solving overlapping but distinct parts of the same problem - one through legal and financial backstops, the other through cryptographic guarantees. The interesting question isn't which one wins outright. It's which parts of agent-to-agent commerce end up needing which guarantee, and whether that split stays fixed or shifts as agent trading volume grows past what either model was originally designed for.

What's your take? Does the agent economy converge on custodial infrastructure at scale because compliance requires it, or does atomic settlement replace the need for a custodian entirely once verification is solved separately? Curious what people actually building agent-to-agent commerce are seeing.

References:

Methodology: https://hashlock.markets/methodology
SSRN whitepaper: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722
GitHub: https://github.com/Hashlock-Tech/hashlock-mcp
npm: https://www.npmjs.com/package/@hashlock-tech/mcp (0.5.1 as of this writing, unchanged in the past 15 days per today's registry check)

UTM: utm_source=devto&utm_medium=blog&utm_campaign=2026-08-13-custodial-vs-atomic-settlement

The Hidden Tax on the Agent Economy: What Trust Actually Costs in Basis Points

Baris Sozen — Wed, 12 Aug 2026 11:39:51 +0000

PayPal made it safe to pay strangers online. It did that by inserting itself as a trusted intermediary and charging for the service. That fee is small per transaction and easy to ignore - until you're doing the transaction a million times a year, autonomously, with no human checking each one.

That's the position AI agents doing cross-chain trading are in today. Every settlement path available to them either requires a custodian or a legal system standing behind the trade. Neither of those exists for an autonomous agent. So it's worth asking plainly: what does trust actually cost, in basis points, and what happens to that cost as agent-to-agent commerce scales past human trading volume?

The spread is a risk premium

Custodial OTC desks and CEX-style settlement typically price counterparty risk somewhere in the range of 8-10bps per trade. That number isn't arbitrary - it's the desk pricing in the cost of the things that make trust possible: compliance overhead, a legal entity you could sue if they misbehave, insurance, and a human relationship that took time to build. For a trader doing a handful of large trades a month, that spread is a reasonable price for peace of mind.

For an autonomous agent doing thousands of small trades a day, none of that infrastructure is available anyway. Agents don't have standing to sign an ISDA agreement or a legal identity a court recognizes. So today, an agent that wants to trade either routes through a custodian and pays the spread on infrastructure it can't actually use if things go wrong, or it trades peer-to-peer and simply eats the counterparty risk with no recourse at all. Neither is a real answer.

Removing the party you'd pay to hold the risk

Hash-time-locked contracts (HTLCs) change the shape of the problem instead of trying to make agents legally capable of trust relationships. Both sides lock capital in a smart contract. A cryptographic secret reveals atomically - either both legs settle or both refund after a timeout. There's no point in the flow where one party can walk away with the other party's funds. The settlement is enforced by math, not by a custodian's balance sheet or a court's willingness to enforce a judgment.

That changes what you're paying for. You're no longer paying a fee that compensates someone for absorbing counterparty risk, because there's no counterparty risk left to absorb in the way a custodial spread prices it. Hashlock's architecture - sealed-bid RFQ for price discovery, HTLC for atomic settlement - is designed to compress that spread toward 1-2bps. That's a design target grounded in removing the intermediary, not an audited historical benchmark across live agent volume yet. We don't have agent customers running that volume today - rails ready, trains coming - so treat it as the economics the architecture is built to produce, not a claim about traffic we've already seen.

Why the gap matters more as volume grows

At the volume a human trader generates, the difference between an 8-10bps spread and a 1-2bps spread is close to noise. At the volume an autonomous agent can generate - continuous, high-frequency, no fatigue - that gap compounds. A settlement layer that's 6-8bps cheaper per trade isn't a marginal optimization once you're doing thousands of trades a day; it's the difference between a viable trading strategy and one that gets eaten alive by its own settlement costs.

This is also why "trustless OTC settlement" and "agent-to-agent payment protocol" keep showing up as searches without clear, direct answers yet - most of the infrastructure being built for agent commerce right now is a payment rail (get money from A to B, often through a facilitator or merchant relationship), not a settlement layer built specifically for two parties who don't know or trust each other to atomically exchange value across chains. Those are genuinely different jobs. A payment rail optimizes for reach and integration ease. A settlement layer optimizes for removing counterparty risk without adding a custodian back in through the side door.

What this doesn't solve

HTLCs aren't free of tradeoffs, and it's worth saying so directly. Capital is locked for the duration of the swap - that's a real cost, and it's a different kind of cost than a spread, one that scales with how long your funds sit idle rather than with trade count. Settlement is asynchronous, bounded by block times rather than instant. And the model depends on both parties actually being on-chain and ready to act within the timeout window; a counterparty who goes silent doesn't cost you your funds (you refund), but it does cost you the time your capital was locked doing nothing.

None of that is a reason to prefer custodial spreads. It's a reason to be precise about what "cheaper" means: cheaper in the risk premium you're paying, not free of every cost a settlement system can have.

The academic case, not just the pitch

This isn't just a positioning claim - the atomicity guarantees and the settlement model are documented formally in our SSRN paper (linked below) and in the underlying methodology published on the site. If you're deciding whether to build against this model, read the mechanism design directly rather than taking a blog post's word for it.

What's your read? Does the cost of trust compress as agent trading volume grows, or does it just relocate to a different part of the stack - identity verification, reputation systems, insurance pools? Curious what people building agent-to-agent commerce are seeing.

References:

Methodology: https://hashlock.markets/methodology
SSRN whitepaper: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722
GitHub: https://github.com/Hashlock-Tech/hashlock-mcp
npm: https://www.npmjs.com/package/@hashlock-tech/mcp (currently 0.5.1)

UTM: utm_source=devto&utm_medium=blog&utm_campaign=2026-08-12-cost-of-trust-agent-settlement

Who Holds the Overnight Risk on an AI Agent's Forward Trade?

Baris Sozen — Tue, 04 Aug 2026 06:07:41 +0000

Your OTC desk agrees a price today and settles tomorrow, and everyone sleeps fine. Not because the overnight risk disappeared. It never disappears. Someone is always holding it - and in traditional finance, the holder has a name.

Between agreement and settlement, the risk that your counterparty fails to deliver is carried by a very specific stack: a credit department that decided how much exposure to allow you, an ISDA master agreement that defines what happens if you default, collateral posted against the position, and, at the bottom of everything, a court system that can seize assets from a legal entity. T+1 is not safe because nothing can go wrong overnight. It is safe because when something goes wrong, there is a person to sue.

What the gap costs when the holder fails

Finance learned the price of that gap in September 2008. When Lehman Brothers filed for bankruptcy, it was a counterparty on roughly 900,000 open derivatives trades - forwards, swaps, options, all instruments that live in the space between agreement and settlement. Every one of those trades had Lehman's balance sheet as the thing holding the gap. Unwinding the book took more than a decade of litigation across multiple jurisdictions.

The regulatory response was not to close the gap. It was to give the gap a stronger custodian. The G20 pushed standardized OTC derivatives into central clearinghouses, mandated initial and variation margin, and in the process made CCPs some of the most systemically important institutions on the planet. It broadly works. But notice what every layer of the solution assumes: counterparties that have legal names, sign master agreements, maintain margin accounts, and can be pursued through courts when they fail.

The counterparty that can't be sued

Now put an autonomous agent on one side of that forward.

An agent has a wallet and a signing key. It does not have a legal name. It cannot sign an ISDA master agreement. It cannot open an account at a clearinghouse, because clearinghouse onboarding is built for regulated entities with balance sheets and compliance officers. And if it defaults, there is nothing to sue - a fresh wallet has no assets to seize and no reputation it cannot abandon.

Every tool traditional finance uses to hold overnight risk assumes legal personhood. Agents have none. Which explains the shape of today's agent-payment landscape: almost every rail an agent can reach settles on the spot, in the next block or two. Spot swap, spot payment, spot escrow. "Settle now" is the only thing the stack can say safely, because "settle later" requires someone to hold the gap - and there is no one.

That is a real expressiveness loss. Forwards exist because "now" and "later" are genuinely different needs: hedging a known future obligation, matching a payment schedule, locking a price ahead of expected volatility. An agent economy that can only settle on the spot cannot express one of the oldest instruments in finance.

Holding the gap with code instead of a balance sheet

There is a third option between "trust a balance sheet" and "spot only": make the settlement itself atomic at the forward date.

The mechanism is one added constraint on a hash-time-locked contract. A standard HTLC already has two knobs: a hashlock (the claim requires revealing a secret) and a timelock (if nothing happens, both sides refund). A forward adds a third: the moment the claim becomes valid. Both parties lock their legs at agreement time, but the withdraw path only opens inside a window - from the agreed settlement date until the timeout. Before the window, neither side can pull the trade forward. Inside it, settlement is atomic: one claim reveals the secret that unlocks the other leg. After it, if settlement never happened, both sides refund.

Walk through what happened to the overnight risk. Between agreement and the settlement window, neither party is exposed to the other's balance sheet, because there is no balance sheet in the middle - both legs sit locked in contracts with deterministic refund paths. Your money never leaves your wallet's control in the sense that matters: no custodian holds it, and the worst-case outcome is your own funds coming back after the timeout. Default, in the traditional sense of "my counterparty owes me delivery and cannot pay," stops being an event category. It is not forbidden. It is unexpressible.

The honest ledger

This design pays for that property, and it is worth being precise about the price.

Full collateralization. A cleared forward in traditional finance is margin-efficient - you post a fraction of notional. An atomic forward locks the full notional on both sides for the entire gap. That is real opportunity cost, and for leveraged trading desks it may be the wrong trade. For an agent that would otherwise have no safe way to express "later" at all, the comparison is not against 5% margin - it is against nothing.

Market risk stays. A forward fixes the price by design. If the market moves, one side will be settling at a worse-than-market rate. The mechanism removes counterparty risk, not price risk - exactly like any forward.

The abandonment option. The side holding the secret can choose silence: reveal nothing, let the window close, and both legs refund. The disadvantaged party never loses principal - but their capital was locked for the duration, for nothing. This is the classic optionality critique of HTLCs, and it is fair. It is also why a settlement layer needs an economic layer on top: completion bonds that an agent stakes on its commitment, forfeited to the counterparty it leaves waiting. We wrote up that mechanism - execution rewards - yesterday. The residual risk in an atomic forward is time, not principal, and time is exactly the thing a bond can price.

Where this sits

None of this competes with the payment rails being built for agents right now - HTTP-native micropayments, facilitator APIs, per-request billing. Those move a single leg for a completed service call, and they are good at it. A forward is a different object: two legs, two chains, a deliberate gap in between. That is settlement-layer work, underneath the payment layer.

At Hashlock we are building this as part of a sealed-bid RFQ protocol fused with HTLC settlement, exposed to agents as MCP tools (the server is @hashlock-tech/mcp on npm, currently 0.5.1). Status, stated precisely: the settlement core is live end-to-end on Ethereum mainnet; Sui contracts are deployed and CLI-tested, not yet live; Bitcoin is validated on signet, mainnet pending. The forward window design above is one of the five primitives we are building on that core - the mechanics are in our docs: https://hashlock.markets/docs?utm_source=devto&utm_medium=article&utm_campaign=2026-08-04-forward-otc-overnight-risk

The protocol design is written up in more depth in our whitepaper on SSRN: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722

The question

Two audiences, one question each.

If you run size through an OTC desk: would you accept locking full notional for 24 hours to delete counterparty risk entirely, or is margin efficiency the whole game - and someone to sue an acceptable substitute for certainty?

If you build agents: what is the longest gap between "agreed" and "settled" your stack can express today - and what trade did you not do because it couldn't?

Execution Rewards and Tiered KYC: The Mechanics of a Verified Counterparty Layer for Trading Agents

Baris Sozen — Mon, 03 Aug 2026 06:07:56 +0000

Atomic settlement solves theft. It does not solve time-wasting. Those are different attack surfaces, and conflating them is the most common mistake in how people reason about trust in agent-to-agent markets.

This post is a mechanics-level look at the two primitives Hashlock is designing to close the second gap: execution rewards (a stake-and-slash mechanism for quote reliability) and tiered KYC (a per-trade trust filter an agent sets itself, not a policy a custodian enforces on everyone). Both sit above the settlement core, not inside it - which matters, because it means neither one changes who can touch your funds.

The gap atomic settlement leaves open

Hash-time-locked contracts give you a clean guarantee: both legs of a trade unlock against the same secret, or neither does. Party A funds an HTLC against H = SHA256(s). The only way to claim it is to reveal s. The instant s becomes public to claim one leg, it's available to claim the other. There is no reachable state where one side's funds move and the other's don't.

That guarantee eliminates theft as an outcome. It does not eliminate griefing: an agent posts an attractive quote, watches a counterparty fund their leg, and then simply never reveals s. Nothing was stolen - the counterparty's asset is recoverable via the timelock refund path - but capital sat locked for the full timelock window for nothing. In a human market this costs the griefer their reputation. An agent spun up from a fresh wallet has no reputation to lose, so the settlement guarantee alone doesn't make griefing unprofitable.

Execution rewards: making completion the dominant strategy

The design goal is to make "reveal and settle" the cheapest strategy for a rational agent, enforced by the protocol rather than by a hosted rating system.

The mechanism, at the level we can describe it today: when an agent responds to a sealed-bid RFQ, it can post a bond sized relative to the trade - collateral it stakes on actually completing. If the trade settles (secret revealed, both legs claimed), the bond returns along with a small increment to an on-chain completion record tied to that agent's address. If the counterparty funds their leg and the quoting agent lets the timelock expire without revealing, the bond is forfeit - paid out to the counterparty that had capital locked for nothing.

A simplified sketch of the state machine:

RFQ posted (min_tier: X, size: N)
  -> Agent B quotes, optionally stakes bond B(N)
  -> Requester accepts, funds HTLC leg 1 against H
  -> Agent B funds HTLC leg 2 against same H
  -> Requester reveals s to claim leg 2
       -> Agent B claims leg 1 with same s
       -> settlement complete: bond returned + completion_count++
  -> OR timelock_2 expires before s is revealed
       -> Agent B triggers refund on leg 2
       -> bond forfeit -> paid to requester as compensation

The important property: completion_count and forfeiture history live at the settlement layer itself, not in a database a company operates. You can't reset it by spinning up a new frontend, and you can't have it edited by a platform operator - because there is no platform operator sitting between the two legs. That's the difference between "the protocol enforces the incentive" and "someone we have to trust enforces the incentive."

None of this is a claim that a slashing contract is deployed and live today. It's the design layer we're building on top of an atomic-settlement core that already is - the distinction matters and is spelled out below.

Tiered KYC: a filter the agent sets, not a gate a custodian owns

Execution rewards answer "will this counterparty actually finish." Tiered KYC answers a separate question: "how much do I need to know about this counterparty before I'm willing to trade with them at this size?"

A single global answer breaks in both directions. Force full identity verification on every trade and you've killed the permissionless, anonymous-by-default property that makes an agent-native market useful in the first place. Verify nobody and you've made every regulated or large-size flow impossible. The tiered design treats verification as a property of the counterparty pool an RFQ is allowed to reach, set per request:

Anonymous tier - wallet-only. Anyone can quote. For small size, the settlement guarantee alone is the protection; worst case is a wasted timelock window, not a stolen asset.
Attested tier - counterparty holds a credential commitment (a hash of an attestation, not raw identity data) that can be checked on-chain without revealing the underlying document to the protocol or the counterparty.
Regulated tier - counterparty has cleared identity verification at the level a specific regulated flow requires, checked before the RFQ is even visible to them.

The agent sets min_tier as a parameter on the RFQ. Nobody upstream picks a custodian to vouch for the trade; the agent picks how much verification it needs for that specific trade, and dials it up or down independently of settlement. A verified counterparty market is a filter you apply per request. A custodian is a party that takes possession. Those are structurally different things even when the marketing copy for either one uses the word "trust."

Where ERC-8004 fits and doesn't overlap

Ethereum's ERC-8004 gives agents an on-chain identity and reputation registry - a shared place to establish who an agent is and reference its track record. That's complementary infrastructure, not a competing approach: a reputation registry tells you what an agent has done; it doesn't make a specific trade atomic, and it doesn't have an economic mechanism that forfeits a griefing agent's capital at the moment it griefs. Execution rewards are narrower and more specific - they're tied to one settlement event, not a general-purpose reputation graph. The two are stackable: an agent could reference an ERC-8004 identity to satisfy a tiered-KYC attestation requirement, then still be subject to stake-and-slash at the settlement layer for that specific trade.

Honest status, stated the way we always state it

The settlement core these two primitives sit on top of: atomic settlement is live end-to-end on Ethereum mainnet. Sui contracts are deployed and CLI-tested - gateway wiring is still in progress, and we don't call that "live" until it is. Bitcoin settlement is validated on signet via P2WSH HTLC scripts; mainnet is pending. Execution rewards and tiered KYC are the counterparty-market design layered above that core - describe the mechanism, don't overclaim the deployment. This is a place where a settlement project cannot afford to drift, and a post about trust and verification is exactly the wrong place to start.

The MCP server that exposes the settlement core today - sealed-bid RFQ and HTLC creation fused into six tools - is hashlock-tech/mcp (scoped) on npm, currently at 0.5.1. Source is on GitHub.

The open design question

Where should the bond size sit relative to trade size for execution rewards to actually deter griefing without locking honest new agents out of the market? Too small and forfeiture is a rounding error; too large and you've reintroduced a capital barrier that looks a lot like the custodial minimum-balance requirements this whole design is trying to avoid.

Methodology write-up: hashlock.markets/methodology. Source: github.com/Hashlock-Tech/hashlock-mcp. Academic background on the settlement primitive: SSRN. If you've built or thought through a bonding curve for agent reliability, I'd like to hear where you'd set it.

Payment Rail vs. Settlement Layer: What AEON's Coinbase x402 Partnership Actually Validates

Baris Sozen — Sun, 02 Aug 2026 07:04:20 +0000

Every few weeks the agent-economy infrastructure race produces a data point worth stopping for. This one: AEON, which raised an $8M pre-seed round led by YZi Labs in May to build a "settlement layer for the agentic economy," became one of Coinbase's early x402 ecosystem partners and says it has shipped an x402 Facilitator and SDK on BNB Chain.

That's a real milestone, and it's worth being precise about what it proves and what it doesn't.

What x402 actually does

x402 repurposes the long-dormant HTTP 402 "Payment Required" status code so an API can demand payment inline, and an AI agent can pay it without a human clicking a button. An agent calls an endpoint, gets a 402, resolves it with a stablecoin micropayment (mostly USDC on Base so far), and the call completes. No API keys to provision, no invoice to reconcile after the fact.

That's a genuinely hard problem for the agent economy, and the volume backs up that it's being solved: on-chain data shows AI agents have executed well over 100 million payments in the past year, the large majority in USDC, with average ticket sizes clustering around $0.30-$0.50. Coinbase and Cloudflare formalizing an x402 Foundation, and a funded player like AEON building distribution across 50M+ merchants on top of it, is the payment-rail layer maturing in real time.

What it doesn't do

A payment rail settles a completed action. Agent calls API, agent pays, merchant receives funds, transaction closed. That flow assumes one side of the exchange (the API response) happens first, and payment follows - the equivalent of "buy now, pay now" for a single, atomic unit of value that either the API delivered or it didn't.

Cross-chain asset trading is a different problem. Two parties each hold an asset the other wants, on two different chains, and neither wants to send first. That's the settlement problem HTLCs (hash time-locked contracts) were built to solve back in 2013, well before "agent economy" was a phrase anyone used: both legs of the trade are locked behind the same cryptographic secret, so either both sides settle or neither does. No bridge holding funds mid-transit. No custodian standing between two parties who don't trust each other.

Payment rails don't need this property, because they're not solving a two-sided, cross-chain exchange problem. That's not a knock on x402 or AEON - it's a different layer, doing a different job, and Coinbase's own docs describe it as a payment protocol, not a settlement primitive for asset swaps.

PayPal made this safe for humans once already

The analogy we keep coming back to: PayPal's actual innovation wasn't moving money, banks already did that. It was making it safe to transact with a stranger you'd never met, by inserting itself as an intermediary both sides could trust.

Hashlock is trying to do the equivalent thing for on-chain trades between strangers, minus the intermediary. We fuse sealed-bid RFQ (so pricing isn't front-run before a trade even starts) with HTLC atomic settlement, and expose the whole flow as six MCP tools: create an RFQ, respond to one, negotiate, fund a leg, claim a leg, check deal status. An AI agent - Claude, GPT, Cursor, any MCP-compatible client - can discover a counterparty, negotiate a price, and settle a cross-chain trade without a human in the loop and without either side's funds sitting in a bridge contract waiting to be drained.

Your money never leaves your wallet until theirs arrives. That's the property a payment rail doesn't need to have, and the property we think cross-chain agent trading can't ship without.

Where the two layers actually meet

We don't think this is a competitive story. If x402-style payment rails and AP2/ACP-style intent layers keep maturing, that's more agents transacting autonomously, which is more demand for a settlement layer underneath the ones that need to swap assets across chains rather than just pay for a completed API call. Google's AP2 and OpenAI/Stripe's ACP are solving the "how does an agent express and authorize intent" problem; x402 is solving "how does an agent pay for a discrete action." Hashlock is solving "how do two parties, possibly both autonomous, exchange assets across chains without trusting each other or a middleman."

Three different layers. All three need to exist for the stack to be complete.

What we shipped

Small but real: hashlock-tech/mcp (scoped) is now at version 0.5.1 on npm. Six MCP tools, atomic settlement live end-to-end on Ethereum mainnet. Sui contracts are deployed and CLI-tested (gateway wiring still in progress - not calling that "live" until it is). Bitcoin settlement is validated on signet via P2WSH HTLC scripts, mainnet pending.

If you want the formal treatment of the sealed-bid RFQ + HTLC design, the writeup is on SSRN: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722

The question worth arguing about

If your agent stack needs to both pay for API calls and trade assets across chains, are you building or buying the settlement primitive underneath the payment rail - and does it actually need to be atomic, or is "probably fine, we'll add insurance later" good enough for what you're building?

Repo: https://github.com/Hashlock-Tech/hashlock-mcp
Try it: https://hashlock.markets?utm_source=devto&utm_medium=blog&utm_campaign=2026-08-02-settlement-layer-race

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.