DEV Community: Baris Sozen

Rails are not settlement: what the 92% x402 crater tells us about the agent economy

Baris Sozen — Thu, 18 Jun 2026 06:07:52 +0000

A number worth sitting with: x402, the agent-payment standard that cleared more than 100M payments since launch, has seen transaction volume fall roughly 92% from its November peak — about $5.15M down to $1.19M per month, per OKX Ventures' agent-economy map. In the same window, new rails kept shipping: OKX's own Agent Payments Protocol (APP), Mastercard Agent Pay, a Ripple XRPL agent kit. Volume cools, supply expands.

That looks like a contradiction. It isn't. It's what happens when an entire category builds the same primitive at once and then discovers the primitive only addresses half the problem. The half everyone is building is payment. The half almost no one is building is settlement. They are not the same job, and conflating them is why the map looks crowded while a layer underneath stays empty.

One leg versus two

A payment is one leg, one direction, one asset. An agent buys compute, a dataset, or an API call; value moves from agent to seller; the request resolves. x402 does this elegantly — an HTTP 402 response carries a payment requirement, the client pays, the resource unlocks. AP2, Mastercard Agent Pay, and the XRPL kit are variations on the same shape. For the buy-a-thing use case, this is exactly right, and the proliferation is healthy competition.

Settlement is two-sided. My asset for your asset, often across two different chains, with a binding guarantee that either both legs clear or neither does. No half-states. No "I paid, where's my side?" That guarantee — atomicity — is what makes it safe to trade with a counterparty you don't trust and have never met. A one-directional rail cannot express it, because there is no second leg for the rail to bind.

When two autonomous agents want to trade rather than pay — swap ETH for a stablecoin on another chain, agree a price now and settle later, run a multi-leg basket where every leg must clear together — a payment rail leaves the hardest part undefined: who guarantees the other side shows up?

"Settlement" that is really custody

Read the launch copy and you'll see "settlement" used freely. OKX APP advertises escrow, usage metering, settlement, and dispute resolution as a full business cycle. That is real engineering and genuinely useful — but notice the mechanism. The escrow is an escrow agent: a third party that holds funds mid-trade and releases them when conditions are met. That is orchestration with a custodian in the middle. It works by trusting the orchestrator.

This is the distinction that matters for anyone designing agent infrastructure: there are two ways to make a multi-step trade safe.

Trusted orchestration. A third party (escrow agent, custodian, clearing service) holds funds and arbitrates. Safety comes from trusting that party. Fireblocks, Copper, and most "escrow layers for agents" sit here.
Trust-minimized atomicity. A contract enforces clear-or-refund with no party ever holding both sides. Safety comes from the protocol. There is no orchestrator to freeze, lose, or drain the funds.

Both are valid. But only the second removes the counterparty entirely, and that removal is precisely what an autonomous agent — which can't read a custodian's terms of service or sue when funds are frozen — actually needs.

The mechanism: HTLC, not escrow agent

A Hash Time-Locked Contract is the trust-minimized version. The flow, stripped down:

The maker locks funds against a hash H = hash(secret), with a timelock.
The taker locks their side against the same hash, on their chain, with a shorter timelock.
Revealing the secret to claim one side mathematically reveals it for the other. Both legs clear, bound by the same preimage.
If anyone walks away, the timelocks expire and both sides auto-refund. No funds stranded, no arbiter needed.

The contract is the escrow. There is no escrow agent. That is the difference between "settlement" as a marketing word and settlement as a property the chain enforces. The same hashlock-plus-timelock construction also encodes a forward — commit now, claim only inside a future settlement window — which is how you bind a "agree today, settle at T+24h" agent trade without anyone holding margin in between.

Why the crater is a signal, not a verdict

It would be easy to read "x402 volume down 92%" as "the agent economy is overhyped." That's the wrong lesson. Payments are a solved-and-commoditizing layer — that's why volume concentrates and margins compress and a dozen rails fight over the same flows. Commoditization of payments is the precondition for the next layer to matter, not evidence against it. When moving a stablecoin one direction is free and ubiquitous, the open question becomes: how do two agents trade different assets across different chains without a trusted middleman? That's settlement, and it sits underneath every rail rather than competing with them.

For builders, the practical takeaway is to be precise about which job your integration is doing. If your agent only ever pays for resources, a rail is the right tool and you have excellent options. If your agent needs to exchange value with another agent — bidirectional, cross-asset, cross-chain, with no custodian — you need a settlement primitive, and you should check whether the thing labeled "settlement" is atomic or merely orchestrated.

Where Hashlock sits

Hashlock is the settlement layer, not another rail: sealed-bid RFQ for price discovery, fused with HTLC atomic settlement for the clear-or-refund guarantee. No bridge, no custodian. It's exposed to agents as an MCP server with 6 tools — hashlock-tech/mcp (scoped) on npm — so an assistant or autonomous agent can request quotes, lock, and settle natively rather than through a wrapper. It's live end-to-end on Ethereum mainnet; Sui contracts are deployed and CLI-tested with gateway wiring in progress, and the Bitcoin path is signet-validated with mainnet pending. Fees run 1-2 bps against the 8-10 bps a traditional OTC desk charges, because there's no intermediary taking a cut. The design rationale lives in the methodology write-up and the SSRN paper.

The rails will keep multiplying, and most of them will be good at the one-directional payment they're built for. The question that decides the next 12 months is whether they absorb settlement or whether settlement stays a separate, trust-minimized layer underneath. I have a view. What's yours — do payment rails absorb settlement, or is it permanently a different layer?

Methodology: https://hashlock.markets/methodology?utm_source=devto&utm_medium=post&utm_campaign=2026-06-18-rails-vs-settlement
Whitepaper (SSRN): https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722

Why would two agents that have never met trade? The incentive layer the rails keep skipping

Baris Sozen — Wed, 17 Jun 2026 08:11:28 +0000

PayPal made it safe to pay strangers online. The interesting part was never the payment — it was that two people who had never met could transact without trusting each other, because the platform stood in the middle. On-chain, you can get the same safety with the opposite arrangement: no one in the middle at all. Two agents lock assets into a hash-time-locked contract that can do exactly one of two things — clear both legs together, or refund both. Your money never leaves your wallet until theirs arrives.

That primitive has existed for years. So here is the question that actually matters for the agent economy: if atomic settlement is already possible, why doesn't it just happen?

Rails are not networks

Most of what's shipping right now in agent payments is a rail. x402 now spans 10,000+ merchants and 160M+ cumulative transactions. Mastercard Agent Pay, Google's AP2, the various CEX agent protocols — all of them move value along a path that already exists. That's genuinely useful. But a rail answers "how does value get from A to B." It does not answer two questions that an open, two-sided settlement network lives or dies on:

Why would an agent execute a trade for a stranger first? Atomic settlement removes counterparty risk, but someone still has to be the first to lock funds, watch for the preimage, and complete the second leg. On a custodial venue the venue does this and charges for it. On a trust-minimized network, if nobody is rewarded for executing, the network is technically correct and practically empty.
How do strangers transact without everyone being forced through the same identity gate? A custodian solves trust by knowing who you are — one KYC process, applied to everyone, before anyone can move. That's a sensible default when the custodian is liable. It's a strange default for a swap where the contract itself guarantees the outcome.

These are not plumbing problems. They are network-bootstrapping problems, and they are exactly where "we have atomic settlement" stops being enough.

Execution rewards: pay the agents that clear trades

The cold-start problem for a settlement network is concrete. Early on there are few counterparties, thin liquidity, and no reason for an agent to route its first trade through you instead of the custodial venue it already trusts. You can't subsidize that away with marketing; you have to make execution itself worth doing.

Execution rewards put the incentive where the work is. The agents and relayers that actually clear settlements — lock the matching leg, monitor the hash preimage, complete or refund within the timeout window — earn a protocol-level reward for doing so. The effect is that liquidity and reliability bootstrap themselves instead of waiting on goodwill:

Reliable executors get paid for being reliable, which is the behavior you want to reinforce on a network where a missed timeout means a refund, not a theft.
Reward accrues to the function that's scarce early (execution and liquidity), not to the function that's abundant (opinions about the protocol).
Because settlement is atomic, the reward never creates a custody risk. An executor is paid for clearing a trade that could only ever clear or refund — there is no intermediate state where they hold your assets and decide what to do.

This is the part the rail metaphor hides. A rail is paid per transaction it carries. A settlement network has to pay for the thing that makes it a network at all: agents willing to show up and execute against people they don't know.

Tiered trust: a dial, not a gate

The second question — identity — is where custodial and trust-minimized settlement diverge most sharply, and where the agent economy is quietly importing an assumption it doesn't need.

When a custodian holds the assets, one KYC gate for everyone is rational: the custodian is the liable party, so it must know its customers before it moves a cent. But when the contract guarantees the outcome, identity stops being a precondition for safety and becomes a parameter you can tune to context:

A small, asset-for-asset atomic swap between two agents needs no identity at all. The HTLC is the trust. Either both legs clear or both refund; there is nothing an unknown counterparty can do to you that the contract permits.
Larger flows, or flows touching regulated assets or jurisdictions, can opt into higher tiers — verified counterparties, attestations, limits — without dragging every $40 swap through the same process.

Trust becomes a dial, not a gate. The default is permissionless because the cryptography carries the risk; the higher tiers exist for the cases where something outside the contract (a regulator, a counterparty preference, a size threshold) genuinely needs more. This is the opposite of the custodial model, which sets the gate at maximum for everyone because it has no other way to bound its liability.

Custody, to be clear, is the honest tool when something subjective has to be judged — did the work get delivered, did the merchant ship. For a clean asset-for-asset swap, none of that judgment is needed, and forcing a single identity gate in front of it is friction without a corresponding risk.

Where this sits in the stack

None of this competes with the payment rails. x402, AP2, agent payment protocols — they decide intent and authorization. Underneath them, something still has to make the two-sided, cross-asset exchange final without a custodian. That's the settlement layer, and execution rewards plus tiered trust are how that layer becomes a living network rather than a correct-but-empty contract.

For reference on how the underlying settlement and its volume are accounted for from public chain data, the methodology is here: https://hashlock.markets/methodology?utm_source=devto&utm_medium=article&utm_campaign=2026-06-17-execution-rewards-tiered-trust

A note on status, because precision matters: Ethereum mainnet is live end-to-end. Sui contracts are deployed and CLI-tested. Bitcoin is signet-validated. The settlement primitive is built on hash-time-locked contracts, exposed through an MCP server with 6 tools (create_htlc, get_htlc, withdraw_htlc, refund_htlc, swap_quote, swap_execute) so an agent can negotiate and settle without a bridge or a custodian. The economic design above — rewarding execution, tiering trust — is how an open settlement network is meant to bootstrap, not a claim that every knob is already turned in production. Rails ready, trains coming.

The academic foundation, if you want the formal version of the settlement argument, is on SSRN: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722

So I'll put the question back to you: if you were bootstrapping an open settlement network for autonomous agents, what should carry the most weight early — execution incentives, identity tiering, or something the rails-vs-settlement framing misses entirely?

Your AI can trade for you now. The question is who's holding the money.

Baris Sozen — Tue, 16 Jun 2026 06:08:53 +0000

A new pattern shipped this month: connect an AI assistant to your exchange account and let it trade for you. You ask, it places the order. It's a genuinely useful demo, and it's going to get a lot of people comfortable with the idea of an agent moving their money.

It's also worth being clear-eyed about the trade you make to get it. For an agent to trade on a custodial exchange, it needs access to an account that the exchange controls. The funds sit with the venue. The agent is fast and autonomous right up until the custodian decides otherwise - freeze, limit, lose, or get drained. You've added a smart trader on top of an old trust assumption, not removed the trust assumption.

That's fine for some jobs. It's not the only shape an agent trade can take. And if agents are going to move real value between each other, the shape we normalize now matters.

Two ways an agent can "do a trade"

Custodial: the agent operates an account held by a third party. The venue holds the keys and the balance; the agent holds permission to act. Speed and convenience are excellent. The cost is a standing trust assumption - there is always someone in the middle who can stop or lose the money, and that someone is now also a target.

Trust-minimized atomic settlement: two parties lock assets into a contract, and the contract can only do one of two things - clear both legs together, or refund both. No account to log into, no balance held by a middleman, nothing in between to freeze. The agent decides what to trade; the protocol guarantees how it settles.

The first answers "who holds the money?" with a custodian. The second answers it with nobody - the funds stay put until the swap completes atomically.

How "nobody holds it" actually works

The primitive is a Hashed Timelock Contract (HTLC). It's old, boring, and exactly the property you want when no one is supposed to be in the middle.

Both sides lock their funds against the hash of a secret. To claim, you reveal the preimage of that hash - and revealing it on one chain exposes it for the counterparty to claim on the other. So either both legs are claimed with the same secret, or neither is and both refund after a timelock. There is no window where one party has both assets, and no window where a third party is holding either.

A clean cross-chain swap - say ETH for BTC across two chains - looks like this:

Each side locks its asset to the same hash, with a refund timelock.
The claim reveals the preimage, unlocking both legs as a unit.
If anyone walks away, the timelock refunds both sides. No counterparty risk, no custodian to chase.

The contract is the escrow. There's no honeypot account, because there's no account.

Where each one honestly fits

This isn't "custody bad." A held balance buys you something real: a place for funds to wait while something subjective gets judged - did the dataset arrive, was the work acceptable, did the merchant ship. For agent-to-merchant payments and off-chain work, a trusted middle is the honest tool, and payment rails like x402 (which crossed 160M cumulative payments) are built for exactly that: move one known asset, one direction, now.

Atomic settlement is for the other case: two parties swapping different assets, possibly across chains, where the only question is "did both sides deliver?" There's nothing subjective to judge, so there's nothing for a custodian to do except add risk. That's the case where "login to my exchange" is solving a problem you could delete entirely.

The mistake is using the custodial shape for trades that don't need it - paying the honeypot tax on a swap that math could have settled trustlessly.

Why this matters more for agents than for people

A human logging into an exchange at least understands the custody bargain. An agent trading on your behalf, thousands of times, across venues you didn't individually vet, compounds that bargain. Every custodial connection is a standing key to your funds and a standing target. The trust-minimized version doesn't accumulate that exposure: there's no key to leak and no balance to drain, because settlement happens in a contract that can only clear-or-refund.

If autonomous agents are going to trade at scale, the default should be the shape where a bad actor in the middle simply has nothing to take.

Where Hashlock sits

Hashlock fuses sealed-bid RFQ with HTLC atomic settlement, exposed to agents as an MCP server with a small set of tools. An agent can request a quote, get matched, and settle a cross-chain swap where no one ever custodies the funds. Your money never leaves your wallet until theirs arrives.

Status, honestly: Ethereum mainnet is live end-to-end; Bitcoin is signet-validated; Sui is deployed and CLI-tested. Small and verifiable beats big and hand-wavy.

Site: https://hashlock.markets/?utm_source=devto&utm_medium=post&utm_campaign=2026-06-16-who-holds-the-keys
MCP server: @hashlock-tech/mcp (scoped) - GitHub: https://github.com/Hashlock-Tech/hashlock-mcp
Whitepaper (SSRN): https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722

Here's the question I keep coming back to: when you let an agent trade for you, are you okay with someone holding your money the whole time - or should the trade be built so nobody can? Curious where people land on this, especially for high-frequency agent flows.

Forward settlement without a custodian: how two agents bind a future trade with one timelock

Baris Sozen — Mon, 15 Jun 2026 09:52:10 +0000

Most explanations of atomic swaps stop at the spot case: two parties lock funds, one reveals a secret, both legs clear in the same short window. Clean, but it quietly assumes the trade settles right now.

A lot of real agent activity isn't spot. It's a forward: two agents agree on terms today - asset pair, size, price - and settle at some future point, T+24h or T+48h. Procurement agents pre-committing to a delivery. A treasury agent locking tomorrow's FX-equivalent rate. A market-making agent quoting a forward to offload inventory risk. The economics are old; what's new is that the counterparties are anonymous software that will never meet.

That raises a question spot swaps don't have to answer: what holds the trade together in the gap between agreement and settlement?

In traditional markets the answer is a chain of intermediaries - a clearing house, posted margin, a credit desk that decides whether your counterparty is good for it. Strip those away, as you must in a market of anonymous agents, and the naive version of a forward collapses. If nothing binds the trade, either side can simply not show up when the price has moved against them. That's counterparty risk, and it's exactly the thing a forward is supposed to manage.

This post is about how the HTLC primitive - the same hashlock plus timelock most people only associate with same-block atomic swaps - can encode a forward obligation that's binding without anyone custodying the funds in between.

The timelock is doing more work than you think

Recall the two parameters of a hash-time-lock contract:

Hashlock: funds can only be claimed by revealing a preimage s such that hash(s) == H. The same H is used on both legs, so the act of claiming one leg reveals the secret that unlocks the other. That's what makes the swap atomic - both clear or neither does.
Timelock: if the preimage isn't revealed before a deadline, the funds refund to their original owner. No third party decides this; the contract enforces it.

In the spot case the timelock is just a safety hatch - a short window so a stuck swap doesn't trap funds forever. In a forward, the timelock stops being a safety hatch and becomes the instrument itself.

The move is simple to state: commit the funds now, but make the claim valid only inside a future settlement window. The lock exists from the moment both legs are funded. Neither party can withdraw their committed asset during the term - it's not in a custodian's account, it's in a contract whose only two exits are "clear" or "refund." When the settlement window opens, both sides settle against the shared preimage and both legs clear at once. If the window closes with no settlement, the timelock refunds both sides to their original owners.

That gives you the three properties a forward needs, with none of the intermediaries:

Binding. Once funded, the obligation is locked for the term. Walking away isn't a unilateral option; the funds are already committed to the contract.
No custody. During the entire term, no counterparty and no platform holds the other side's money. The contract is the escrow, and the contract can only ever clear-or-refund.
No margin call, no credit check. There's no "is my counterparty good for it" question, because settlement is collateralized by the locked legs themselves, not by a promise. Default isn't a loss event; it's just a refund.

Worked example

Two agents, A and B. A wants asset X tomorrow; B wants asset Y tomorrow; they agree the rate today.

t = 0 (agreement): A funds an HTLC locking X against hash H; B funds an HTLC locking Y against the same H. Settlement window is defined as roughly T+24h, with a refund deadline after it. Both legs are now committed. Neither agent can pull their asset.
During the term: nothing custodial happens. The price of X/Y can move. Neither agent can act on that by withdrawing, because withdrawal isn't an available transition - only clear (inside the window) or refund (after the deadline) are.
t = T (settlement window opens): the party holding the preimage claims their leg, which publishes s on-chain. That same s immediately unlocks the other leg. Both clear atomically against one secret.
Failure path: if the window closes with no claim - one agent went dark, infra failed, whatever - the timelock refunds both legs to their original owners. Nobody is out anything except a locked-capital window. The worst case is a wasted term, never a theft.

Notice what's absent: no clearing house, no posted variation margin, no counterparty credit assessment, no wrapped IOU minted on a destination chain, no bridge multisig holding value. The forward is enforced by two contracts and one shared secret.

Why agents specifically need this

You could argue humans got by with clearing houses for a century, so why change it. The answer is that the agent setting breaks the assumptions clearing houses rely on. Clearing depends on identity and recourse: known members, legal agreements, the ability to pursue a defaulter. Anonymous agents transacting across chains have none of that. There's no membership committee, no jurisdiction, no one to sue. In that environment the only enforceable forward is one where enforcement is mechanical - in the contract - rather than institutional.

This is also why "payment rails are enough" undersells the problem. This week made the point cleanly: x402 added Injective as a chain and crossed 160M cumulative payments. That's genuine adoption, and it's worth taking seriously. But a payment rail moves one known asset, one direction, at the moment of payment. It is structurally a spot, one-legged instrument. It can't bind a two-sided, cross-asset trade that settles later without smuggling a custodian back in to hold the gap. Volume on the payment layer is not the same thing as settlement, and a forward is the cleanest example of a trade the rail can't express.

Where this sits in Hashlock

Forward settlement is one of the primitives we build on top of sealed-bid RFQ plus HTLC atomic settlement - the same machinery that powers spot swaps, reused so the timelock encodes a future obligation instead of an immediate one. No bridges, no custodians; both legs clear or both refund.

To be precise about chain status, because it matters: Ethereum mainnet is live end-to-end; Bitcoin is signet-validated; Sui is deployed and CLI-tested. Forward mechanics live in the docs, and there's an academic treatment of the settlement model in the whitepaper if you want the formal version.

Docs: https://hashlock.markets/docs?utm_source=devto&utm_medium=post&utm_campaign=2026-06-15-forward-settlement
MCP server (6 tools): hashlock-tech/mcp (scoped) on npm
Whitepaper (SSRN): https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722

If you're designing forward or deferred-settlement flows for agents today, what's holding the trade together between agreement and settlement in your design - a balance sheet, or a contract that can only clear-or-refund? Curious how others are handling the term-risk gap.

The agent economy added two rails and lost most of its volume this week. Nobody added settlement.

Baris Sozen — Sun, 14 Jun 2026 06:07:34 +0000

Title: The agent economy added two rails and lost most of its volume this week. Nobody added settlement.
Tags: mcp, ai, cryptocurrency, blockchain

This is our weekly recap from building Hashlock in public. We try to read every agent-economy announcement of the week and ask one question of each: at the moment a trade actually clears, which layer finishes it? This week the answers lined up unusually neatly.

The headline number: x402 is down 92%

OKX Ventures published agent-payment data in June showing that x402 transaction volume has fallen roughly 92% from its November 2025 peak - from about $5.15M to $1.19M per month. Transaction count recovered (around 2.89M monthly), but the average transaction is now about $0.52. That is a category settling into micropayments, not a category absorbing real trade value.

That is worth sitting with, because for most of the last year the narrative ran the other way: payment rails for agents were the story, and settlement was treated as a solved sub-problem of payment. The first hard volume number says the opposite. The rails are cooling.

And yet the rails keep launching

The same week, two more shipped:

Mastercard Agent Pay - a way for agents to initiate card payments on a user's behalf.
A Ripple XRPL agent kit - tooling for agents to move value over the XRP Ledger.

Both are real, both are useful, and both do the same fundamental job: route a known asset from an agent to a seller. That is payment. It is also the layer that already has the most entrants, the most capital, and - per the x402 data - the softest demand relative to the hype.

There is nothing wrong with a crowded payment layer. The point is narrower: launching more payment rails does not address the thing that is structurally missing.

The map with a hole in it

The most useful artifact of the week was OKX Ventures' framework for the agent economy. It describes three converging layers:

Payment - x402 and similar (move value from agent to seller).
Trust - ERC-8004 and agent registries (identity and reputation).
Commercial - marketplaces where agents transact.

It is a clean model. Read it carefully and you notice what is not in it: a settlement layer. The framework assumes that once you have payment, trust, and a marketplace, the clearing of a trade takes care of itself.

It does not - not for the hardest and most interesting case.

The job none of the rails do

Here is the case the payment layer does not cover: two agents that do not trust each other, holding different assets on different chains, want to swap. Agent A has USDC on Ethereum, Agent B has an asset on another chain. Neither wants to send first. There is no marketplace escrow they both trust, and routing a stablecoin one direction does not solve a two-sided exchange.

What that needs is atomic settlement: both legs of the trade complete, or both refund. No intermediate state where one party is exposed. No custodian holding the funds "for a moment." No bridge minting a wrapped IOU.

The primitive that does this is a hash-time-locked contract (HTLC). Both parties lock funds against the same hash. Revealing the preimage to claim one leg mathematically enables claiming the other. If nobody reveals before the timelock, both sides refund. The guarantee is enforced by the contracts, not by a trusted third party. That is a different layer from payment - it is the clearing layer underneath it.

This is also why "settlement layer" became a contested phrase this week. AEON raised $8M describing itself as "the settlement layer for the agent economy." Looking at what it does, it is an x402-based payment facilitator that bridges agents to fiat-merchant payments. That is genuinely valuable - and it is the payment rail, not the clearing layer beneath it. We do not think that is a contradiction to attack; it is a category that is still forming its vocabulary. But the words matter, because they point an agent builder at the wrong primitive for a two-sided cross-chain trade.

What we shipped and learned

Building in public means reporting our own numbers, not just other people's:

First AI-assistant referrals in our analytics. This week we saw the first sessions in GA4 arriving via claude.ai and chatgpt.com - including one that completed an MCP OAuth connection and stayed for over 12 minutes. Small numbers, but a new channel: agents and their users are starting to find the protocol through assistants, not search.
A discipline lesson. Our automated publisher refused to ship a draft this week because a transparency disclaimer contained a phrasing that tripped our own chain-claim guardrail. Annoying in the moment, correct in principle: the guardrail does exact-string matching and does not make exceptions for "we are clarifying, not claiming." We would rather over-block our own copy than let an out-of-context quote imply a chain is in production when it is not.

On that note, the honest chain status, every time: Ethereum mainnet is live end-to-end. Bitcoin is signet-validated. Sui contracts are deployed and CLI-tested. Ethereum is the only production chain right now. If an assistant ever describes more than that, it is ahead of where the code is.

The scoreboard

This week the agent economy added two payment rails, watched its flagship rail's volume fall 92%, and published a three-layer map that left settlement out. The number of trust-minimized, cross-chain, atomic settlement layers is still 1 - and it is the layer the map forgot.

Where we sit: sealed-bid RFQ + HTLC atomic settlement, fused into one flow. No bridge, no custodian. Your money never leaves your wallet until theirs arrives. Six MCP tools so an agent can request a quote, respond, and settle without ever handing custody to anyone. The architecture and the threat model are written up in our methodology page and, for the formal version, our SSRN whitepaper.

When a product tells you it is "the settlement layer," the most useful thing you can do is ask which of the four jobs it means - payment, custody-and-release, micropayment, or clear-or-refund. Which one does your agent actually need at the moment a trade settles? I would genuinely like to hear which case you are hitting first.

Anyone can claim volume. Here's how to recompute ours from public chain data.

Baris Sozen — Fri, 12 Jun 2026 06:08:54 +0000

DEX volume is one of the easiest numbers in crypto to inflate and one of the hardest to audit. Wash trades, both-legs counting, "volume" recognized at quote time instead of settlement time - the tricks are old, and the dashboards rarely tell you which ones a venue is playing.

This matters more in the agent economy than it ever did for humans. An AI agent choosing where to route a trade doesn't get vibes from Discord. It gets a number from an aggregator API. If that number can't be independently recomputed, it isn't a metric - it's marketing, and for an autonomous allocator it's an attack surface.

So today's product post is a transparency post: exactly how we count Hashlock Markets volume, what we refuse to count, and the three public surfaces where you can check our math. (Full version lives at our methodology page.)

The unit of volume: a settled withdraw, nothing else

On Hashlock, settlement is the trade. Both sides of an RFQ lock funds in Hash Time-Locked Contracts on their respective chains under a shared sha256 hashlock. When the taker reveals the preimage on one leg, the maker claims the other leg with the now-public preimage. Both legs settle, or both refund after the timelock.

A unit of reported volume is the USD notional of a settled HTLC withdraw on a given chain - the moment the Withdraw event (EVM) or HTLCClaimed event (Sui package) is emitted, meaning the preimage was revealed and funds actually moved to the receiver.

What is deliberately not counted:

Refunded HTLCs. Timelock expired, no preimage, money went home. That's a failed trade, not volume.
Locked-but-unclaimed HTLCs. Volume is recognized at claim time, not lock time. A lock is a promise; a claim is a trade.
Off-chain RFQ activity. Quotes and sealed bids are not trades. A venue counting quote flow as "volume" is counting conversations.
Protocol fee transfers. Fees are fees. They get their own line.

The double-counting problem, handled the boring way

Every cross-chain trade emits one withdraw per leg - one on each chain. Summed naively, protocol-level volume is roughly 2x the unique-trade value. Some venues quietly enjoy that 2x. Our DefiLlama adapter instead sets doublecounted: true, so DefiLlama can deduplicate at the protocol level while per-chain views stay accurate as "value transferred via Hashlock HTLCs on this chain."

We'd rather under-claim than inflate. In a market that's about to be navigated by software, the venues that survive audits will be the ones that were boring about this from day one.

Three places to check our math

The contracts, verified on Etherscan. Three HTLC contracts on Ethereum mainnet (Ether, Ether+fee, ERC-20+fee), deployed 2026-04-09. Volume reads straight from HTLCETH_Withdraw / HTLCERC20_Withdraw events - amount and token are on the event itself, no back-join needed.
Open Dune queries. ETH events, Sui events, and a unified cross-chain trades query, mirrored on GitHub. The public dashboard shows the settled-trade counter and daily volume from the same SQL.
The DefiLlama adapter source. The dexs/hashlock-markets adapter in DefiLlama's dimension-adapters repo is the literal code that produces the number on the listing. If we changed how we count, the diff would be public.

One detail worth calling out for builders: Sui's HTLCClaimed event doesn't carry amount or coin type, so the adapter joins each claim to its HTLCLocked event by htlc_id and reads notional from the lock side - counting only locks whose IDs also appear in a claim within the day window. Event-schema quirks like this are exactly where silent volume inflation usually hides; documenting the join is part of the methodology.

And the chain-status fine print, because precision is the whole brand here: Ethereum mainnet is live end-to-end. Bitcoin HTLCs (native P2WSH scripts, no contract to deploy) are signet-validated, and a v2 adapter for BTC is planned for when mainnet BTC trades are observable - classification there requires parsing the spending transaction's witness stack, since Bitcoin has no event log. Sui contracts are deployed and CLI-tested - the inaugural $1.00 smoke settlement is visible in the public Sui events query - with full production wiring still in progress.

Why a tiny protocol publishes an audit trail

Honest answer: our volume is small. The smoke trade that opened the Sui events query is literally one dollar. Publishing a reproducible methodology when your numbers are modest feels backwards - transparency is supposed to be what big venues owe the market, not what small ones lead with.

We think it's the opposite. The agent economy is going to industrialize metric-gaming: synthetic flow is cheap to generate and agents are tireless at generating it. The only volume numbers that will mean anything are the ones a third party - or a third party's agent - can recompute from chain data without asking permission. We'd rather establish that standard at $1 than retrofit it at $1B.

If you're building a venue, an aggregator, or an agent that consumes venue metrics: what would it take for you to treat a reported volume number as load-bearing? Event-level reproducibility? Independent indexing? Something stronger? Tell me what we're still missing.

Hashlock Markets - the atomic settlement layer for the agent economy. Methodology: hashlock.markets/methodology · MCP server: hashlock-tech/mcp on npm · Whitepaper: SSRN

Held custody vs. no custody: two ways to make an AI agent's trade safe

Baris Sozen — Thu, 11 Jun 2026 06:07:29 +0000

A useful thing happened in agent infrastructure this June: several teams shipped "escrow layers for AI agents" - production MCP tools that let an agent run a full commit -> hold -> complete lifecycle without a human anywhere in the loop. An agent can now park value with a contract or service, wait for the other side to deliver, and release on completion. That is genuinely new, and it solves a real problem.

It is also worth being precise about, because "escrow" and "settlement" get used as if they were one thing. They are not. There are two structurally different ways to make a trade your agent does at 3am trustworthy, and the difference is exactly who holds the money while the trade is in flight.

Model one: held custody

In the held-custody model, a third party - a smart contract escrow, a custody service, a payment facilitator - takes the funds, holds them, and releases them when a condition is met. The condition can be anything you can express: a delivery confirmation, an evaluator's attestation, a timeout, a multi-sig approval.

This is the right tool for a large class of agent commerce. If your agent is paying a merchant, buying a dataset, or hiring another agent to do a unit of work, the hard question is subjective: did the thing actually get delivered, and was it any good? A hash function cannot see that. A custodian can - it gives the trade a place to pause while something or someone checks. The new agent-escrow tooling is built around exactly this shape: a job, a held balance, a release on completion. For agent-to-merchant payments riding on rails like x402, held custody is the honest primitive.

The cost is equally concrete. A held balance is a honeypot. Someone controls the funds between commit and complete, which means someone can freeze them, lose them, misconfigure the release condition, or get drained. You have added a trust assumption and a liveness dependency - the custodian has to be online, solvent, and honest at release time. That is often an acceptable price for the ability to arbitrate subjective delivery. But it is a price.

Model two: no custody at all

The second model deletes the custodian. In an atomic swap built on hash-time-locked contracts (HTLCs), both legs of a trade are locked to a single hash preimage. Reveal the preimage and every leg unlocks together; never reveal it and every leg refunds. There is no escrow account, no release decision, and no point in time where a third party is holding the money. The trade clears as one unit or it unwinds completely.

This is the right tool for the other large class of agent activity: two non-trusting agents exchanging assets, often across two chains - ETH for BTC, one chain's token for another's. Here the risk that matters is not "was the work good," it is "one leg lands and the other doesn't, and somebody just got robbed." Atomicity removes that failure mode by construction. No custodian means no honeypot, no freeze, no liveness dependency on a third party staying honest. The trade is safe because of how it is shaped, not because of who is watching it.

The honest limit is the mirror image of model one's strength: atomicity can only settle things that are assets moving on a ledger. It cannot judge subjective delivery, it cannot stream a payment against partial work, and it cannot rule on a dispute that lives off-chain. If your trade needs a referee, an HTLC has no referee to offer.

Where each one wins

Put plainly:

Held custody wins when delivery is subjective, off-chain, or unfolds over time - agent-to-merchant payments, hiring an agent for work, anything where "did you actually deliver" is a real question someone has to answer.
No custody wins when the trade is a clean, two-sided exchange of on-chain assets - especially across chains, where a bridge or a custodian would otherwise be the single biggest point of failure.

These are not competitors so much as different layers of the same stack. A mature agent economy will use both: held custody where a trade needs judgment, atomic clear-or-refund where it needs none. The mistake is using one where the other belongs - putting a custodian in the middle of a clean ETH-for-BTC swap (now you have a honeypot you never needed), or trying to atomically settle a subjective deliverable (now you have a primitive that literally cannot see the thing in dispute).

What we're building, stated honestly

Hashlock is the no-custody side of that stack: sealed-bid RFQ fused with HTLC atomic settlement, exposed to agents through an MCP server with six tools, so an agent can quote, match, and settle a cross-chain trade where no one - including us - ever holds the funds. The chain status, without rounding up: Ethereum mainnet is live end-to-end; Bitcoin is signet-validated with mainnet pending; Sui contracts are deployed and CLI-tested with gateway wiring in progress. We are not claiming BTC or Sui mainnet, and a comparison post is a bad place to fudge maturity.

The academic backing for the settlement design lives in the SSRN whitepaper if you want the formal version: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722. The MCP server and tools are open at https://github.com/Hashlock-Tech/hashlock-mcp, published as hashlock-tech/mcp (scoped) on npm.

The interesting question for builders is not which model is "better" in the abstract - it's where the boundary sits for your agent's flows. If you're wiring up agent trades right now: which of your trades genuinely needs someone to hold the money mid-flight, and which ones are clean enough that a custodian is just risk you could cryptographically remove?

More on the settlement design: https://hashlock.markets/methodology?utm_source=devto&utm_medium=post&utm_campaign=2026-06-11-custody-or-not

Payment rails are winning the agent economy. A trade needs something a rail can't do.

Baris Sozen — Wed, 10 Jun 2026 06:09:01 +0000

A widely cited number in agent infrastructure right now comes from Crossmint's protocol data: x402 has processed 150M+ transactions across Base and Solana, and agent-to-agent payments are its fastest-growing segment - Solana alone now carries roughly 49% of that A2A volume. A machine-to-machine payment network at real scale, on a protocol that didn't exist in its current form two years ago.

Add the rest of the quarter's announcements - AWS Bedrock AgentCore, Shopify's UCP, Google's AP2 - and a clear picture forms: big tech is paving the payment layer of the agent economy, and it's working. This post is not a contrarian take on that. The rails are good. They're also, by construction, one-way - and that one property defines exactly where they stop.

What a rail is, mechanically

Strip any agent payment rail down to its state machine and you get the same shape:

Agent receives a 402 Payment Required (or an intent mandate, or a checkout session).
Agent signs and submits a transfer: agent → seller.
Seller (or facilitator) verifies receipt and releases the resource.

One leg. One direction. The buyer's risk is bounded by the price of the request, and the seller delivers only after value lands. For an agent buying compute, a dataset, an API call, or inference, this is precisely the right primitive - low ceremony, instant, cheap. Agent-to-agent volume is climbing on x402 because the design fits the job.

Note what makes it safe: the transaction is small, unilateral, and the seller's delivery is conditional on payment already being final. The trust model is "buyer pays first, for something cheap enough that failure is an annoyance, not a loss."

What a trade is, mechanically

Now change the job. Two agents - call them A and B - want to exchange assets: A's ETH for B's BTC. Neither trusts the other. Often the assets live on different chains. The state machine that matters is no longer one leg; it's the joint state of two legs:

Both legs complete → trade settled. ✅
Neither leg completes → trade cancelled, both refunded. ✅
One leg completes, the other doesn't → one agent has both assets, the other has neither. ❌

That third state is the entire problem. It isn't an edge case; it's the default outcome whenever the two legs commit independently and one party is adversarial. A trade primitive is exactly a mechanism that makes the third state unreachable.

Why two rails don't make a trade

The tempting answer: "just run two payments in opposite directions." A pays B over a rail; B pays A over a rail. But each rail transfer is unconditional once submitted - that's what makes it a good payment. So whoever pays first hands the other side a free option. B can take A's leg and simply not send the second one. Sequencing doesn't fix it; it only chooses the victim.

You can bolt an intermediary on top - an exchange, a custodial facilitator, an escrow service that receives both legs and forwards them. That genuinely works, and it's how most trading happens today. But you've reintroduced the exact thing the agents were trying to avoid: a third party who, for some window, holds both assets and could fail, freeze, or walk. For autonomous agents transacting at machine speed with counterparties they discovered minutes ago, "trust the venue" is a strange foundation.

The primitive that makes the third state unreachable

The construction that does this without an intermediary has been known for years: the hash time-locked contract. Both legs are locked under the same hash H = sha256(s). Claiming either leg requires revealing the preimage s on-chain - and the moment it's revealed on one chain, it's public, so the other party uses it to claim their leg on the other chain. Timelocks (the claimer's window expires before the funder's refund opens, with a safety margin for chain latency) guarantee that if s is never revealed, both legs refund.

The result is the three-state property a trade actually needs: at every instant, each asset is either locked, released (preimage revealed, both sides can claim), or refunded (expired, funds home). There is no state in which a third party holds anything, and no reachable state where one side has both assets past the timeout boundary.

That is not a payment optimization. It's a different primitive solving a different problem - which is why it doesn't compete with rails any more than TCP competes with HTTP.

The layer map, as we see it

The stack that's emerging looks roughly like this:

Intent / authorization - Google AP2, OpenAI+Stripe ACP: should this agent transact, on whose mandate?
Identity / reputation - ERC-8004: who is this agent, what's its track record?
Payment rails - x402, facilitators built on it: move value one way, fast and cheap.
Trade settlement - clear-or-refund for two-sided, cross-chain exchanges: both legs or neither, no custodian.

Every layer above settlement can (and should) sit on top of it. An agent that authenticates via ERC-8004, negotiates under an AP2 mandate, and pays for its API calls over x402 still needs the bottom layer the first time it exchanges one asset for another with a counterparty it doesn't trust. (A week of mapping the overloaded word "settlement" taught us most disagreements here are vocabulary, not substance - so we'll keep it to that one sentence.)

This is the layer we build. Hashlock combines a sealed-bid RFQ (so agents get firm quotes without leaking intent) with HTLC atomic settlement, exposed to agents as an MCP server with six tools - the package is hashlock-tech/mcp (scoped) on npm. Chain status, stated honestly and in the same order every time: ETH mainnet live end-to-end; Sui contracts deployed and CLI-tested (gateway wiring in progress); BTC signet-validated, mainnet pending.

If you want the protocol-level detail, the docs walk through the RFQ-plus-HTLC flow end to end: hashlock.markets/docs. Source: github.com/Hashlock-Tech/hashlock-mcp. Academic write-up: SSRN.

The question worth arguing about

The rails' growth curve (150M+ tx, agent-to-agent as the fastest-growing slice) says agents already buy things constantly. The open question is when they start trading - rebalancing treasuries across chains, swapping inventory, posting collateral to each other. When that happens, the half-completed-trade problem stops being theoretical.

So: what's the first thing you expect an agent to trade - not buy? And would you let it do so through a venue, or only through a mechanism where the venue can't hold the money?

Your agent is trading with a stranger. What keeps the stranger honest?

Baris Sozen — Tue, 09 Jun 2026 06:09:44 +0000

Picture the moment your AI agent actually transacts. It posts a request, gets quoted a great price by some other agent, and prepares to trade. It has never met that counterparty. It has no name for it. It will probably never see it again. The whole interaction lasts a few hundred milliseconds and then both parties move on.

So what keeps the stranger honest?

In human markets we have a stack of answers: reputation, repeat business, legal recourse, a broker whose job is to vouch for both sides. None of those survive contact with an anonymous, high-frequency, agent-to-agent market. You can't sue an ephemeral wallet. You can't build a relationship with a counterparty you'll interact with exactly once. And if your answer is "route everything through a trusted venue that vouches for both sides," you've just rebuilt the custodian you were trying to delete.

This post is about the layer that actually addresses it — without a referee holding the money. Two primitives: execution rewards and tiered KYC. But first, the floor underneath both of them, because it changes what problem you're even solving.

The floor: with atomic settlement, you can't be robbed

The instinct is to assume the danger with a stranger is theft — they take your asset and vanish. Atomic settlement removes that danger structurally.

Both legs of the trade lock to the same condition: a hash preimage that either unlocks both legs or neither. Concretely, each side funds an HTLC against H = SHA256(s), and the only way to claim is to reveal s. The instant s appears on one chain to claim a leg, it's public, and the other side copies it to claim theirs. There is no sequence of events where your funds leave your control and the counterparty's don't arrive. If the trade doesn't complete, both sides refund.

So with an anonymous counterparty, the worst case is not theft. It's a wasted timelock window: your capital sat locked in the HTLC, the price you wanted moved, the opportunity passed — and at the end, you got your own asset back. You lost time and option value, not principal.

That reframing matters, because it tells you exactly what reputation has to solve in an agent market. Not "will this stranger steal from me" — the protocol already answered that. The real question is "will this stranger actually finish the trade, or quote me, watch me commit, and then ghost until my timelock expires?" That's griefing, and it's an economic attack, not a theft.

Execution rewards: skin in the game, enforced by the protocol

Griefing is cheap when there's no cost to walking away. An agent can spray attractive quotes across the market, let counterparties lock funds against them, and never reveal — tying up other agents' capital for the timelock duration at zero cost to itself. In a human market, the griefer burns their reputation. An anonymous agent has no reputation to burn.

Execution rewards make completion the profitable path. The mechanism is simple to state: counterparties that reliably settle accrue a verifiable, on-protocol track record and earn; counterparties that quote-and-ghost forfeit. The "skin in the game" isn't a vibe or a star rating hosted on someone's server — it's an economic position the agent has to stake and can lose, enforced by the same settlement layer that runs the trade.

The design goal is alignment, not punishment. You want the cheapest strategy for a rational agent to be settle the trades you quote. When forfeiture on non-completion is real and accrual on completion is real, the griefing strategy stops paying for itself. A reputation that the protocol itself mints and slashes can't be faked by spinning up a fresh wallet, because the fresh wallet starts with nothing staked and nothing earned.

Tiered KYC: a verified counterparty market the agent navigates itself

Execution rewards handle the "will it finish" question. Tiered KYC handles a different one: how much do I need to know about who I'm trading with for this particular trade?

The wrong answer is a single global policy — either force every interaction through full identity verification (which kills the permissionless, anonymous-by-default property that makes an agent market interesting) or verify nobody (which makes regulated or large-size flows impossible). Tiered KYC is the market-structure answer: counterparties exist at different, legible verification tiers, and the agent chooses the tier per trade.

For a small, fast, anonymous swap, trade with anyone. Atomic settlement still has your back; the worst case is still just a refund.
For larger size, where a wasted timelock window has real option cost, filter to counterparties that have posted a bond or built an execution-reward track record.
For flows that touch regulated rails, filter to counterparties that have passed identity verification at the tier that flow requires.

The crucial property: the agent picks the trust level; the protocol doesn't pick a custodian for it. A verified counterparty market is a filter, not a gate manned by an intermediary. You can dial trust up when the trade warrants it and all the way down when it doesn't, and at no tier does a third party take possession of the assets. That's the line between "a market with reputation in it" and "a market with a middleman in it."

Why this isn't just "add a reputation score"

It's tempting to flatten all of this into "give agents a reputation score." The difference is where the score lives and what it can do.

A reputation score hosted by a platform is a database row that platform controls. It can be edited, censored, or lost when the platform does; it's only as trustworthy as the host; and it reintroduces exactly the trusted third party an agent market is trying to avoid. Execution rewards and on-protocol verification tiers are different in kind: the track record is minted and slashed by the settlement layer itself, it's portable because it's not anyone's private database, and — critically — it sits on top of a settlement guarantee that already makes theft impossible. You're not trusting the reputation system with your money. You're using it to avoid wasting time, while the cryptography handles the part that actually protects principal.

How an agent touches this

In practice an agent doesn't implement any of it. It calls the MCP server — sealed-bid RFQ to discover a counterparty and a price, then HTLC creation to lock the legs, fused into one operation across six tools. The counterparty tier is a parameter on the request, and the execution-reward accounting is a property of the settlement layer the agent is already using. The package is hashlock-tech/mcp (scoped); source is on GitHub.

A note on maturity, stated the way we always state it: execution rewards and tiered KYC are the counterparty-market design layered on top of the atomic settlement core. The honest chain status of that core is unchanged and we say it in the same order every time — ETH mainnet live end-to-end; BTC signet-validated, mainnet pending; Sui deployed and CLI-tested (gateway wiring in progress). Chain claims are the one place a settlement project cannot afford to drift, and a post about trust is exactly the wrong place to start fudging them.

The open question

The settlement guarantee is the part I'm confident about: atomic clear-or-refund means a stranger can't take your principal. The counterparty-market design is the part worth arguing about. So here's the real question:

When an autonomous agent trades with a counterparty it will never see again, what should keep that counterparty honest — cryptographic skin-in-the-game that the protocol mints and slashes, or a reputation score that someone, somewhere, has to host and be trusted with? And if it's the former, where would you set the forfeiture so griefing stops paying without freezing out brand-new honest agents?

The methodology behind the settlement primitive is written up at hashlock.markets/docs, source is at github.com/Hashlock-Tech/hashlock-mcp, and the academic write-up is on SSRN. I'd genuinely like to hear how you'd tune the incentives — drop your reasoning in the comments.

BTC collateral vaults: how an agent posts native Bitcoin against an obligation without a custodian

Baris Sozen — Mon, 08 Jun 2026 06:07:36 +0000

Most "Bitcoin in DeFi" stories quietly route through a custodian or a wrapped representation. You send BTC somewhere, someone (or some bridge multisig) holds it, and you get an IOU on another chain. That works until the thing holding your BTC is the thing that fails. For an autonomous agent that has to post collateral against an obligation it can't babysit, "trust the custodian" is exactly the assumption we're trying to delete.

This post is about the alternative: a BTC collateral vault where native Bitcoin backs an obligation on another chain, the release is gated by a hashlock, and the worst case is a refund — not a loss. It's one of the primitives underneath Hashlock's settlement layer. I'll walk through the timelock ordering that makes it safe, the Bitcoin script that enforces it, and the failure modes you design around. Honest status up front: this is signet-validated, not BTC mainnet.

The problem in one sentence

An agent wants to commit BTC as collateral backing an action on Ethereum — settling a forward, anchoring one leg of a multi-leg trade, guaranteeing a payout — such that the BTC is released to the counterparty only if the corresponding obligation on Ethereum is fulfilled, and returns to its owner if it isn't. No third party should ever be able to hold, freeze, or abscond with the BTC in between.

That's a cross-chain conditional. Bitcoin can't read Ethereum state, and Ethereum can't read Bitcoin's. The only thing both chains can independently verify is a hash preimage. So the entire construction hangs on one shared secret.

The shared secret, and why timelock order is the whole game

Both legs lock to the same hash H = SHA256(s). Whoever knows the preimage s can claim. The instant s is revealed on one chain to claim a coin, it's public, and the other party copies it to claim the other coin. That's the atomic part: one preimage unlocks both legs or neither.

The danger isn't the hash. It's time. If both legs had the same expiry, the party who knows the secret could wait until the very last block, claim the counterparty's asset, and leave the counterparty no time to claim back. The fix is asymmetric timelocks, and getting the direction right is the single most important decision in the whole design.

Rule: the party who knows the secret takes the longer timelock.

Walk it through with Alice posting BTC collateral and Bob locking ETH:

Alice picks secret s, computes H. She funds the BTC vault output, spendable by Bob if he presents s, refundable to Alice after T_A = 48h.
Bob, seeing the BTC vault on-chain locked to H, funds the ETH-side HTLC, claimable by Alice if she presents s, refundable to Bob after T_B = 24h. Note T_B < T_A.
Alice claims the ETH by revealing s on Ethereum — she must do this before the 24h mark.
The moment Alice's claim lands, s is in a public Ethereum transaction. Bob reads it and uses it to claim the BTC, with the full window up to 48h to get his transaction mined.

If Alice never reveals, both legs refund: Bob after 24h, Alice after 48h. Nobody is stuck. The 24h gap exists precisely so Bob always has slack to react after Alice forces the reveal. Flip the timelocks and you hand the secret-holder a free option — they claim your asset and let yours expire. This is the classic atomic-swap safety argument, and a collateral vault is the same argument with the BTC leg held open longer as posted margin rather than swapped instantly.

What the Bitcoin side actually looks like

Bitcoin has no smart-contract VM, but it doesn't need one here. An HTLC is expressible directly in Script. The redeem condition is a simple if/else: spend by revealing the preimage and a signature from the claimant, or spend after an absolute locktime with a signature from the refunder.

OP_IF
    OP_SHA256 <H> OP_EQUALVERIFY
    <Bob_pubkey> OP_CHECKSIG
OP_ELSE
    <T_A> OP_CHECKLOCKTIMEVERIFY OP_DROP
    <Alice_pubkey> OP_CHECKSIG
OP_ENDIF

The refund branch uses OP_CHECKLOCKTIMEVERIFY (CLTV, BIP-65) for an absolute block-height/time lock; you can use OP_CHECKSEQUENCEVERIFY (CSV, BIP-112) instead if you want the timelock to count from when the vault was funded rather than from a fixed wall-clock point. The claim branch requires s such that SHA256(s) == H, plus Bob's signature so a watcher who merely sees s can't redirect the funds to themselves.

Two implementation notes that matter in practice:

Wrap it in P2WSH, or better, a Taproot (P2TR) output. With Taproot you put the refund path in a tapleaf and the cooperative path as the key-spend, so a vault that closes happily looks like an ordinary single-sig spend on-chain — smaller, cheaper, and more private. The HTLC script only ever appears if you take the script-path.
The refund transaction must stay mineable. You pre-sign the refund with a fee that's still credible at expiry, or you keep CPFP/anchor outputs available, because a refund you can't get into a block is not a refund. On Bitcoin you cannot assume you'll just "bump it later" inside a tight timelock window.

Why "vault," not "swap"

A plain atomic swap reveals the secret almost immediately — both sides want to close fast. A collateral vault deliberately holds the BTC leg open as backing for a longer-lived obligation: a forward that settles next week, a multi-leg position where the BTC leg must clear in lockstep with two others, a payout guarantee an agent posts before doing work. The hashlock is still the release condition; the timelock is now sized to the obligation's lifetime, not to a few confirmations.

The property an agent actually cares about: at every instant, the BTC is in exactly one of three states — locked (backing a live obligation), released (the obligation was met, preimage revealed), or refunded (it expired, BTC home). There is no fourth state where someone else is "holding it for you." That's the difference between this and a custodied vault, and it's the entire pitch.

Failure modes you have to design around

This is infrastructure, so the interesting part is what goes wrong:

Reveal-and-stall race. Alice reveals on Ethereum at the 23h59m mark hoping Bob's BTC claim won't confirm before his fee is too stale. The 24h/48h gap is the budget for this; it has to be sized against realistic Bitcoin mempool conditions, not optimistic ones.
Block-time granularity. Bitcoin's ~10-minute blocks mean a "24h" timelock is really "≈144 blocks ± variance." Your safety margins have to absorb that variance, especially near difficulty epoch boundaries.
Fee spikes. A refund or claim transaction priced at funding time can become unmineable in a congestion spike. Pre-signed refunds with anchor outputs (CPFP) are the standard mitigation.
Chain reorgs on the short leg. You wait for enough confirmations on the reveal before treating the secret as final; a shallow reorg that un-mines the reveal shouldn't strand the long leg.

None of these are exotic — they're the well-trodden hazards of cross-chain HTLCs. The point of building it once, correctly, behind an MCP tool: an agent calling create_htlc doesn't re-derive the timelock math every trade.

How an agent touches this

In Hashlock, an agent doesn't write Script. It calls the MCP server — sealed-bid RFQ to find a counterparty and price, then HTLC creation to lock the legs, fused into one operation across six tools. The BTC collateral vault is the Bitcoin-leg instantiation of that HTLC: same preimage, same timelock-ordering discipline, expressed in Script instead of Solidity. Assets stay native the entire time — no wrapping, no bridge multisig, no custodian.

Status, stated honestly

The BTC leg is signet-validated: the script, the timelock ordering, and the refund paths have been exercised end-to-end on Bitcoin's signet test network. BTC mainnet wiring is pending — I'm not going to tell you native BTC settlement is live in production when it isn't. For the record, the current honest chain status across the protocol: ETH mainnet live end-to-end; Sui contracts deployed and CLI-tested (gateway wiring in progress); BTC signet-validated, mainnet pending. We say it in the same order every time because chain claims are the one place a settlement project cannot afford to drift.

If you want the formal write-up of the settlement primitive, the methodology page lays out the RFQ-plus-HTLC construction: hashlock.markets/methodology. Source is on GitHub at github.com/Hashlock-Tech/hashlock-mcp, the package is hashlock-tech/mcp (scoped), and the academic version is on SSRN.

One question I'd genuinely like answers to: for a BTC collateral leg, where would you set the timelock gap — and what mempool assumption are you sizing it against? Drop a number and your reasoning in the comments.

Settlement means four different things now - a week mapping the agent economy's most overloaded word

Baris Sozen — Sun, 07 Jun 2026 06:08:49 +0000

This week the agent economy got another "settlement layer." Actually it got three. They don't agree on what the word means, and one of them raised $8M to keep saying it. So instead of a new argument, here's the map we drew across the week - four honest meanings of "settlement," what each one is genuinely good at, and the one job that none of the funded products this week actually cover.

This is a recap post. If you read along this week, you've seen the pieces; this is the through-line. If you didn't, this is the whole week in one place.

The week's biggest signal: a funded word

The freshest data point is AEON's raise - $8M from YZi Labs to build, in their words, a settlement layer for the agentic economy. Under the hood it's an x402 facilitator on BNB Chain, routing agent-to-merchant payments across a very large merchant network. That is a real and useful thing. It is also, very specifically, payment: an agent sends a stablecoin to a seller it has chosen, value moving one direction to a known recipient.

It sits next to two others that shipped recently and also wear the word:

Circle's Agent Stack + Nanopayments moves gas-free USDC down to a millionth of a dollar, batched across chains. That's settlement as machine-speed micropayment - still one asset, still one direction, optimized for volume and tiny amounts.
Fireblocks' Agentic Payments Suite puts a custodied vault between intent and execution: the vault holds funds and releases them when policy says so. That's settlement as custody-and-release - someone you trust holds the money in the middle.

Three products, three meanings: route a stablecoin, micropay at machine speed, custody-and-release. All three are legitimate infrastructure. Builders should use them where they fit.

The meaning none of them cover

Here's the job that falls through the gap between all three: two agents that don't trust each other, swapping different assets, possibly across two chains, with no one holding the funds in between.

A payment rail assumes you've already decided who gets paid and that value flows one way. A custodial vault assumes you're willing to trust the vault. A micropayment rail assumes a single asset moving in tiny increments. None of them gives you the property you actually need when two strangers trade: the whole thing clears as one unit, or it all refunds, and at no point has one side paid while the other hasn't.

That property has a name and it predates the agent economy: a hash-time-locked contract. Both sides lock against the same hash H = hash(s). One reveal of the secret s opens both locks; no reveal, and every lock refunds after its timeout. There is no half-settled state, and - the part that matters most - there is no custodian, validator quorum, or judge whose honesty or uptime you depend on. The math finishes the trade.

Stretch the same hashlock across a multi-hop path - pay BTC, receive ETH, route to a stablecoin - and reveal-once opens the entire path while never-reveal refunds all of it. The "leg one done, leg two stuck" state simply has nowhere to exist.

The week, in order

The four meanings didn't arrive as a list. We built toward them one day at a time, in public:

Monday - multi-leg atomicity. Why a single hashlock across every leg of a path is different from chaining several one-hop swaps and hoping none of them strand you halfway.
Wednesday - the counterparty-selection gap. Even with perfectly safe settlement, your agent still has to decide who to trade with. Safe settlement and good counterparty choice are different guarantees; a system that conflates them quietly leaves one unsolved. (This was, by our own analytics, the most-read thing we published all week - more on that below.)
Thursday - judge or math. The evaluator model (a trusted party rules on whether a deal was performed correctly, like Ethereum's ERC-8183 draft) versus cryptographic settlement. The honest answer: an evaluator is the right tool for subjective performance ("was this work any good?"), which no hash function can grade. For a clean asset-for-asset swap, where the only question is "did the assets move as agreed," a properly built lock already makes the wrong outcome impossible - and the judge is overhead.
Friday - the full taxonomy. All of it laid out long-form: custodian, validator set, judge, reputation, and math - five finishers for one question, with the limitations of each stated plainly.

The meta-point that held the week together: these are layers, not rivals. A mature agent stack probably uses several at once - atomic settlement underneath, an evaluator over the subjective slice, a reputation signal informing who to deal with at all. The mistake is using one answer for a question it can't answer: a custodian for trades too small to onboard, a validator set where a lock would do, a judge ruling on something math already settled.

A note on building in public, honestly

One thing we'll share because it's useful and slightly humbling: we track which posts actually move people to the site, and the pattern this week was unambiguous. The concrete posts - the specific primitive, the deep technical body with a real link into the docs - consistently out-pulled the provocative, jargon-light ones. The spiciest framing of the week drove the least traffic; the most specific drove the most. We're recalibrating accordingly. If you write developer content, that may be worth a test on your own numbers.

Where this leaves the map

When a product says "settlement layer for the agent economy," the useful reflex is to ask which one:

Route a stablecoin to a seller (payment).
Move a single asset at machine speed (micropayment).
Hold and release on policy (custodial).
Clear-or-refund between non-trusting parties with no one in the middle (cryptographic).

Each answers a different question and fails in a different way. Hashlock is the fourth: sealed-bid RFQ fused with HTLC atomic settlement, no bridge and no custodian. ETH mainnet is live end-to-end; BTC is signet-validated; Sui contracts are deployed and CLI-tested. We build for agents that need the fourth meaning and are honest about pointing you elsewhere when you need one of the other three.

How the primitive works: https://hashlock.markets/methodology?utm_source=devto&utm_medium=article&utm_campaign=2026-06-07-weekly-meta-recap

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

Code: https://github.com/Hashlock-Tech/hashlock-mcp

If you're building an agent that trades: when it settles a deal at 3am with a counterparty it has never met, which of the four is actually finishing the trade - and is that the right one for the failure you're most worried about?

The word 'settlement' is doing too much work: a builder's map of the agent-economy settlement layers

Baris Sozen — Sat, 06 Jun 2026 06:08:01 +0000

If you read agent-infrastructure announcements this month, you saw the same four words attached to very different machines: "the settlement layer for the agent economy." AEON used it. Circle's product copy leans on it. Fireblocks is in the same lane. We use it too.

That's a problem for anyone trying to actually build, because "settlement" has quietly come to mean at least four different things, and they have different trust assumptions, different failure modes, and different right answers depending on what your agent is doing. This is a short, opinionated map. No leaderboard, no "who wins" - just what each layer actually is, so you can pick the one your use case needs.

Meaning 1: route a stablecoin to a seller (payment-rail settlement)

The biggest funding signal this month was AEON, which raised an $8M pre-seed led by YZi Labs (IDG Capital, HashKey, Stanford Blockchain Builders Fund, and others participating). AEON describes itself as "the settlement layer for the agentic economy," and in partnership with BNB Chain it launched an x402 Facilitator handling agent-to-merchant payments - reportedly serving 2M+ users, ~30M monthly transactions, and connecting agents to 50M+ real-world merchants. It leans on x402, ERC-8004, Google AP2, and MCP.

What it is: a payment rail. An agent needs to pay a merchant; AEON routes a stablecoin from agent to seller, encodes the instruction in an HTTP 402, and produces an on-chain receipt. For agent-to-merchant commerce - the "my agent bought something from your store" flow - this is exactly the right shape.

What it isn't: a mechanism for two parties who don't trust each other to exchange different native assets and have both sides clear together. The money moves one direction, to a known seller. That's a different problem from a trade.

Meaning 2: move value at machine speed (micropayment-rail settlement)

Circle's Agent Stack, with its Nanopayments layer (launched May 3), is the cleanest example of a second meaning. Nanopayments moves gas-free USDC in amounts as small as $0.000001 - a millionth of a dollar - by batching enormous numbers of transfers off-chain over Circle Gateway and x402, then settling on-chain. Gateway already gives you chain-abstracted USDC across supported networks.

What it is: a micropayment rail, tuned for the high-frequency, sub-cent flows that machine-to-machine commerce generates (pay-per-API-call, pay-per-token, metered services). When your agent needs to pay for ten thousand tiny things without ten thousand gas fees, this is a genuinely impressive primitive.

What it isn't: a two-sided trade settlement either. It's still single-asset value transfer - USDC from A to B - just at remarkable granularity and throughput. The asset doesn't change hands for a different asset, and there's no "clear together or not at all" requirement, because there's only one leg.

Meaning 3: a trusted vault holds and releases (custodial settlement)

Fireblocks rolled out an Agentic Payments Suite for stablecoin transactions, extending its custody platform to agent flows. The model here is the most familiar one in institutional crypto: a custodian holds funds in a vault, and releases them when policy conditions are met.

What it is: custodial settlement. It's battle-tested, it has rich policy controls, and for institutions that already trust Fireblocks with custody, extending that to agents is a small, sensible step.

What it isn't: trust-minimized. By design, someone you trust is holding the money between intent and execution. For many enterprises that's a feature - the custodian is also the compliance and recovery surface. But it means the trust assumption is "the custodian behaves," which is a different budget from "no one holds my money at any point."

A fourth meaning is forming in the standards layer

Worth flagging, not litigating: the BNBAgent SDK went live on BNB Chain testnet as the first implementation of ERC-8183, which pairs ERC-8004 agent identity with on-chain escrow and an evaluator that verifies a job before funds release or refund. Mainnet is "coming soon." This is escrow-with-a-judge - powerful where the dispute is "was the work done well," subjective and off-chain. (We dug into the judge-vs-math tradeoff separately; the short version is that an evaluator earns its keep on subjective delivery and is overhead you can delete on a clean asset-for-asset swap.)

Meaning 4: clear-or-refund with no one in the middle (cryptographic settlement)

This is the layer we build, and the one the other three don't cover: two parties exchanging different native assets, possibly across chains, who don't trust each other, with no custodian and no bridge.

The primitive is a sealed-bid RFQ paired with hash-time-locked contracts. Both legs of the trade are locked under one hashlock. Reveal the preimage once and the whole path opens; never reveal it and every leg refunds. There is no vault holding your assets, no evaluator to attest, no wrapped IOU standing in for the real thing. The trade clears as a single unit or it doesn't happen.

The honest limits, because a map without limits is marketing: cryptographic atomicity can only adjudicate whether assets moved, not whether subjective work was done well - that's the evaluator's domain. And our chain status is specific: Ethereum mainnet is live end-to-end; the BTC HTLC path is signet-validated with mainnet pending; Sui contracts are deployed and CLI-tested with gateway wiring in progress. Rails ready, more trains coming.

One concrete piece we've been building toward: forward settlement

A question this map raises: if no one holds the money, how do you settle a trade that's agreed now but executes later? That's the forward-settlement case - an agent locks in terms today for delivery at a future point. The custodial answer is "a vault holds the margin in between." The atomic answer is to keep the same clear-or-refund guarantee across a time dimension: terms commit now, the hash-time-lock structure carries the settlement window, and neither side has to trust the other to hold anything during the wait. It's the same primitive, extended along time instead of just across chains - and it's why "no custodian" doesn't have to mean "spot only."

How to actually pick

Ask one question: what does your agent's transaction need to be true at the moment of settlement?

Paying a known merchant a stablecoin → payment rail (AEON, x402 facilitators).
Paying for thousands of tiny metered services → micropayment rail (Circle Nanopayments).
An institution comfortable with a trusted vault → custodial settlement (Fireblocks).
A job where "was it done well" is subjective → evaluator escrow (ERC-8183).
Two non-trusting parties swapping different native assets, no middleman → cryptographic atomic settlement.

Most real agent stacks will use more than one of these. They compose; they're not rivals. The mistake is assuming "settlement layer" means the same thing in two announcements - it almost never does this month.

Which meaning is your agent actually relying on? I'd genuinely like to hear which layer you're picking and why - especially if your use case sits between two of them.

Map and tools: https://hashlock.markets/?utm_source=devto&utm_medium=article&utm_campaign=2026-06-06-three-settlements

Methodology and the academic basis for the atomic-settlement claims: https://hashlock.markets/methodology and the SSRN whitepaper (abstract_id=6712722).