DEV Community: Baris Sozen

Atomic settlement is not just for tokens: shipping compute-capacity MCP tools this week

Baris Sozen — Fri, 29 May 2026 06:11:13 +0000

An agent that cannot pay for its own compute is a stranded asset. It can reason; it cannot continue reasoning. That sentence sounds glib until you start wiring an autonomous agent and realise the boring constraint underneath every interesting behaviour is the same: can this agent acquire the next block of compute it needs, on its own, without a human in the loop?

This week, two PRs in hashlock-mcp merged that take a small but meaningful step toward that constraint becoming first-class on our MCP surface. This is a product update, not a manifesto. The point is to write down exactly what shipped, what the mechanism is, and what it lets an agent do that it could not do on Monday.

What shipped

Two PRs in Hashlock-Tech/hashlock-mcp:

PR #8 (feat(compute): MCP create_compute_capacity_listing tool (PR2.1b)) — merged 2026-05-26.
PR #9 (feat/compute-pr2.2-mcp-tool) — merged 2026-05-27.

Together they introduce a tool path on the MCP server for treating a block of compute — GPU hours, inference credits, model-access windows, whatever the provider chooses to denominate — as something an agent can list, discover, and settle against using the same primitive the server already uses for token swaps. The effective MCP tool count on the server moves from six to eight.

The npm package @hashlock-tech/mcp is still sitting at 0.4.0 as I write this — the new tool surface is in the repo and live in the running server; the version cut to publish those tools downstream is the next step in our release pipeline this week. We are being deliberate about not bumping the published package version until the tool docs and examples land in /docs together. If you are tracking the version, that is why it has been sticky.

Why compute is the obvious next thing to settle atomically

The honest framing: there is nothing magical about tokens that makes them the canonical thing two agents exchange. Tokens are well-defined, transferrable on-chain, and easy to lock. That is why every cross-chain settlement primitive in existence — bridges, intent protocols, atomic swaps — started with token-for-token.

But if you ask what an autonomous agent actually consumes in order to act in the world, the list is short and tokens are not at the top of it. The list is compute, data, model access, and storage. The thing an agent runs out of first is usually not money; it is the resource that money was a placeholder for.

A few specific examples to make this concrete.

A research agent has a budget in USDC and a long-running task that needs a few hours of GPU time. The agent does not want to open an account at a cloud provider, hold a credit card on file, and sign a usage agreement. It wants to spot-buy a block of GPU hours from whoever is offering them right now, settle atomically, get a credential it can use, and move on.

An inference-routing agent picks between model providers per call. Today it does this through pre-paid accounts at each provider, which means it carries N counterparty exposures and N reconciliation problems. With atomic settlement of inference credits, it can buy a small block from a provider at the moment of use, with the same trust-minimised guarantee a token swap gives it: pay and receive, or nothing happens.

A training agent has spare capacity on a machine it controls and wants to sell that capacity into the open market when it is idle. Today this requires a custodial marketplace that takes a cut and holds both sides' assets between match and settle. With an atomic settlement primitive, the seller posts an HTLC-keyed listing, the buyer locks payment on the other side, both legs resolve or neither does, and no marketplace ever touches either asset.

These are not exotic flows. They are what an agent doing useful work is going to need to do thousands of times. The settlement primitive that already works for tokens is, by construction, also the right primitive for compute — because the primitive does not care what the leg is denominated in, only that both legs have a hash, a timelock, and a refund path.

The mechanism, written out

The shape of a compute-capacity settlement using the new MCP tools is structurally identical to a token settlement. The reason we are excited about this week's PRs is precisely that it did not need to be a new primitive. The same HTLC + sealed-bid RFQ flow does the job; we are just extending what the listing leg is allowed to describe.

Provider lists capacity. The provider calls create_compute_capacity_listing and describes what they are offering: a quantity of compute (a unit the provider defines — e.g. N GPU-hours of class X, N inference calls against model Y, N storage-GB-months), a price denominated in some chain-native asset, a delivery commitment (how the credential is handed over once settlement clears), and a timelock window.
Consumer agent discovers and quotes. The same RFQ discovery path that already exists for token pairs returns capacity listings. The consumer agent inspects them, picks one, and submits a sealed bid against it.
Both sides lock. The consumer locks payment in an HTLC on its chain, keyed to a hash h. The provider, having seen the consumer's lock with matching hash, amount, and timelock, locks the credential commitment in a corresponding HTLC on the chain where the credential will be claimed.
Atomic settle or refund. The consumer reveals the preimage of h to claim the credential. That same preimage, now public, lets the provider claim payment. If anything stalls — bad lock, missing reveal, expired timelock — both sides refund. No third party ever held either asset.

The asymmetry to be honest about: the credential leg of a compute trade is not as clean as a token leg. A token, once transferred, is unambiguously yours. A credential — an API key, an access token, a signed authorisation — is a capability. The provider has to commit to honouring it after the preimage is revealed, and the consumer has to be able to verify the credential is what it says it is. We handle this today by binding the credential cryptographically into the HTLC commit so that revealing the preimage reveals the credential, and by requiring the provider to publish a verifiable specification of what the credential entitles the holder to before any consumer locks against it.

This is the part of the design we are most actively iterating on, and the part where the next PRs after #8 and #9 will land. We would rather state that plainly than oversell.

Honest chain status

The chain-status section every Hashlock post carries, exactly as it ought to read this week:

Ethereum mainnet is live end-to-end today. Token settlement and now compute-capacity listings.
Bitcoin HTLC is signet-validated, mainnet pending. Compute-capacity listings priced in BTC therefore work on signet and not yet on mainnet.
Sui contracts are deployed and CLI-tested, with gateway wiring in progress. The compute-capacity tool path is plumbed through the same gateway; capacity listings on Sui follow the gateway timeline.
Roadmap still names Base, Arbitrum, Solana, TON.
npm @hashlock-tech/mcp is at 0.4.0 (sticky since 19 May); the new tool surface is live on the server, the package version bump to ship those tools downstream is the next pipeline step.

The MCP server is hashlock-tech/mcp (scoped). The MCP — Model Context Protocol — is the open protocol Anthropic introduced for connecting models to external systems; it is the contract our six (now eight) tools speak.

What this lets an agent do that it could not do on Monday

Two specific things.

It lets an agent treat compute as a thing it trades, not a service it subscribes to. The mental model shifts from "I have accounts at three providers" to "there is a market in GPU-hours, I check the depth, I lock and settle when the price is right." That changes what an agent can plan, because it can hold a budget in tokens and convert to compute at the moment of use, not in advance.

It lets the providers selling that compute do so without a custodial marketplace in the middle. A small lab with spare GPU capacity can list it. A specialised model host can sell direct access. There is no platform fee for the matching, because the matching is the MCP server's discovery surface, and there is no float held between match and settle, because settlement is atomic on both legs.

We do not yet have an agent in production buying compute via these tools — the listing tool merged two days ago. What we have is the primitive, and the open question of who is going to use it first. If you are building an agent that runs into the compute-acquisition problem in the way we described above, we would like to hear from you in the comments — both what is missing in the current tool surface and what would make this a path you would actually wire your agent to.

What to read

Code: Hashlock-Tech/hashlock-mcp, specifically the PR #8 and PR #9 diffs for the new tool.
npm: @hashlock-tech/mcp (scoped).
Tool docs: hashlock.markets/docs — compute-capacity tool reference lands here as the docs publish.
Methodology: hashlock.markets/methodology.
Whitepaper (SSRN): the underlying mechanism design.

The question

We are interested in the part we cannot answer from the protocol side: if your agent could spot-buy a block of compute from another agent, atomically settled, with no custodian and no platform in between — what would it spend on first? GPU hours for a training run? Inference credits for a model you do not have a contract with? Something we have not thought of?

Custodial vs trust-minimized: two settlement layers for the agent economy

Baris Sozen — Thu, 28 May 2026 06:11:55 +0000

"Settlement layer for the agent economy" is suddenly a crowded sentence.

In the last few weeks, two very different things have started competing for it. OKX Agent Payments Protocol (APP) announced in May 2026 — backed by AWS, Alibaba Cloud, Uniswap, Paxos, QuickNode, with ecosystem support from Base, Ethereum Foundation, Solana, Sui, Aptos, Optimism — describes itself as the settlement layer where AI agents pay each other. AEON's $8M pre-seed (May 20, YZi Labs) described itself the same way. There is a list now, and it is getting longer.

We build one of the things on this list, and we think the framing is wrong. These are not rivals jostling for the same slot. They are two different layers, and they answer two different versions of the same question: what does an agent need to settle a trade?

This piece walks through the two layers, where each is the right answer, and why an honest comparison gets you further than picking sides.

What APP and other custodial-venue protocols actually do

A useful way to read OKX APP — and similar moves coming from the larger exchanges — is to treat them as a venue layer. An exchange already holds inventory across many chains. It already has the risk engines, the liquidity, the legal arrangements with banks and partners. Adding an agent-facing API on top of that machinery is a relatively short walk.

What an agent gets, in exchange, is breadth. Many chains, many assets, batched and netted settlement against deep internal books, and fast execution because the exchange is just moving entries in its own ledger. For an agent whose job is "find a price somewhere and execute now," that is a powerful primitive.

What the agent gives up, in exchange, is a counterparty. At any moment between deposit and withdrawal, the agent's balance is the venue's promise to pay. That promise is normally good. The agent has no way to verify, from inside its own logic, that it still is.

This is not a criticism of OKX APP. It is the structural shape of any venue-mediated settlement layer: the venue is broad because it is in the middle, and it is in the middle because you trusted it to be. That is the deal — you knew you were making it.

What trust-minimized atomic settlement does

We make the other thing on the list — the primitive layer. Hashlock is sealed-bid RFQ fused with HTLC atomic settlement. No bridge, no custodian, no wrapped asset.

The mechanism, briefly, so the comparison is concrete:

Two agents agree on a swap. Maker locks asset A on chain X inside an HTLC keyed to a hash h.
Taker locks asset B on chain Y, keyed to the same h. Taker only locks once they have seen maker's lock on chain X, with the same h, the same amount, and a timelock long enough.
Either taker reveals the preimage of h to claim asset A on chain X, which atomically lets maker use the same preimage to claim asset B on chain Y — both halves of the trade settle, or neither does.
If anything stalls, the timelocks refund both sides.

There is no point in the flow at which a third party holds either asset. The assets stay native: BTC stays on Bitcoin, ETH stays on Ethereum. The only thing that crosses chains is a hash.

The honest chain status, written exactly: Ethereum mainnet is live end-to-end today. Bitcoin HTLC is signet-validated, mainnet pending. Sui contracts are deployed and CLI-tested, gateway wiring is in progress. Roadmap: Base, Arbitrum, Solana, TON. The MCP server hashlock-tech/mcp (scoped) ships six tools an agent can call to discover pairs, request quotes, settle, and refund.

Two different agent-trust problems

If you look at the two architectures side by side, they answer two different questions an agent has to answer before it can transact.

Question 1 — "Whom am I trusting, and how much?" A custodial venue layer answers this clearly: you are trusting this exchange, for the size of your inventory there, until you withdraw. If your agent is comfortable with that bound, the venue layer is the right tool. It will be faster and broader than anything trust-minimized for a long time.

Question 2 — "Can I trade with a counterparty I don't trust at all?" A trust-minimized atomic settlement layer answers this clearly: yes, because no one holds either side's asset until the other side's asset has been claimed in the same atomic step. The agent does not have to trust the counterparty or a venue between them. It has to trust the math of a hash, and the timelocks it set.

That is the actual distinction. Not "centralized vs decentralized" — that argument is decades old and produces more heat than insight. The distinction is: who is the agent trusting, and over what window?

Why both layers exist at the same time

A useful analogy. In traditional finance, an institution can settle by sending money to a clearing member who clears it onward, or it can settle DvP — delivery versus payment, atomic, no intermediary holds both legs at once. Both exist. Both are correct for different trades. No one writes posts asking which one is "the" settlement layer because the answer is plainly "the one that fits the trade."

The same thing is happening here, just with the labels still being settled. A custodial venue layer is good for high-frequency, in-venue, in-inventory trading where the agent's risk to the venue is bounded and short. A trust-minimized settlement layer is good for cross-chain, cross-counterparty, native-asset trades where the agent is not allowed (or unwilling) to take on venue counterparty risk.

The agent economy will need both. It will also need the layers underneath and around them — agent identity (ERC-8004), payment plumbing (x402), trust/intent (Google AP2, ACP). What you do not want is one of these layers to colonize the others by overloading the word "settlement."

What we'd flag if you're picking a layer

For people who actually have to choose — building an agent, integrating one — three concrete things to look for.

First, what is the asset, at the moment of settlement? Inside a custodial venue, it is the venue's promise to pay. Inside an HTLC swap, it is the asset itself, on its own chain, controlled by the agent's key. Two different things, both reasonable, depending on what your agent is doing.

Second, what failure modes are atomic, and which are graceful? Custodial venues handle most failure modes gracefully — pause, requeue, refund, customer support — but the hard failure (the venue itself) is not graceful at all; it is total. Trust-minimized swaps have ungraceful soft failures (timelock expires, capital idle for a window) but the hard failure (asset stolen) is structurally absent.

Third, how does the layer compose? A venue layer is hard to compose with — you are mostly making API calls into a single counterparty. A primitive layer is easier to compose with — an agent can put atomic settlement under another layer's payment intent (for instance, an x402-style HTTP payment can resolve to an HTLC swap underneath), or wrap multi-leg trades around it.

None of this requires the layers to fight. The honest read is that a fleet of agents will use a custodial venue when the trade is in-inventory, and a trust-minimized primitive when the trade is cross-chain, cross-counterparty, or worth more than the agent's trust budget for any single venue. That is also how human traders use the same options today.

Where this leaves us

We are happy that "settlement layer for the agent economy" is a sentence people are writing. We are less happy that it is being used for two things at once without flagging which one.

If the answer to what is the agent holding at settlement? is "the venue's promise to pay," you are looking at a custodial venue layer — and OKX APP is a serious example of that. If the answer is "the asset itself, on its own chain, atomically swapped against the other leg," you are looking at a trust-minimized primitive layer. The two are complementary; both will exist; agents will pick between them per trade.

That is a healthier conversation than crowning a single "settlement layer."

Reading and code:

https://hashlock.markets/?utm_source=devto&utm_medium=article&utm_campaign=2026-05-28-okx-app-vs-trust-min
npm: @hashlock-tech/mcp
GitHub: https://github.com/Hashlock-Tech/hashlock-mcp
Methodology: https://hashlock.markets/methodology/?utm_source=devto&utm_medium=article&utm_campaign=2026-05-28-okx-app-vs-trust-min
Whitepaper (SSRN): https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722

A real question for builders: which question is your agent actually trying to answer with "settlement" — who do I trust, and how much, or can I trade with someone I don't trust at all? Different answers should pick different layers.

Atomic settlement guarantees your agent won't be robbed. It says nothing about who trades well with it.

Baris Sozen — Wed, 27 May 2026 06:09:06 +0000

Trustless settlement has a clean promise. When two agents settle through a hash-time-locked contract, either both legs of the trade complete or both refund. There is no path where one side walks away with the other's funds. Counterparty risk — the risk that the entity on the other side of your trade fails to deliver — is removed by construction, not by reputation.

That is real, and it matters. But it is worth being precise about what it does and does not cover, because the gap is where most of the work in an agent market actually lives.

Two kinds of failure

Settlement atomicity solves exactly one failure: the hard failure. Your counterparty takes your money and disappears. In an atomic settlement, that outcome is unreachable — the preimage either resolves both legs or neither.

A market has a second kind of failure, and atomicity does nothing about it. Call it the soft failure. Your counterparty does not rob you — they just trade badly with you. They quote you a price eight basis points wide when the rest of the field is at two. They respond to your RFQ and then leave the HTLC untouched until it times out, so you get your funds back, but only after your capital sat locked and idle for the full timeout window. They accept one leg of a multi-step trade and then stall on the leg you needed to clear fast.

Nothing here is theft. Every one of these degrades the market anyway, and an agent transacting thousands of times has no human noticing the pattern.

A human trader handles soft failures with memory. You remember the desk that always quotes wide. You stop calling the counterparty that ghosted you last quarter. That memory is a reputation system running quietly in a person's head. An autonomous agent has no such thing — unless the protocol gives it one.

Atomicity is necessary, not sufficient

This is the part the "trustless" framing tends to skip. Removing counterparty risk is necessary for an agent market — without it, agents cannot transact with strangers at all. But it is not sufficient for a good agent market. A market where you cannot be robbed, but every counterparty quotes wide and half of them ghost, is technically trustless and practically unusable.

So a settlement layer built for agents has to answer a second question, separate from "how do we make settlement safe": how does the market reward the counterparties that execute well, and steer flow away from the ones that do not — without a central operator deciding who is good?

We think the answer has two parts, and they are designed to work together.

Part one: price execution quality directly

The first part is what we call execution rewards. The idea is to measure execution quality from the settlement record itself — which is objective, on-chain, and unforgeable — and let that measurement feed back into the terms a counterparty gets.

The settlement layer already sees everything needed. It sees whether a responder's quote was competitive against the rest of the sealed-bid field. It sees whether a committed leg settled on the fast path or was left to time out. It sees whether a counterparty completes the legs of a multi-step trade in the order and window they agreed to. None of this needs a survey or a star rating — it is all already in the record of what the agent actually did.

Execution rewards turn that record into a price. A counterparty with a clean settlement history — tight quotes, fast-path completions, no abandoned legs — earns better standing: priority in RFQ matching, lower protocol fees on the next trade, access to larger size. A counterparty that consistently quotes wide or lets locks expire earns the opposite. The reward is not a token airdrop or a loyalty scheme. It is the market repricing access based on what an agent has verifiably done.

The important property: this is not a trust input. It is a behavior output. Nobody vouches for a counterparty. The settlement history vouches, or it does not.

Part two: make identity a dial, not a gate

The second part is harder, and it is where most settlement systems pick a bad extreme.

One extreme is KYC everyone. Every agent verifies a legal identity before it can trade at all. This is the custodial-exchange model, and it quietly kills the thing that makes an agent economy interesting: an agent spun up this morning, with no paperwork and no human in the loop, can do nothing. The permissionless property is gone.

The other extreme is KYC no one. Pure pseudonymity. This is clean, but it means an agent has no way to ever reach the parts of a market that genuinely require a known counterparty — larger sizes, regulated venues, institutional flow — and no counterparty has any recourse beyond the collateral in front of it.

Tiered KYC is the deliberate middle. Identity is not a gate you pass once. It is a dial. An agent can trade fully pseudonymously — and when it does, the protocol asks for more: more collateral posted against each obligation, smaller maximum size, shorter timeout windows. The pseudonymous agent is not excluded; it is priced. As an agent verifies more — a persistent on-chain identity, a staked bond, a legal entity behind it — the dial moves: collateral requirements fall, size limits rise, and a wider set of counterparties become reachable.

The reframe that makes this work: identity becomes a form of collateral. A pseudonymous agent backs its trades with capital. A verified agent backs some of that with identity instead. Neither is forced; each agent picks the point on the dial that fits what it is trying to do. A high-frequency micro-trade agent may rationally stay fully anonymous and over-collateralize. An agent moving institutional size will verify, because the better terms are worth it.

Why the two parts need each other

Execution rewards without tiered identity have a Sybil problem: a counterparty that earns a bad settlement history just discards the identity and spins up a fresh one. Tiered KYC is what gives execution history something to attach to — a bad history has a cost only if starting over also has a cost.

Tiered KYC without execution rewards is just a credential check: it tells you an agent verified something, not that it trades well. A verified agent can still quote wide and ghost.

Together they form one system. Execution rewards measure behavior; tiered identity makes that measurement stick and graduates how much the market is willing to expose to a given counterparty. Atomic settlement sits underneath both, guaranteeing that whatever terms two agents agree to, the settlement itself cannot be the thing that fails.

The honest status

This is design, and it deserves a straight status report rather than a confident one. Atomic HTLC settlement is live end-to-end on Ethereum mainnet today. The Bitcoin hash-time-lock construction is validated on signet, with mainnet pending; the Sui contracts are deployed and CLI-tested, with gateway wiring in progress. Execution rewards and tiered KYC are part of the protocol design we are building toward — the settlement primitive they sit on top of is the part that is live. We would rather state that plainly than blur the line between what runs today and what is designed.

For an agent, none of this should be hand-managed. Reading a counterparty's settlement standing, choosing where to sit on the identity dial, deciding whether better terms justify verifying — that belongs behind a tool call. Our MCP server (hashlock-tech/mcp, scoped — six tools) is the surface where an agent reasons about those decisions rather than the mechanics underneath them. MCP is the open protocol Anthropic introduced for connecting models to external systems.

The question

The trustless framing answers "can my agent be robbed." It is the wrong question to stop on. The question a builder should actually be asking is the second one: in the market your agent trades in, what happens to the counterparty that executes badly but never technically defaults — and if the answer is "nothing," how is your agent supposed to tell a good counterparty from a bad one?

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

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

Your trading agent doesn't own Bitcoin. It owns a promise.

Baris Sozen — Tue, 26 May 2026 06:09:31 +0000

Ask a trading agent what it holds and it will give you a clean answer: Bitcoin, dollars, some treasuries. Then read the actual wallet. What you find is a wrapped token, a bridged stablecoin, a tokenized note. None of those things are the asset. Each one is a promise that the asset exists somewhere else, in someone else's custody, and that the someone will honor the claim when asked.

That gap — between what an agent reports holding and what it actually holds — is small enough to ignore right up until it isn't. It is worth looking at directly.

What a wrapper actually is

Take wrapped Bitcoin, the most familiar case. Bitcoin the chain cannot run the contract logic that most trading venues need, so to "use BTC" somewhere else you wrap it: you hand the real Bitcoin to a custodian, and the custodian mints a token on the destination chain that represents a claim on it. The token moves and trades freely. The real coins sit still, in the custodian's keys.

This is convenient, and it is everywhere. It is also a quiet swap of one kind of thing for another. Native Bitcoin is a bearer asset: holding the key is ownership, with no one else in the loop. A wrapped token is a claim against an intermediary. The token is worth what the asset is worth only as long as the institution behind it stays solvent, stays honest, and stays in business. The moment that stops being true, the token is worth whatever the market thinks the recovery will be.

And it is not only Bitcoin. Bridged stablecoins are claims on a bridge's reserve. Tokenized treasuries are claims on an issuer's brokerage account. Liquid staking tokens are claims on a validator set. Walk through a working trading agent's inventory and a striking share of it is not assets — it is IOUs, each one as good as the institution standing behind it.

Why this is worse for an agent than for a human

A human trader holds wrapped and tokenized assets too, and mostly does fine. The reason is that a human is quietly running a trust model the whole time. You know which custodians have been around, which had a bad year, which name keeps coming up in the wrong kind of news. You read a depeg as it starts. You can decide, on a hunch, to move early.

An autonomous agent has none of that. It has no instinct for a brand, no memory of last cycle's blowups, no feel for when a quiet story is about to get loud. It cannot open a custodian's books and verify solvency. It cannot confirm that the locked backing pile is whole and unencumbered. What it can do is read a token balance and a price, and those two numbers look identical whether the backing is pristine or already gone.

So an agent holding wrapped assets is holding unverifiable trust — trust it did not evaluate, because it has no way to evaluate it. Multiply that across a fleet of agents transacting continuously, with no human in the loop on any single position, and the wrapper stops being a convenience and starts being the largest unpriced risk in the system.

There is a second-order problem too. Every wrapped asset has a backing pile — the real coins or reserves held in one place. That pile is a single, standing, valuable target. The more agent capital flows into wrapped form, the bigger and more attractive the honeypot, and the more an individual agent's safety depends on infrastructure it cannot see.

The fix is not a better custodian

The instinct is to ask for a more trustworthy wrapper: better attestations, more frequent proof-of-reserves, a more reputable name. That helps a human, because a human can weigh reputation. It does not close the gap for an agent, because the agent still cannot verify any of it — it can only be told, and being told is not the same as knowing.

The structural fix is different. It is settlement that never converts the asset into someone's liability in the first place.

Concretely: the asset stays native on its own chain. Bitcoin stays as Bitcoin, locked in a hash-time-locked script on the Bitcoin chain itself — not handed to anyone, not represented by a minted token. What crosses between chains is not the asset and not custody of it. It is a single piece of information: the hash of a secret. The obligation the asset backs lives on a chain that can run real contract logic; the asset lives where it already is; the two are coupled only by that shared hash, and resolved by revealing a preimage or by a timeout. No custodian ever holds the unilateral ability to move the coins.

This is the design behind what we call a BTC collateral vault, and it generalizes: settle and collateralize with assets in their native, bearer form, and move information across chains instead of moving custody. An agent does not have to audit a custodian if there is no custodian in the path.

For an autonomous agent, this should not be hand-managed plumbing. Watching a locked output, coordinating timeouts across chains with very different block times, building the right spend path — that belongs behind a tool call. Our MCP server (hashlock-tech/mcp, scoped — six tools) exists so an agent reasons about the position rather than the script-level mechanics. MCP is the open protocol Anthropic introduced for connecting models to external systems.

The honest status

This is a direction, and it deserves a straight status report rather than a confident one. Only Ethereum mainnet is live end-to-end today. The Bitcoin hash-time-lock construction is validated on signet, with mainnet pending. The Sui contracts are deployed and CLI-tested, with gateway wiring in progress. A native-collateral vault is a design we are building toward — and the tradeoffs are real even when it ships: collateral sits locked for the life of a position, and Bitcoin's roughly ten-minute blocks make timeout windows coarse. Removing the custodian is not free. We think it is worth the price for the assets an agent is meant to hold for real.

The question

Wrapped assets made everything usable everywhere by making everything custodial everywhere. For a human running a trust model in the background, that trade is often fine. For an autonomous agent that cannot run that model, it is an open question whether it should ever hold a custodial asset at all.

So here is the question for anyone building trading agents: do you actually know what your agent owns right now — the asset, or a promise of the asset? And if it is a promise, who is on the other side of it, and what happens to your agent the day that promise is tested?

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

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

Using Bitcoin as collateral without wrapping it: the design of a BTC collateral vault

Baris Sozen — Mon, 25 May 2026 09:32:26 +0000

This is the Monday deep-dive — one mechanism, examined closely.

Suppose a trading agent needs to post collateral, and the asset it wants to post is Bitcoin. That is a reasonable thing to want: BTC is the deepest, most liquid collateral asset in crypto. The problem is that Bitcoin the chain cannot run the contract logic a collateralized position needs — no expressive smart contracts, no objects, no state machine watching a position over time. So the collateral lives on one chain and the obligation it backs lives on another.

The standard fix is to wrap the Bitcoin. We think there is a better-shaped one, and it is worth walking through carefully.

What wrapping actually costs you

Wrapping BTC means handing it to a custodian — or a federation, or a bridge contract — that holds the real Bitcoin and mints a token on the destination chain representing a claim on it. Once you hold the token, you can use it as collateral anywhere that chain's contracts run.

You have also done three things you may not have meant to do. You converted a bearer asset into a claim against an intermediary. You contributed to a honeypot — the locked BTC pile that backs every wrapped token is a single, standing, valuable target. And you made your collateral's integrity depend on something an agent has no good way to audit: the ongoing honesty and solvency of whoever holds the real coins.

For a trustless settlement system, that is the wrong trade. The whole point of settling without a custodian is undone the moment the collateral backing the settlement is itself custodial.

The design: keep the Bitcoin on Bitcoin

A collateral vault takes the opposite approach. The Bitcoin never moves to another chain and is never represented by a minted token. It stays as native BTC, locked in a script on the Bitcoin chain itself. What crosses chains is not the asset — it is a single piece of information: the hash of a secret.

Here is the shape of it. On Bitcoin, the collateral is locked into a P2WSH output — a pay-to-witness-script-hash output whose redeem script is a hash-time-lock. The script has two spend paths: a hashlock path, spendable by presenting the preimage of a specific hash, and a timelock path, spendable by the original depositor after a block-height deadline. This is the same HTLC construction used for atomic swaps, applied here to a longer-lived position rather than an instant exchange.

On the other chain — for us, Sui, where our Move contracts are deployed — lives the obligation the collateral backs: a forward to deliver, a loan to repay, a leg of a multi-step trade. The Sui-side contract is written so that the outcome of that obligation controls who learns the preimage, and when.

The two chains are coupled by exactly one shared value: the hash. Bitcoin Script cannot read Sui state, and Sui cannot read Bitcoin's UTXO set. But both can agree, in advance, on a hash — and the preimage of that hash becomes the single key that resolves the position on both sides at once.

The outcome paths

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

If the obligor performs — delivers the forward, repays the loan — the protocol releases the preimage along the agreed path, and the BTC settles to whoever the performance entitles. The pattern is reveal-to-claim: the act of claiming on one side publishes the secret that resolves the other.

If the obligor defaults, the hashlock path routes the BTC to the counterparty as the agreed remedy. The collateral does exactly what collateral is for — it makes the counterparty whole without anyone needing to chase the defaulter through courts or reputation.

If nothing happens — the position is simply abandoned — the timelock path returns the BTC to the depositor after the deadline. No counterparty, no protocol, and no custodian can hold the coins past that block height. The refund is enforced by Bitcoin consensus, not by anyone's cooperation.

In every path, the BTC was native Bitcoin the whole time, and no third party ever had the unilateral ability to move it.

What the vault deliberately does not do

A vault is not a margin account, and it is worth being blunt about that. Bitcoin Script has no access to a price feed, and we are not going to pretend otherwise by smuggling an oracle into the design. That means the vault cannot do a real-time margin call — it cannot watch a price and liquidate the instant a collateral ratio is breached. Its resolution is discrete: it triggers on performance, on default, or on a deadline, not on a continuous price.

For a large class of agent-to-agent use cases that is fine, because the obligation itself is discrete — a forward with a fixed delivery date, a fixed-term loan, a bonded commitment. For a position that genuinely needs continuous mark-to-market, a hash-time-locked vault is the wrong tool, and we would say so rather than oversell it.

Where this sits for an agent

For an autonomous agent, none of the above should be hand-managed. Watching a P2WSH output, coordinating two timelocks across chains with very different block times, constructing the witness needed to spend a hashlock path — that is exactly the kind of work that belongs behind a tool call. Our MCP server (hashlock-tech/mcp, scoped — six tools) exists so an agent reasons about the position rather than the plumbing: it commits to a hash, funds a leg, checks status, and lets the protocol handle the script-level mechanics. MCP is the open protocol Anthropic introduced for connecting models to external systems; a vault is just another set of tool calls on that surface.

The honest limits

This is a design, and it deserves a straight status report. The Bitcoin P2WSH HTLC is validated on signet — Bitcoin's test network — with mainnet still pending. The Sui contracts are deployed and CLI-tested, with gateway wiring in progress. The only place atomic settlement is live end-to-end today is Ethereum mainnet. So a BTC collateral vault is a design we are building toward, not a button you can press this morning — and we would rather state that plainly than blur it.

The tradeoffs are real even once it ships. Bitcoin's roughly ten-minute blocks make timeout windows coarse: you cannot set a tight, precise deadline the way you can on a fast chain, and the cross-chain timeout coordination — the destination chain's deadline has to sit safely inside Bitcoin's — has to be conservative by construction. Collateral is locked and idle for the life of the position. And the model assumes the hash function holds. These are the costs of removing the custodian. We think they are worth paying for the class of positions a vault is meant for. They are still costs.

The question

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

So here is the question for anyone building agent-side collateral logic: when your agent posts Bitcoin as collateral, do you know exactly who can move those coins — and is the honest answer "only the agent, and only along paths the agent agreed to in advance"?

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

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

Everyone is building a "settlement layer." There are two of them.

Baris Sozen — Sun, 24 May 2026 06:13:32 +0000

This is the Sunday recap — a step back from the week in agent-economy infrastructure, and where our own week fit into it.

The headline event: an $8M pre-seed round, led by a well-known fund, for a company describing itself as "the settlement layer for the agentic economy." That is a lot of money and a lot of conviction pointed at a thesis we have been building on for months — agents will transact autonomously, and they need infrastructure to do it. When a serious fund writes that check, it is a useful signal: the market is real, and we are not the only ones who think so.

But "settlement layer" is doing a lot of work in that sentence, and it is worth slowing down on. Because there are two different layers that both get called "settlement," and conflating them makes the whole agent-economy stack harder to reason about than it needs to be.

Layer one: the payment rail

The first layer answers a concrete question: how does an agent pay for something?

An agent books a flight, subscribes to an API, tips another agent for a result. On one side is the agent's wallet; on the other is a merchant who wants to be paid in a form they can use. The job of a payment rail is to wire those two together — handle the request, move the value, confirm the merchant received it. The x402 pattern (a payment embedded directly in an HTTP 402 response) is the cleanest expression of this idea, and it is growing quickly: the protocol is now clearing on the order of 500,000 transactions a week.

This is real infrastructure with real traction. The round this week is, in large part, a bet on this layer — agent-to-merchant payments, plugged into existing commerce. It is the work of plugging an agent into the economy that already exists.

It is just not the layer we build.

Layer two: trustless settlement

The second layer answers a different question: how do two agents exchange value when neither one trusts the other — and neither trusts an intermediary?

This is not "agent pays merchant." It is "agent A holds ETH, agent B holds BTC, they have agreed a trade, and now both legs have to happen — or neither." There is no merchant relationship here, no repeat business to lean on, no reputation either side can hold hostage. There is just a trade between two strangers across two chains.

The naive answer is to route through a custodian or a bridge: someone holds both sides, performs the swap, hands the results back. That works, and it is convenient, but it reintroduces exactly the thing an agent has no good way to evaluate — a trusted third party. A custodian can freeze funds. A bridge's lock-and-mint contract is a standing honeypot; the value sits there, waiting.

The trustless answer is a hash-time-lock contract (HTLC). Agent A locks funds against the hash of a secret. Agent B locks the corresponding funds on the other chain against the same hash. When A reveals the secret to claim B's funds, the act of revealing it lets B claim A's funds. Either both legs settle, or — after a timeout — both refund. No custodian ever holds both sides. There is no intermediate state where value sits exposed.

That is the layer we build. It is a primitive, not a product feature: a way for any two parties to perform a conditional value exchange across any two chains without trusting an intermediary.

They are a stack, not rivals

Here is the part worth being precise about. The payment rail and the settlement layer are not competitors fighting over the same job. They sit at different heights in the same stack.

An agent can use an x402-style rail to pay a merchant for a service — that is the rail doing its job well. The same agent can use a hash-time-lock to settle a cross-chain trade with another agent — that is the settlement primitive doing a different job. One is "buy something from the existing economy." The other is "exchange value with a peer, trustlessly." A mature agent will do both, often inside the same workflow.

So when this week's round gets described as funding "the settlement layer for the agentic economy," the honest reading is: it funded a payment rail, and payment rails are valuable. The trustless cross-chain atomic settlement layer underneath — no custodian, no bridge — is a different layer, and it still needs building. That is the part we have spent the week on.

What our week looked like

Pull our own threads from the past seven days and every one of them turns out to be the same primitive seen from a different angle:

Forward-dated settlement. An HTLC timeout is usually treated as a safety valve. Used deliberately, it is a delivery window: set it to 24 hours and an atomic swap becomes a T+24h forward — a price locked today, delivery enforced on-chain tomorrow, with no clearinghouse holding the asset in the gap.
Sealed-bid quote requests. A quote request leaks direction, size and urgency the moment it is broadcast. A sealed-bid RFQ removes the pre-trade leak — makers bid blind — and atomic settlement removes the post-commit leak, because there is no gap between "agreed" and "settled" for a last look to live in.
Counterparty filtering. Trustless settlement removes the need to trust a counterparty's intent. Agents still benefit from filtering on a counterparty's history — on-chain data, not identity claims.

Three different-looking features. One hash-time-lock underneath all of them.

The usual honest caveat

Because we keep this straight: atomic settlement is live end-to-end on Ethereum mainnet today. The Sui contracts are deployed and CLI-tested, with gateway wiring still in progress. The Bitcoin P2WSH HTLC is validated on signet, with mainnet pending. When this recap says "live," it means Ethereum mainnet — the rest is honest roadmap.

And HTLCs are not free. They cost capital lockup for the duration of the timeout, they carry timeout-coordination risk across chains with different block times, and they assume the hash function holds. We think those are the right tradeoffs for trustless settlement. They are still tradeoffs, and we would rather say so than pretend otherwise.

The question for the week

So here is what we would leave you with. The agent economy clearly needs payment rails — the funding this week says so, and the transaction counts back it up. But it also needs a layer below the rails: a way for agents to settle with each other directly, with no one in the middle.

When you read "settlement layer for the agent economy," which layer do you actually picture — the rail that plugs an agent into merchants, or the primitive that lets two agents trade without trusting anyone?

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

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

If your trading agent asks for a price out loud, it has already paid for it

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

This is a short, practical one — a Saturday tip rather than a deep dive. But it's a mistake I keep seeing in agent trading code, and it's worth thirty seconds of your attention.

Here it is: the moment your agent asks for a price, it has already given something away.

The naive quote flow

Picture a trading agent that wants to sell 10 ETH for BTC. To find a price, the obvious move is to ask around. Broadcast the intent to an open order book, ping a list of market makers, drop it into a public mempool-adjacent venue. Collect the quotes that come back, pick the best one, trade.

That feels like comparison shopping. It is not. It is publishing.

A quote request is not a neutral question. It carries direction (you're a seller), size (10 ETH), and — by the fact that you're asking right now — urgency. Anyone who sees the request before you trade is reading your hand.

Three ways that leak costs you

Once your intent is visible, three things happen, and none of them are in your favour.

Front-running. A faster party sees "seller of 10 ETH incoming" and trades ahead of you, moving the price into the spot you were about to take. You arrive late at your own trade.

Quote shading. Market makers who can see that you're a committed seller — and can see what their competitors are showing — quietly widen their quotes. You're not getting their best price. You're getting the worst price they think you'll still accept.

Last look. This is the quiet one. A maker shows you an attractive quote, you commit to it, and then — in the moment between your commitment and settlement — the maker re-prices or simply declines. "Sorry, the market moved." The optionality was theirs the whole time. You carried the risk; they kept the exit.

Your agent thinks it ran a competitive auction. What it actually did was advertise its position and then hand counterparties a free option on it.

What a sealed-bid RFQ changes

A sealed-bid request-for-quote flips the information asymmetry back.

The agent posts an RFQ. Makers submit bids — but the bids are sealed: each maker prices the request without seeing the other makers' bids, and without seeing any reaction from the taker. There is no live book to shade against, no competitor's number to undercut by a hair, no read on how badly you want the fill.

When the bidding window closes, the taker sees the bids and picks the best one. Crucially, the maker who quoted has committed to that price. There is no "let me look again" — because the next thing that happens is settlement, not a renegotiation.

That's the pre-trade half. The post-commit half is where atomic settlement matters.

Sealed bid plus atomic settlement — why both

A sealed bid removes the pre-trade leak: nobody shades or front-runs a request they can't read.

Atomic settlement removes the post-commit leak: last look only exists because there's a gap between "agreed" and "settled" where one side still holds an option. Close that gap and the option disappears.

Hashlock fuses the two into one operation. The RFQ and the settlement are not separate steps a counterparty can wedge themselves between. The winning bid settles through a hashed-timelock contract (HTLC): either both legs of the swap complete, or both sides refund. There is no state in which the maker has re-priced, walked, or kept your asset. The deadline is enforced by the chain, not by anyone's good intentions.

For an agent, the whole thing is a few tool calls over MCP — the open protocol Anthropic introduced for connecting models to external systems. The MCP server exposes six tools; the RFQ path is create_rfq to post the request, list_open_rfqs to see what's live, respond_rfq for makers to submit a sealed bid, and the swap tools to settle the winner. Your agent doesn't manage timelocks or watch the chain — it calls a tool and gets an atomic outcome.

The honest limits

A sealed-bid RFQ is not an invisibility cloak. It protects the quote phase — the window where your intent would otherwise be readable and exploitable. Once a trade settles on-chain, the settlement transaction is public, like any other; sealed bidding doesn't and can't hide a completed trade. What it removes is the free option that counterparties get when they can see your hand before you've traded.

And the usual chain-status caveat, because we keep this honest: atomic settlement is live end-to-end on Ethereum mainnet today. Sui contracts are deployed and CLI-tested with gateway wiring in progress; the Bitcoin P2WSH HTLC is validated on signet with mainnet still pending. When this post says "live," it means Ethereum mainnet.

The takeaway

If you're building a trading agent, treat the quote request as part of the trade, not as a free lookup before it. The cheapest spread in the world doesn't help if getting to it leaked your position to everyone who could act on it.

So here's the question I'd genuinely like builders to sit with: if shopping for a price is itself a leak, how much of what we call "best execution" was ever really best — and how much was just the least-bad price we could get after tipping our hand?

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

Protocol: https://hashlock.markets?utm_source=devto&utm_medium=referral&utm_campaign=2026-05-23-sealed-bid-rfq
MCP server (source): https://github.com/Hashlock-Tech/hashlock-mcp
For the underlying mechanism design, there's a working paper on SSRN: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722

Forward Settlement: how a trading agent locks tomorrow's price without a clearinghouse

Baris Sozen — Fri, 22 May 2026 19:18:22 +0000

A trading agent agrees a price at 9am. Delivery is tomorrow. For the 24 hours in between, somebody is exposed: either the price moves and one side wants out, or one side simply doesn't show up to settle.

This is the oldest problem in market structure, and traditional finance solved it a long time ago — with a clearinghouse. A forward contract works because a central counterparty stands between the two parties, holds margin, and guarantees that the trade completes even if one side fails.

That solution doesn't transfer cleanly to autonomous agents. If you're building agents that trade — on top of an MCP server, inside a framework like LangChain or CrewAI, wherever — you eventually hit a case where the agent needs to commit to a trade now and settle it later. And the moment you reach for a forward, you've reintroduced exactly the trusted intermediary the rest of your stack was designed to avoid.

There's a way to get the forward without the clearinghouse. It's worth walking through, because it's a small idea with a large consequence.

What a forward actually needs

Strip a forward down to its mechanics and it asks for three things:

A price, fixed now. Both parties agree terms today.
A delivery window, in the future. Settlement happens at T+24h, T+48h, or whatever the two sides picked.
A guarantee that both legs complete — or neither does. If one side vanishes, the other must not be left holding a half-finished trade.

The clearinghouse exists almost entirely to provide #3. It is a very expensive, heavily regulated answer to one question: who makes the trade whole if a counterparty fails?

For two agents on two different chains with no shared venue, that question has no good custodial answer. A centralized desk means both agents now trust the desk — and the desk can freeze, fail, or front-run. A bridge means trusting an optimistic settlement model: most bridges assume the far side will be made whole and rely on challenge windows to catch it if not. "Probably settled by tomorrow" is not a forward.

Why the naive on-chain version fails

The first instinct on-chain is to write an escrow contract. Agent A deposits the asset, the contract holds it until the delivery time, then releases it to Agent B against payment.

Look closely at "the contract holds it." Who can upgrade that contract? Who holds the admin key? Who decides what happens if the delivery oracle disagrees with one party? Every one of those questions is a custodian wearing a smart-contract costume. You haven't removed the trusted party — you've renamed it.

The fix is not a better escrow contract. It's to remove the holding step entirely.

The HTLC as a forward

A hash time-locked contract (HTLC) binds both legs of a trade to the same cryptographic secret and a timelock. The standard description of an HTLC emphasizes the atomic property: either both sides settle against the secret, or both sides refund after the timeout. No party can take one leg without releasing the other.

The piece that turns an atomic swap into a forward is the timelock itself. The timelock is not just a safety hatch — it is a programmable delivery window. Set it to 24 hours and you have described a T+24h forward in one parameter. Both legs are funded now, at the agreed price. Settlement can occur any time inside the window. If the window closes with the trade incomplete, both sides independently refund. No counterparty can be left exposed, because no counterparty was ever holding the other's asset — the contract logic was.

That gives you all three things a forward needs:

Price fixed now — both legs are committed at agreed terms when the contract is created.
Future delivery window — the timelock is the window.
All-or-nothing guarantee — the atomic property, enforced by the chain, not by a clearinghouse.

The delivery deadline is the part worth dwelling on. In the clearinghouse model, the guarantee is institutional: you trust that the central counterparty has the capital and the legal standing to make you whole. In the HTLC model, the deadline is enforced by the base layer. On Ethereum mainnet, the timelock is just block timestamps and contract code. Nobody — including the protocol that wrote the contract — can extend it, skip it, or quietly settle around it.

Where this fits for agents

We call this Forward Settlement, and it's a direct extension of the primitive Hashlock Markets already runs in production: atomic settlement, live on Ethereum mainnet today. The base layer is a sealed-bid RFQ for price discovery fused with HTLC settlement, exposed to agents through a 6-tool MCP server. A forward is not a separate product bolted on — it's the same HTLC with the timelock used deliberately rather than defensively.

The reason this matters for the agent economy specifically: agents are good at committing to future actions and bad at trusting counterparties they can't inspect. A forward written as an HTLC plays to both. The agent commits today; the chain enforces the window; neither agent has to evaluate the other's solvency, because solvency was never load-bearing. The trade either completes atomically or unwinds atomically.

It also composes. Because each leg is independently refundable and bound to the same secret, a forward can be one leg of a multi-leg trade — sell BTC, buy ETH, buy SUI, all or nothing — without inheriting a clearinghouse for the whole bundle.

The honest limits

A few things this does not do, because overclaiming helps nobody:

It does not eliminate price risk. A forward fixes a price; if the market moves, one side is worse off. That's the trade, not a bug.
It does not give you margin or leverage. Both legs are fully funded up front. This is a delivery guarantee, not a credit facility.
Today the production settlement layer is Ethereum mainnet. Sui contracts are deployed and CLI-tested with gateway wiring in progress; the Bitcoin P2WSH HTLC is validated on signet with mainnet still pending. Forward-dated settlement is live where atomic settlement is live — which today means Ethereum.

The underlying argument is in our working paper on SSRN, for anyone who wants the formal version rather than the blog version.

If an agent can get a forward without a clearinghouse, it's worth asking how much else in market structure was only ever a workaround for missing settlement guarantees — and how much of that an atomic primitive quietly makes optional.

Protocol: https://hashlock.markets
MCP server (canonical): https://github.com/Hashlock-Tech/hashlock-mcp

A regulated exchange just gave AI agents trading access — through custody. The settlement layer underneath shouldn't need it.

Baris Sozen — Thu, 21 May 2026 19:13:22 +0000

This week a regulated US exchange connected AI agents to live trading. Gemini's Agentic Trading lets an MCP-compatible model — Claude, ChatGPT, whatever you're building on — place real orders on a regulated venue.

It's worth pausing on that. When a regulated exchange ships an MCP integration, "agents that trade" stops being a hackathon demo and becomes infrastructure other people build on. The agent economy isn't a forecast anymore; it's being plumbed in public.

So this post isn't a takedown. It's the opposite — it's a "yes, and." The exchange MCP solves a real problem. There's just a second problem sitting right next to it that a single-venue integration structurally can't solve, and if you're building trading agents it's the one that will bite you.

What the exchange MCP actually does

The shape of these integrations is consistent: your agent connects to one exchange, authenticates, and sends order instructions. The exchange executes and holds custody throughout.

Inside a single venue that's fine. The agent is, functionally, a very fast trader sending instructions to a custodian it has decided to trust. You've made the interface programmatic. You have not changed who holds the money.

The problem that starts one chain over

Now put two agents in the picture, on two different chains, with no shared custodian — and no desire to acquire one.

Agent A holds USDC on Ethereum. Agent B holds an asset somewhere else. They've agreed on a price. They want to swap. The question that has no good answer in the custodial model is simple: who do they both trust to hold the funds while the trade completes?

The usual answers are all somebody:

A centralized desk or exchange — now both agents trust that desk, and the desk can fail, freeze, or front-run.
A bridge — most bridges settle optimistically: they assume the other side will be made whole and rely on challenge windows and watchers to catch it if not. "Probably atomic" is not atomic.

For autonomous agents transacting at machine speed, "trust this intermediary" is not a footnote. It's the whole risk model.

Atomic settlement: the answer is nobody

The honest answer to "who holds the funds" is nobody — and that's a solved primitive, not a research problem.

A hash time-locked contract (HTLC) binds both legs of a trade to the same cryptographic secret and a timelock. Either both sides settle, or neither does, and any party can independently refund after the timeout. There's no custodian in the middle and no optimistic assumption to challenge. The trade is atomic in the literal sense: indivisible.

That's the layer Hashlock Markets builds — atomic settlement for agent-to-agent trades. Sealed-bid RFQ for price discovery, HTLC for settlement, the whole thing exposed to agents through a 6-tool MCP server. It's live on Ethereum mainnet today and multi-chain by design.

Front door vs. floor

A custodial exchange MCP and a trust-minimized settlement layer are not competitors. One is the front door — a regulated, familiar venue an agent can walk into. The other is the floor — the thing that has to hold when two agents who've never met, on chains that don't know about each other, need to exchange value without electing a trusted party.

If you're building agents that only ever trade inside one venue, the exchange MCP is genuinely most of what you need. If your agents trade across chains or with each other, the settlement primitive is the part that matters more than the exchange — and it's worth choosing one that's atomic rather than optimistic.

Docs and the MCP server: https://hashlock.markets/docs?utm_source=devto&utm_medium=referral&utm_campaign=2026-05-21-regulated-cex-mcp

I've Spent 30 Years Trying to Decode Markets. Here's What I Think Comes Next.

Baris Sozen — Thu, 21 May 2026 14:58:25 +0000

I've always been obsessed with financial markets. Not the money — the mechanism. The question that never let me go: how does price actually form?
Starting from zero
Charles Dow didn't have Bloomberg terminals. He had a pencil and a newspaper. He hand-tracked closing prices, computed averages by arithmetic, recorded OHLCV on ruled paper. From that discipline — just watching, recording, thinking — he built a theory that still underpins how we read markets 130 years later.
That story hooked me early. The idea that you could sit with raw data and see something other people couldn't.
I followed Richard Russell's Dow Theory Letters for years. Russell took Dow's framework and ran it through decades of real markets — bull, bear, crash, recovery. No fancy models, just persistent observation and honest reporting. I learned more about market psychology from those letters than from any textbook.
The indicator rabbit hole
Then came the quantitative explosion, and I went all the way down. Thousands of indicators. Hundreds of stop-loss variations. Elliott Wave, Bollinger Bands, Ichimoku, RSI divergences, volume profile, market delta — you name it, I built it, backtested it, watched it work for a while, then watched it stop working.
It took me an embarrassingly long time to understand why. I kept thinking I had the wrong indicator. I didn't. I had the wrong object. I was studying the output of the market — the price tape — and trying to reverse-engineer the thing that produced it. But the thing that produces price is people's intent, and the market never shows you that. It only shows you the residue.
The order is the problem
Here is the realization that reframed everything for me.
When you place a classic limit order, you compress everything you know and feel about a trade into two numbers: a price and a size. "Buy 1 BTC at $58,000." That is it. That is the entire bandwidth.
But that is not what you actually want. What you actually want is closer to: "I'd be happy buying around $58k, a little less happy at $59k, I'd take more size if it dips, and I don't want to touch it above $60k." That is a shape — a soft landscape of preference. The limit order throws all of that away and keeps one point.
And then it does something worse: it publishes that point. Your exact price, your exact size, sitting in a public order book. For a retail trader this is the quiet tax nobody explains to you — your stop-loss is a coordinate, and there are bots whose entire job is to walk price to that coordinate, trigger you, and hand the move back. You didn't get unlucky. You got read.
Thirty years of indicators, and the honest summary is this: I was trying to out-predict a game whose board was rigged at the level of the order type itself.
Orders vs. intent
So what is the alternative? Stop submitting a point. Submit the shape.
Instead of "buy 1 BTC at $58,000," you express your full intent: a surface over price and size that says how much you'd want to trade, where, and with how much tolerance. Call it an intent. It is signed, it is committed, and — this is the part that matters — it is not a public coordinate. There is no flat $58,000 line for anyone to hunt.
This changes what "matching" even means. A classic exchange crosses two orders when a buy price meets a sell price — a hard, discrete event on a public book. An intent-based market does something different. Two traders submit their intent surfaces, and a solver looks for where those two surfaces overlap most — the point where both sides are simultaneously most satisfied.
Here is the part I find genuinely beautiful. When you work out the math of "where do two preference surfaces peak together," you don't get some arbitrary venue rule. You get the Nash bargaining solution — the result John Nash proved in 1950 is the unique fair outcome under a handful of common-sense axioms. Nobody negotiates. Nobody quotes a spread. The solver answers one question — where is the product of the two intents highest — and that answer is the fair clearing price. Fairness is not bolted on. It falls out of the geometry.
Old market vs. new market, side by side
Let me put the two models next to each other, because the difference is the whole point.
In a classic orderbook market, you submit discrete orders. Your price and size are public. Priority is price-time — speed wins. Market makers sit in the middle and earn the spread for providing immediacy. Your stop is a visible target. The system rewards whoever is fastest and best-positioned to see everyone else's coordinates.
In an intent-based solver market, you submit a private, committed preference surface. There is no public point to hunt. There is no spread to pay, because there is no market maker standing in the middle — the solver computes the clearing directly from the two intents. Matching is not "who crossed first," it is "where are both sides most satisfied." And the more rigid you make your intent, the closer the clearing sits to your ideal — but the smaller your overlap, so the less likely you match. The flexibility-versus-fill trade-off is yours to set, explicitly, instead of being hidden inside an order type you never chose.
It is the difference between shouting a number into a room and handing someone a map of what you would actually accept.
Why this is happening now
This idea is not brand new — intent has been in the air in DeFi for a couple of years. What is new is who is trading.
A human clicking a limit order was always going to give the market a thin, one-point signal — clicking fifteen boxes to express a real preference surface is too much work. An AI agent has no such limit. An agent can carry a genuinely rich intent, update it as conditions change, and commit it cryptographically without getting bored. Intent is not a nicer UI for human traders; it is the native language for agents that trade. The order book was built for humans with a mouse. The intent surface is built for software with a goal.
And once you can see intent as a surface, you can finally see the market. Not a scrolling tape of trades — an actual landscape: where buying intent piles up, where selling intent thins out, where the two are about to overlap. I have been building 3D renderings of exactly this, because for the first time the picture in my head — the thing I was always trying to reverse-engineer from the price tape — is simply, directly drawable.
The last piece: settlement
There is one more thing that has to be true for this to work, and it is the thing my team has spent the most time on. If two agents discover a fair clearing across two different chains — BTC on one side, an L2 asset on the other — the trade still has to settle without a custodian holding both sides and without a bridge's fraud window. That is HTLC-based atomic settlement: both legs clear on one cryptographic secret, or both refund. It is the floor the whole thing stands on. Discovery and matching are interesting; settlement is what makes it real.
Where I think this goes
After thirty years I have stopped believing the edge is in a better indicator. The indicators describe the residue. The interesting move is upstream — change what a trader is allowed to express, and you change what the market is.
A market made of discrete public orders is a market that rewards speed and punishes anyone whose intent is visible. A market made of overlapping private intent rewards clarity about what you actually want. One is a wall of coordinates. The other is a field of preference, settling where it genuinely overlaps.
I do not think this is finished, and I will not pretend it is. Solver trust, liquidity bootstrapping, the privacy stack — all of it is still being worked out, honestly and in the open. But for the first time in thirty years, the thing I am looking at is not the residue of the market. It is the market itself.
That is what I think comes next.

I am building this at Hashlock — atomic, cross-chain settlement for the agent economy. The mechanism design behind intent-based markets is written up in our working paper on SSRN: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722. Protocol: https://hashlock.markets. Code: https://github.com/Hashlock-Tech/hashlock-mcp.
If you have traded long enough to carry your own stop-hunt scar tissue, I would genuinely like to hear how you think about this: does expressing intent as a surface instead of a point change the game — or just move it?

Counterparty data > counterparty identity: why an agent's KYC document is the wrong primitive

Baris Sozen — Tue, 19 May 2026 14:22:24 +0000

Yesterday I walked through the four filters Hashlock runs before an HTLC locks in: on-chain settlement history, sealed-bid RFQ commitment, tiered KYC attestation, and the HTLC timelock/hashlock itself (deep-dive here). The deep-dive was about the mechanism. This post is about the thesis.

The thesis is one sentence:

For an AI agent picking a counterparty in milliseconds, the most predictive thing isn't who the counterparty is. It's the last 200 swaps they settled.

That sounds like a small claim. It isn't. It's the difference between two different settlement stacks, and most of the agent-payment infrastructure being shipped right now is implicitly choosing the wrong one.

The two stacks

Stack A — identity-first. Every counterparty arrives with an attestation: KYC document, regulated venue membership, sanctions-screened wallet. The protocol checks the attestation, and if it passes, the trade is allowed. This is how the Fireblocks / Copper / Paxos generation of settlement networks works. It's also, broadly, how ERC-8183 is being framed: the escrow state machine assumes an evaluator that vouches for the leg.

The strength of Stack A is institutional defensibility: "we only trade with verified entities." The weakness, for agents, is that the verification signal is upstream of the actual trade. An agent in milliseconds can't re-verify; it accepts what the attestation says.

Stack B — behavior-first. Every counterparty has a settlement history visible on-chain. The protocol scores them on how many swaps they've completed, how recently, at what size, against how many distinct takers. If the score passes, the trade is allowed. Identity attestations are an overlay — opt-in, layered, mandatory only where policy demands it.

The weakness of Stack B is that new addresses have no history. The strength is that the verification signal is the same primitive that the trade itself uses (the settlement record). An agent can re-verify in the same tool call that submits the bid.

Why behavior survives at agent latency

Three reasons, in cost order:

1. Behavior data is already on-chain. An agent fetching a counterparty's last 200 settlements is a single RPC call (an event log query against the HTLC contract). An agent fetching a counterparty's KYC attestation requires (a) the attesting party to be online, (b) a trust chain to the attestation issuer, (c) some kind of off-chain index. Latency budget: ~50ms vs ~500ms-2s.

2. Behavior data is harder to fake. Spinning up a fresh address with a fresh KYC attestation is cheap (sign-up, KYC pass, attestation issued). Spinning up a fresh address with 200 on-time settlements against unrelated takers, weighted by notional, is expensive — by construction, the address has to actually do the trades. Sybil resistance is built into the primitive, not bolted on by the attestor.

3. Behavior data is non-discretionary. A KYC issuer makes a discretionary call. A settlement record is an objective ledger entry. For an agent that has to defend its routing logic to its owner ("why did you trade with this address?"), "200 on-time settlements at notional X" is a stronger answer than "the attestor said yes."

What the directory actually looks like

In Hashlock terms, the Verified Counterparty Directory is filter 1 of the four-filter stack. It exposes (at the protocol level, not the wallet level):

settlements_completed_total — count of HTLCs this address has redeemed inside its timelock
settlements_refunded_total — count of HTLCs this address has let expire (a soft signal of mismatched price/size)
settlement_notional_weighted — sum of notional × age decay
distinct_counterparties_30d — count of distinct counterparties in the last 30 days (Sybil-resistance)
median_response_ms — RFQ response latency (a liveness signal)

An agent's quote tool, before locking, can run a one-line check: "give me the top-5 makers for ETH→BTC notional 0.5 BTC who scored above threshold X on the first three metrics in the last 30 days." That's behavior-first selection. There is no document to read. There is no attestor to call. There is no warm intro.

If the bid arrives from an address with no history (notional > threshold, score below threshold), the agent can either refuse the bid or escalate to filter 3 (tiered KYC attestation). That's where identity-first overlays earn their keep — they cover the cold-start case, but they don't replace the behavioral baseline.

Where this sits in the agent-economy stack

There are roughly four layers in the agent-trading stack as it's being built today:

How an agent pays — x402 (Coinbase), OKX APP, Stripe x402 multi-chain. Standardises the payment rail.
What state machine holds the escrow — ERC-8183 (Ethereum Foundation + Virtuals Protocol), ERC-7683 (cross-chain intents). Standardises the escrow lifecycle.
Whether the trade matches the agent's intent — Nava-style verification layers. Catches "the agent wanted X but the protocol routed Y."
Whether this counterparty should be allowed to be in the trade at all — the counterparty directory. This is the filter underneath the rest.

Most agent infrastructure being shipped right now is layer 1 or layer 2. Layer 4 — the should-this-leg-exist-at-all layer — is the one that's barely being framed as a category. It's also the one that determines whether the rest of the stack is operating on signal or noise.

Honest limitations

The directory works at scale. With <100 settlements per address it's weak. The protocol cold-start is the same cold-start every reputation system has: you bootstrap with attestations, then transition to behavior as the history accrues.
Notional weighting is sensitive to manipulation if attackers can run wash trades cheaply. The current weighting decays old settlements and discounts repeated trades against the same counterparty, but this is an open design choice.
"Last 200" is not magic. It's a reasonable window for the current settlement volume on the protocol; as throughput grows, the window may shift to a time-decay function (e.g. 30-day rolling notional-weighted score).
For institutional traders subject to regulatory KYC, filter 3 (tiered attestation) is not optional. The directory is the baseline, not the only layer.

Build status (as of 19 May 2026)

ETH mainnet: HTLC live end-to-end; directory metrics queryable via event logs.
SUI mainnet: contracts deployed, CLI-tested; full directory queryable but volume still low.
BTC: signet-validated; mainnet gated on audit firm sign-off.
Roadmap: Base, Arbitrum, Solana, TON.

The protocol is open source. The MCP server (hashlock-tech/mcp on npm — scoped) exposes six tools an agent can call directly. The deep-dive on the four filters and code samples is at the URL below.

The question I want builders to answer

In your agent stack — whatever it's settling, whatever chain — what data would your agent need to see before it trusted a counterparty it had never met? If the answer is "an attestation from a trusted issuer," I'd argue you're outsourcing the decision in a way an agent can't verify. If the answer is "evidence in the trade primitive itself," you've described the directory.

I'd genuinely like to hear what your stack does.

Code, deep-dive, and the four filters in order: hashlock.markets

Source: Hashlock-Tech/hashlock-mcp on GitHub

Academic foundation: SSRN whitepaper — the formal model of sealed-bid RFQ + HTLC atomic settlement that this primitive is built on.

Disambiguation: this is Hashlock Markets (hashlock.markets), the atomic settlement primitive for AI agents. Not affiliated with Hashlock Pty Ltd, the Australian smart-contract auditing firm.

Counterparty validation for AI agents: the 4 filters before an HTLC locks in

Baris Sozen — Mon, 18 May 2026 15:11:35 +0000

When a human walks into an OTC desk, counterparty validation is a meeting. There is a know-your-customer file somewhere, a credit committee that meets quarterly, and a relationship manager who can pull a phone if a leg looks wrong. The check is mostly human, mostly slow, and almost entirely off-chain.

When an autonomous agent picks a trade counterparty, none of those instruments exist. The agent cannot phone a desk. It cannot read a credit memo. It cannot sit on a board call where someone explains why the maker is good for it this quarter. The decision happens in milliseconds, on chain, against a counterparty the agent has never seen and may never see again — and it has to be wrong less often than the agent's owner can tolerate.

Counterparty validation for agents is not KYC. It is a different problem in a different shape, and it needs a different primitive.

Hashlock's third invented primitive is a Verified Counterparty Directory: an on-chain, agent-readable layer that screens a bid through four filters before any HTLC ever locks. The filters run in order, because each one is cheaper than the next and the cheap ones screen out the most takers. The deepest filter — the HTLC itself — only matters if the first three pass.

This post walks through the four filters, the order, the code an agent uses to query each one, and where this layer sits relative to ERC-8183, x402, and the verification-layer projects that have started to ship around it.

The four filters, in order

The filter ordering matters as much as the filters themselves. A naive design checks the most expensive condition first and inverts the cost curve. The directory pushes the cheapest, highest-signal check to the front and only descends into cryptography after policy is already satisfied.

Filter 1 — On-chain settlement history

The cheapest filter is also the highest-signal one for repeated counterparties. Every Hashlock atomic swap emits a settlement event with (maker_address, swap_id, committed_deadline, actual_settlement_time, notional). After a few weeks an address has produced a settlement track record that is more predictive of the next trade than any single identity claim about who is behind it.

The directory computes per-address statistics over a rolling 30-day window:

swaps_completed
on_time_rate (settled before committed deadline, weighted by notional)
timeout_rate (HTLC refunded because the counterparty did not deliver in time)
dispute_rate (legs that went to refund because of a parameter mismatch)

The check is a single read against an indexer or a directory contract; the math is a pure function over public events; the agent gets a pass / inspect / fail flag in one round trip.

// Pseudocode — agent-side query against the directory
const stats = await directory.getCounterpartyStats(makerAddress, {
  windowDays: 30,
  notionalWeighted: true,
});

if (stats.swapsCompleted >= 50 && stats.onTimeRate >= 0.97) {
  // pass — proceed to filter 2
} else if (stats.swapsCompleted < 10) {
  // unknown counterparty — escalate to filter 3 (attestation) before continuing
} else {
  // fail — the address has a track record and it is bad
  return REJECT;
}

The reason this is filter 1 and not filter 4: an address with 200 clean swaps does not need cryptography to be a known quantity. The directory has already done the work. Cheap to query, expensive to fake, predictive enough that most bids resolve here.

Filter 2 — Sealed-bid RFQ commitment

The second filter is structural rather than computational. Hashlock uses a sealed-bid RFQ for the bid phase: a maker submits a bid that is binding once accepted, with a commit-reveal step that prevents the maker from seeing other bids before they commit theirs. Once the taker accepts, withdrawal is not a free option — the maker either delivers or loses their bond.

This filter prevents a specific class of griefing that custodial OTC desks can absorb but agent commerce cannot: the maker who bids aggressively, watches the order book, then withdraws when the market moves against them. In a human OTC desk, the relationship manager fixes this with a phone call. In agent commerce, there is no phone. The primitive has to make the griefing strategy uneconomic.

The agent does not have to evaluate this filter — it is enforced by the protocol. But the agent's strategy can take it as a given: if a bid was accepted by Hashlock's RFQ contract, the maker has already committed.

Filter 3 — Tiered KYC attestation

The third filter is where identity comes back in, but in a layered form. Most agent trades will never need this filter; it exists for the trades that do.

The directory supports three attestation tiers:

Tier 0 — anonymous. No identity claim. Settlement history is the only signal. Agents trading their own balance against retail liquidity sit here.
Tier 1 — attested. A third-party attestation has been issued against the address. This is a single on-chain reference to an off-chain attestation, not the attestation itself. Useful for "this address is associated with an institution" claims.
Tier 2 — verified. A full off-chain identity check has been completed by a regulated attester, and a hashed reference is on chain. Required for sizes or counterparties that policy says are gated.

The attestation tier is policy-readable: an agent operating under a treasurer's policy can require Tier 1 above a threshold size, or Tier 2 for certain instrument classes, without the protocol having any opinion about who can trade. The directory is permissionless at Tier 0; tiering is opt-in.

const tier = await directory.getAttestationTier(makerAddress);
if (policy.requireTier(notional) > tier) {
  return REJECT; // not because the address is bad, but because policy says so
}

This is where the protocol stops being a single-tier system and starts being a stack: institutional flow can require attestation, retail-agent flow does not have to.

Filter 4 — HTLC timelock + hashlock

The fourth filter is the cryptographic floor. Once a bid has passed filters 1–3, the actual settlement uses an HTLC: a hash-time-locked contract where both legs are conditioned on the same preimage and the same timelock. Either both legs settle or both refund. There is no window where one party has delivered and the other has not.

This is the filter people usually argue about. It is also the filter that matters least if the first three pass — because if the maker has 200 clean swaps, is bid-bound by the RFQ, and meets the attestation tier the taker requires, the HTLC is a safety net under a counterparty that is unlikely to need it. The cryptography earns its keep when filter 1 returns "unknown counterparty" — for a brand-new address with no track record, the HTLC is the entire trust assumption, and it is enough.

The point of having the HTLC underneath everything is not that it is the strongest filter. It is that it is the floor: even if filters 1, 2, and 3 are misconfigured or compromised, the worst case is a timed refund, not a stolen leg.

Where this sits relative to ERC-8183, x402, and verification layers

The agent-commerce stack has gotten more crowded in the last two months. It helps to be explicit about which layer the directory is, because the projects in this category are mostly complementary rather than competing.

x402 (Coinbase) and APP (OKX) answer how does an agent pay. They are payment-rail protocols — message formats, settlement triggers, batching. They sit above the settlement primitive. An agent using x402 to authorize a payment still needs something to atomically settle the underlying value if it crosses chains.
ERC-8183 is a state machine for escrowed task-based payments — a standardized way for an escrow contract to hold value while a task is in progress and release it on completion. It answers what state machine holds the escrow. It does not answer who the counterparty should be in the first place.
Nava is a verification layer — does this transaction match what the user actually meant. Pre-trade semantic check. Complementary to a directory that checks the counterparty.
The Verified Counterparty Directory answers should this leg exist at all. It runs before the escrow opens, before the payment rail authorizes, before the state machine starts.

Stacked, the four answer different questions, and an agent in production will hit all of them in the same trade. That is the point: an agent stack is layered, and the directory is the layer that decides whether the rest of the layers ever run.

What the agent actually sees

From the agent's side, the four filters are surfaced as one tool call. The Hashlock MCP server exposes counterparty data through the quote tool, which returns the directory state for the maker on the other side of the bid before the agent commits:

const quote = await mcp.callTool("quote", {
  baseAsset: "ETH",
  quoteAsset: "USDC",
  side: "buy",
  amount: "10.0",
});

// quote.maker.directory:
// {
//   swapsCompleted30d: 187,
//   onTimeRate: 0.994,
//   timeoutRate: 0.0,
//   attestationTier: 1,
//   rfqBindingAfterAccept: true,
//   htlcParams: { timelockSec: 7200, hashlockAlgo: "sha256" }
// }

The agent can apply its policy against that object in a few lines. The four filters become a single pre-trade evaluation, not a multi-step workflow.

Where we are in the build

The directory is live on Ethereum mainnet (settlement-history component reading from the V1 HTLC events). SUI has the contracts deployed and CLI-tested; the directory read path is being wired to the SUI mainnet gateway. BTC is signet-validated with mainnet wiring pending. Attestation tiering is on Ethereum first; the SUI and BTC tier reads will follow once the mainnet gateway audits clear.

Chain registry as of this writing: live on ETH, BTC, SUI; roadmap Base, Arbitrum, Solana, TON. Current published version of the MCP server is hashlock-tech/mcp (scoped npm package) at 0.2.0, with the directory query path included in the quote tool response.

Open question

The honest one: what should the directory do with the median counterparty — the address with, say, 30 swaps, 92% on-time, no attestation? Filter 1 says "inspect" rather than pass or fail. The current policy is to escalate to the agent's own decision (return the stats, let the agent decide), but the wider question is whether the protocol should publish a recommended threshold curve, or stay agnostic and let every operator pick. We are reading the responses on this one — if you have an opinion, the post on hashlock.markets has the canonical version of the question and a place to drop a number.

Hashlock Markets — atomic settlement for the agent economy. Protocol page: hashlock.markets. MCP server source: github.com/Hashlock-Tech/hashlock-mcp. The academic version of the primitive (sealed-bid RFQ + HTLC settlement, written up as a working paper) is at SSRN abstract 6712722.