DEV Community: Baris Sozen

Forward OTC settlement for agent treasuries: T+24h trades that don't depend on trust

Baris Sozen — Fri, 08 May 2026 14:18:11 +0000

In the last three weeks the agent-payments stack added a fifth shipped standard. Pay.sh launched on Solana with Google Cloud. Coinbase's x402 crossed 167M cumulative transactions. OKX Agent Payments Protocol added wallet+SDK+broker. ERC-8183 graduated to BNB Chain mainnet. Coinbase's Agent.market opened a seven-category app store.

All five share one property: they settle at T+0.

That's exactly what they should do. If your agent is calling Vertex AI or paying for a Perplexity query, you want sub-second finality. Pay.sh, x402, and OKX APP are very good at being a payments rail. You shouldn't ask a payments rail to do anything else.

But agent treasuries don't only pay for tools. Increasingly, they trade. And trades are not payments.

The dimension agent payment rails skip

A trade has at least two sides, often more than two assets, and almost always a settlement window that isn't zero.

Consider three real workflows that already exist in production today, run by humans, and that an autonomous agent will be asked to run tomorrow:

Treasury rebalancing. A DAO holds 60% ETH, 30% BTC, 10% SUI and the policy says rebalance weekly. The agent doesn't want to slam every leg through a pool at the same instant — that's a slippage tax. It wants to RFQ each leg, lock prices at the same time, and clear them as a group. Some legs naturally take longer than others.
Scheduled buybacks. A protocol commits to buy back its token every Friday at noon UTC against revenue collected the prior week. The buy and the sell should be linked, not sequential. The agent has to commit on Wednesday but deliver on Friday.
Cross-asset hedge unwinds. An agent shorts a pair via a perp on one venue and offsets in spot on another. The unwind needs to be atomic across venues. Forward windows, sometimes 24 hours, sometimes 48, are how human desks already do this.

None of these are payment-rail problems. All three are settlement problems.

How OTC desks do it today, and what's missing

If you call a crypto OTC desk and ask for a forward, here's what happens. They quote you. You agree on a price. You agree on a delivery window — T+24h, T+48h, sometimes T+5. You sign a confirmation by email. Twenty-four hours later, both sides wire.

Two assumptions are loaded in there. The first is that the desk honors the forward at the agreed price even if the market moves five percent against them. The second is that you honor it back. The history of OTC is full of cases where the second assumption broke and the desk ate the loss, and a smaller history of cases where the first one broke and the customer did.

This is counterparty risk in its purest form. It's the reason 1-in-10 OTC trades reportedly fail at the human desk level, and the reason every autonomous-economy paper this year has flagged "trust between agents" as the unsolved layer.

You can solve trust between agents with reputation. ERC-8004 is a clean attempt at that. You can also solve it with collateral. Hashlock takes the collateral path because reputation has a bootstrapping problem and collateral does not.

Forward OTC, mechanically

A Forward OTC trade on Hashlock Markets is a sealed-bid RFQ followed by a hashed-timelock contract on each leg, with a delivery window measured in real chain time.

The flow looks like this:

RFQ. The taker (agent or human) creates an RFQ specifying the pair, the size, and a delivery window — say, "I'll deliver 1 BTC against 21.5 ETH, settlement window T+24h." Multiple makers respond with sealed bids. The taker picks one.
Lock. Both parties post HTLC bonds on their respective chains. The maker locks 21.5 ETH on Ethereum, hashed to a preimage held by the taker. The taker locks 1 BTC on Bitcoin, hashed to the same preimage. Each lock has a timelock equal to the delivery window plus a small grace period.
Reveal. Inside the window, the taker reveals the preimage to claim the maker's ETH. The act of claiming on Ethereum publishes the preimage on-chain, which the maker's relayer picks up and uses to claim the BTC on Bitcoin. Two reveals, one preimage, atomic across two chains.
Refund. If either side fails to act before the timelock expires, the locks unwind. Both bonds return to their original owners. No partial settlement is possible.

The clock is the smart contract. There is no broker holding both sides of the trade. There is no escrow custodian who could be subpoenaed, hacked, or rugged. The only thing each party trusts is that math holds, that the chain finalizes, and that the timer counts down.

Why Sui makes this primitive cleaner

Hashlock Markets runs on three chains as of this week: Ethereum, Bitcoin, and Sui. Sui mainnet support went live on May 1 and that matters more than it sounds.

Bitcoin doesn't speak smart contracts in the EVM sense. To use BTC as collateral on a Sui-native trade, you need a way to hold it that isn't "wrap it into a custodial token and pray." We use Hashi for this — a Sui-native bridging primitive that holds BTC against a verifiable proof without minting a wrapped token, and that emits an object on Sui you can lock into an HTLC.

Sui's object model is the reason this works. Instead of hashlock state being a balance entry inside a giant shared mapping (the Ethereum approach, which forces every claim/refund to contend with every other claim/refund), each Forward OTC bond is its own object with its own owner and its own lifecycle. Claims on different trades don't queue behind each other. The bonds compose with other Sui primitives (sponsored transactions, programmable transaction blocks, gas pools) the same way any other object does.

This is the part of the stack that wasn't possible six months ago. It is now.

The 7 bps detail

Hashlock charges 7 basis points on settled volume in current reference deployments, with up to a 50% rebate via Execution Rewards for makers who settle inside their committed window. Effective fee for a reliable maker: 3.5 bps. Effective fee for a maker who refunds: 7 bps. Compare to typical CEX OTC desks at 8–10 bps and ask what the desk is actually doing for the spread.

We are deliberately calling these "reference deployments" rather than "production" — we are still pre-audit, contracts are immutable on V1, and the volume floor is small. The fee schedule is not an aspirational marketing number, it is what the contract takes.

Try it

Today, if you point Claude Desktop at the hashlock-tech/mcp package (scoped) and call create_rfq with settlement_window=86400 (24 hours, in seconds), you can submit a real Forward OTC RFQ on testnet against ETH, BTC, or SUI. The MCP exposes six tools: create_rfq, respond_rfq, create_htlc, withdraw_htlc, refund_htlc, get_htlc. Forward windows are a parameter on the first call.

We're publishing the full Forward OTC mechanics walkthrough at https://hashlock.markets/docs. The protocol spec, including the timelock derivation and the cross-chain claim graph, is in the SSRN paper: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722.

Hashlock Markets, public canonical: https://hashlock.markets. GitHub: https://github.com/Hashlock-Tech/hashlock-mcp.

What forward-settlement window does your agent treasury actually need — T+0, T+24h, or T+48h? And which workflow first forced you to think about it?

Pay.sh pays for an API call. Hashlock settles a trade. Know the difference.

Baris Sozen — Thu, 07 May 2026 14:18:49 +0000

Pay.sh pays for an API call. Hashlock settles a trade. Know the difference.

Yesterday Sola Labs, the Solana Foundation, and Google Cloud announced Pay.sh: an x402-based payment standard that lets AI agents pay for API calls on Solana, with Gemini and Vertex AI as the showcase consumers. It's a clean piece of infrastructure. The launch is real progress for the autonomous economy.

It is also not a settlement layer. And the difference matters more than the marketing makes it look.

The week in payment standards

Six months ago, "AI agents need a way to pay" was an academic problem. This week it has at least five shipped answers:

Coinbase x402 — HTTP 402 status code revived as a payments protocol. 69K agents, $50M in cumulative volume, x402 Foundation now under the Linux Foundation.
ERC-8004 — agent identity on Ethereum mainnet (January). The "who is this agent" prerequisite for everything else.
ERC-8183 — Ethereum Foundation + Virtuals Protocol agent commerce standard (March). Job-lifecycle: hire, deliver, pay.
OKX Agent Payments Protocol (APP) — late-April launch. TEE wallets, X Layer L2 rails. Their whitepaper says "escrow coming soon."
Pay.sh (May 6) — Solana + Google Cloud, x402-compatible, deep integration with Gemini, BigQuery, and Vertex AI. Sola Labs is the builder.

That is roughly $1.033B of fresh capital backing the category in the last three weeks alone — Haun Ventures' new $1B fund, Portal to Bitcoin's $25M, Nava's $8.3M seed.

Five standards. None of them settle a trade.

What "payment" means in this stack

Strip the word "payment" down. What every one of these standards does, in one shape or another, is:

An agent calls a service. The service charges. The agent pays. One direction. One asset. One leg.

Pay.sh is the cleanest expression of it. An agent on Solana wants to query Vertex AI. Pay.sh signs the bill, debits the agent wallet, settles in a sub-second on Solana. That's it. That's the whole transaction. Beautiful, narrow, fast.

x402 does the same thing over HTTP. OKX APP does it with TEE-protected wallets. ERC-8183 does it as part of a job lifecycle. Different chains, different cryptography, same shape: agent → provider, one-way, one asset.

This is the easy half of the autonomous economy. It's also the half that scales first, because it's a bilateral relationship with a clear winner (the provider) and a clear loser (the agent's balance).

What "settlement" means

A trade is structurally different. A trade has two sides, and increasingly more than two legs:

"Sell my BTC on Bitcoin. Buy ETH on Ethereum. Buy SUI on Sui. Atomic. All or nothing. No custodian, no wrapped tokens, no bridge."

That single intent is three chains, three legs, two counterparties, and one outcome. Either everything clears or nothing does. There is no "the provider wins." There are two parties trying to satisfy each other simultaneously.

Settlement is the part where two strangers — or, increasingly, two AI agents — exchange value across chains without a third party holding the float. It is a different category of problem. The math is different. The trust model is different. The failure modes are different.

You cannot build trustless trade settlement with a payment primitive any more than you can build SWIFT with Venmo. Same units, different problem.

What Hashlock Markets actually does

We are the layer the five payment standards assume exists.

The primitive is sealed-bid RFQ + Hash Time-Locked Contract atomic settlement, exposed as six MCP tools that any agent runtime can call:

create_rfq — taker posts an intent ("sell 0.5 BTC for ETH, 30 min validity"). Sealed; no public order book to front-run.
respond_rfq — makers quote privately. Best bid wins.
create_htlc — winning maker posts the hash-locked contract on the destination chain.
withdraw_htlc — taker reveals the preimage on the source chain, claiming maker's funds. Maker uses the same preimage to claim taker's funds on destination.
refund_htlc — if either party fails to act, both sides refund after timeout.
get_htlc — read state for monitoring.

Two AI agents can clear a cross-chain swap with each other directly. An AI agent and a human can clear a trade with each other. Two humans — same path. Live on ETH, BTC, and SUI as of April 9, 2026, with reference deployments on mainnet. Base, Arbitrum, Solana, and TON on the roadmap.

The fee is 7 basis points deployed. Tiered execution rewards rebate up to 50% of that for timely settlement, taking the effective floor toward 3.5 bps — versus 8–10 bps for typical exchange OTC desks.

The honest comparison

	Pay.sh, x402, OKX APP	Hashlock Markets
Direction	One-way (agent → provider)	Two-way (agent ↔ agent)
Legs	Single asset, single chain	Multi-leg, multi-chain atomic
Trust model	Trust the provider	Trust no one — HTLC enforces
Latency target	Sub-second	Block time per chain (HTLC)
Best use case	Pay for a tool call	Settle a trade
Custody	Provider takes payment	Neither side custodies

These are not competitive products. They are complementary products that solve adjacent problems. An autonomous agent stack that's serious about real economic activity needs both.

Where this goes

Pay.sh's launch is helpful for us. Every payment standard that ships makes the missing settlement layer more visible. When 69K agents on x402 want to do something more interesting than pay Cloudflare for an API call — when one of them wants to swap its USDC for someone else's SOL atomically — there is no payment standard in this list that can do it.

Five standards. Still no settlement layer. We are filling exactly that one slot.

Live: ETH, BTC, SUI. Roadmap: Base, Arbitrum, Solana, TON.

If your agent needs to pay for a tool, use Pay.sh, x402, or OKX APP — they're built for it. If it needs to swap assets with another party, that's our half.

Does your agent need to pay for a tool, or settle a trade with another agent?

Live endpoint: https://hashlock.markets
MCP server: https://github.com/Hashlock-Tech/hashlock-mcp
npm: hashlock-tech/mcp (scoped)
Full protocol spec: papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722

The autonomous economy has four standards — and a missing layer

Baris Sozen — Wed, 06 May 2026 14:10:28 +0000

In the first five months of 2026, the autonomous economy went from "interesting idea" to "four competing infrastructure standards." Let's map them and find the gap.

A funding week, by the numbers

Three announcements within the last few weeks tell you where the capital is pointing:

Haun Ventures closed a $1B fund (May 4) explicitly targeting the crypto + AI agent intersection.
Portal to Bitcoin raised $25M to ship a trustless cross-chain BTC OTC desk.
Nava raised $8.3M (April 14, Fortune) to build an AI-agent escrow service.

That is roughly $1.033B of fresh capital, in three weeks, betting that autonomous agents will need a different settlement stack than the one humans have been using. Now let's map what already exists, and what is still missing.

The four standards

ERC-8004 — Agent Identity (Ethereum mainnet, January 29 2026)

An Ethereum Improvement Proposal that gives an autonomous agent a verifiable on-chain identity. Think of it as a DID for wallet-bearing software: the agent can prove it is who it claims to be, across chains, without a custodian vouching. ERC-8004 answers the question "who is this agent?"

ERC-8183 — Agent Commerce (Ethereum Foundation + Virtuals Protocol, March 10 2026)

A job-lifecycle standard: Client posts a task, Provider accepts and delivers, Evaluator confirms quality, payment releases. BNB Chain shipped the first live SDK. ERC-8183 answers the question "how do agents hire each other?"

OKX Agent Payments Protocol (APP) — Agent Payments (late April 2026)

OKX's agent payment rail: TEE-secured wallets on X Layer, 20+ chain interop, AWS and Alibaba Cloud as infrastructure partners. APP answers the question "how does an agent pay for something?"

Coinbase x402 — HTTP Payments (dominant, 69K agents, $50M volume)

HTTP 402-based micropayment standard. A server returns a 402 status code, the agent pays, the content unlocks. Backed by Cloudflare, Stripe, AWS, Google, Visa, Circle, Solana Foundation — 20+ institutional backers. The x402 Foundation lives under the Linux Foundation. x402 answers the question "how does an agent pay for an API call?"

What all four assume — and none of them build

Read the specs carefully. Each standard assumes that when two agents want to trade — not pay, not hire, not identify, but swap one asset for another across chains — there is a settlement layer underneath that handles the atomic exchange.

x402 pays for an API call. It does not atomically swap USDC on Ethereum for BTC on Bitcoin.

ERC-8183 hires an agent to do a job and evaluates the output. It does not settle a two-sided asset exchange where both legs clear or neither does.

OKX APP sends a payment from a TEE wallet. It does not run a sealed-bid auction to discover the best price among competing market makers before settlement.

ERC-8004 gives an agent a verifiable identity. Identity is a prerequisite for trade, but identity is not settlement.

The gap: trustless OTC settlement with price discovery. Two sides, multiple chains, no custodian, no escrow service, no exchange account. The trade settles atomically or it does not settle at all.

The missing layer

Hashlock Markets fills this gap. The protocol has two phases:

Sealed-bid RFQ for price discovery. A trader (human or agent) broadcasts an intent. Market makers submit sealed quotes — each maker's price is private from the other makers. The trader picks the best quote. No order book. No information leakage. No front-running.
HTLC atomic settlement across chains. Once the trader picks a quote, a pair of Hash Time-Locked Contracts arms on the two chains. The hashlock ensures atomicity: both sides reveal the same preimage to claim funds, or both sides expire and funds return. No custodian holds the float at any point.

The same protocol works for AI↔AI, AI↔Human, and Human↔Human trades. The MCP server exposes six tools — create_rfq, respond_rfq, create_htlc, withdraw_htlc, refund_htlc, get_htlc — over the same interface that ships in Claude Desktop, Cursor, and any MCP-compatible runtime.

How this fits the stack

Think of the autonomous economy as a four-layer stack:

Identity: ERC-8004 — "who is this agent?"
Commerce: ERC-8183 — "how do agents hire each other?"
Payments: x402, OKX APP — "how does an agent pay?"
Settlement: Hashlock Markets — "how do agents trade assets across chains, trustlessly?"

Each layer needs the others. An agent that can identify itself (ERC-8004), accept a job (ERC-8183), and pay for services (x402) still cannot swap 250K USDC for BTC without a custodial exchange — unless there is a trustless settlement layer underneath.

That is what Hashlock Markets builds. Not a competitor to x402. Not a competitor to ERC-8183. The trade-and-settle rail the other standards assume exists.

Where we are vs where the standards are

Live on Ethereum mainnet (since April 9), Sui mainnet (since May 1), and Bitcoin signet. Expanding to Base, Arbitrum, Solana, and TON. Fee floor at 7 bps deployed — roughly half what a centralized exchange charges.

Read the OKX APP whitepaper carefully: it ships TEE-secured wallets and a payment rail today, and the section on settlement says "escrow coming soon." That is honest disclosure, but it is also a gap. Hashlock Markets has been settling trustless cross-chain trades through HTLC primitives since the Ethereum mainnet bring-up on April 9. The standards are still drafting the layer we are already running.

Full protocol specification: SSRN Abstract 6712722

Which layer is still missing from your agent stack?

Hashlock Markets — trustless settlement for the autonomous economy.
Site: https://hashlock.markets
Hosted MCP: https://hashlock.markets/mcp
GitHub (canonical): https://github.com/Hashlock-Tech/hashlock-mcp

Six tools for an agent, six hundred methods for a human: why agent-shaped APIs beat SDK-shaped APIs for trading

Baris Sozen — Tue, 05 May 2026 07:10:33 +0000

The most common pushback we hear about Hashlock Markets is one sentence long.

"Six MCP tools? That feels thin."

It's a fair instinct if your reference frame is the SDK era. A serious trading SDK is a thousand-method surface. CCXT alone wraps a hundred-plus exchanges and exposes a unified interface that has been growing for years. The Bybit Python SDK has ninety-something endpoints. A modern broker SDK reads more like a textbook than a library.

When you put that mental model next to a six-tool MCP server, it feels under-engineered. The instinct is correct under one assumption — that a human developer will write the integration code. Under that assumption, more methods means fewer custom helpers, less work, more flexibility.

Here's the thing. Most of the trades inside an AI agent aren't being designed by a human developer. They're being described in natural language by a user, parsed by the model, and called by a planner that has to keep every method's behavior in its head as part of the prompt context. The SDK-era assumption doesn't hold any more.

Once that assumption breaks, six tools stops looking thin. It starts looking like the right number.

This post lays out the argument. It's a top-of-funnel piece — no jargon-heavy walkthrough, no schema dumps. Just the case for why the trading surface an agent actually calls should be deliberately small, and why we built ours that way.

The SDK-shaped API is a human convenience

An SDK is a productivity tool for a developer who is going to write a non-trivial amount of code on top of it. It is deliberately granular — fifty methods, because some user might want to filter by exactly that field, paginate exactly that way, or stitch exactly those two endpoints together in a custom way.

Granularity is correct for a human, because a human can read docs once and remember the layout. The cost of one hundred methods is amortized across years of an integration's life. The benefit is flexibility for the unknown shape of the integration.

The economics flip when the consumer of the API is itself a model.

Now every method is something the model has to either keep in its prompt or look up at runtime. Every version is a tiny regression risk. Every "undocumented edge case in method 87" becomes a silent failure mode that a non-deterministic planner can rediscover in production. The granularity that was free for a human becomes a tax on the agent.

The unit economics of an agent-callable API:

Every tool is context. Tools that the model never calls still cost prompt tokens to describe, every single turn.
Every tool is a branch the planner can pick wrong. More tools means more chances for the planner to confuse two semantically-close behaviors.
Every version pin is a regression risk. A breaking change in a sixteenth-most-used method can silently break trades.
Every edge case is a non-deterministic failure mode. Models sometimes call APIs in ways no human would. The fewer surfaces, the fewer of those.

A human gets bored if they have to read more than ten pages. A model can read ten thousand pages. But it pays for every page in attention, in compute, and — if the API is being called inside a real trading loop — in latency. The SDK-shaped API was never optimized for that cost structure.

The agent-shaped API is the smallest surface that still completes the job

An agent-shaped API answers a different question: what is the minimum set of tools that lets a planning model take a trading intent from "natural language request" to "atomic settlement on chain"?

Walk through what an OTC trade actually requires:

The user wants to buy or sell an asset for another asset, with some constraints (size, deadline, optional counterparty filter). That's an intent.
The protocol needs to broadcast that intent to a set of market makers privately, so the order doesn't leak. That's a sealed-bid RFQ.
A market maker who likes the price needs to commit a price quote. That's a response.
Once a quote is picked, both sides need to lock funds in a way that lets either claim atomically with a shared secret, or refund after a deadline. That's a hash-time-locked contract with four lifecycle operations: lock, claim, refund, inspect.

That's the trade. Every piece of work an agent does end-to-end is one of those steps.

Six tools is not a limit we picked; it's what falls out of writing the minimum version of the surface above:

Tool	What it actually does
`create_rfq`	Taker side: post a sealed-bid intent for a trade.
`respond_rfq`	Maker side: commit a price quote against an intent.
`create_htlc`	Either side: record an on-chain lock for the leg you owe.
`withdraw_htlc`	Either side: claim an HTLC by revealing the preimage.
`refund_htlc`	Either side: reclaim a leg if the counterparty disappears past the deadline.
`get_htlc`	Either side: inspect the live state of any in-flight swap.

That's it. There is no list_markets, no get_orderbook, no cancel_order, no set_leverage, no transfer_internal, no get_balance, no get_kline, no twenty other methods that exist in a CEX SDK because exchange UI screens needed them. We don't need them, because the model the protocol exposes is not a CEX. It's a private auction plus a four-state settlement primitive.

Critically, the trade either settles atomically or it doesn't. There is no half-state to inspect, no "fill ratio" to query, no "stuck order" the agent has to reason about. The HTLC's four-state lifecycle (locked, withdrawn, refunded, expired) is a state machine that fits in any reasonable system prompt without using up the planner's working memory.

What "agent-shaped" actually means in practice

Here's the same trade in two API shapes, side by side:

SDK-shaped, on a CEX:

get_account_balance — does the user have funds?
get_market_info — is the symbol valid, what's the precision, what are the tick sizes?
get_ticker — what's the current best bid/ask?
get_orderbook(depth=20) — sanity-check the depth.
create_order(symbol, side, type, amount, price) — submit.
get_order(orderId) — poll for status.
get_order(orderId) — keep polling.
cancel_order(orderId) — if it doesn't fill in time.
get_trade_history(orderId) — confirm fills.
get_account_balance — confirm.

Ten calls. Six different resources. The planner has to know which resource each method lives on, that order IDs come back as strings on this exchange and integers on that one, that "filled" is a status string here and a boolean over there.

Agent-shaped, on Hashlock Markets:

create_rfq(...) — post intent.
respond_rfq(...) — (maker side, separate flow) commit a quote.
create_htlc(...) — taker locks one leg.
create_htlc(...) — maker locks the other leg.
withdraw_htlc(...) — taker reveals preimage, claims maker's leg.
withdraw_htlc(...) — maker uses the now-public preimage, claims taker's leg.
get_htlc(...) — either side inspects live status anytime.

Six different tools, each with a clear lifecycle role, and a state machine the planner can reason about deterministically. No "is the order partially filled," no "did my limit price actually hit," no "do I need to also cancel the residual." Either both sides have the preimage or both sides refund. That is the only terminal state.

The reduction in surface area isn't a packaging trick. It comes from a different settlement primitive. Sealed-bid RFQ skips order books. HTLC skips custody. Atomic cross-chain settlement skips bridges. Each subtraction removes the tools that would have been needed to reason about that set of failure modes.

The MCP spec is what makes this auditable

The reason the six tools work natively across Claude Desktop, Cursor, Windsurf, OpenAI agent runtimes, and LangChain is that they are exposed via the Model Context Protocol — a tool-surface contract Anthropic published as an open standard.

MCP gives you three things that matter for trading:

A typed tool schema — every tool's inputs are JSON-schema, every output is structured. The planner doesn't have to parse free text. It calls a tool, it gets a typed response, it makes a deterministic next decision.
A stateless transport — the same six tools are available over local stdio (npx -y the canonical hashlock-tech/mcp scoped package) and over Streamable HTTP at hashlock.markets/mcp. One protocol. Two transports. Same surface.
An introspectable contract — when something goes wrong in production, the trace is just a sequence of typed tool calls. Reproducing a bug is calling the same tools in the same order with the same arguments. There is no "but it worked in the SDK" mystery.

This matters less for the planner and more for the operator. When you wire an agent into an SDK and something goes wrong at 3 AM, you debug into someone else's library. When you wire an agent into an MCP server and something goes wrong, you debug into a six-call trace. The mean time to "I understand what happened" is an order of magnitude lower.

What you actually lose by going agent-shaped

Worth being honest about the trade-offs.

You lose orderbook-style market structure. No top-of-book quotes, no Level-2 depth, no fancy order types like trailing-stops or iceberg orders. If your strategy depends on reading the book, you should not use this. You should use a CEX-MCP that wraps a CEX's full trading API, and pay the surface-area tax accordingly.

You lose continuous mid-quotes for free. A sealed-bid RFQ has to have a maker price for your specific intent. If no maker is online for your size on your pair, you wait. A streaming order book gives you a quote even when nobody's serious about your size, but that quote is not honored unless you actually fill against it.

You lose order types beyond market-and-limit. No stops, no brackets, no OCO, no conditional triggers. The intent says "I want to buy X for Y by deadline T." The maker either responds or doesn't.

In return you get:

Six tools to reason about, not six hundred.
Sealed-bid pricing instead of public order leakage.
Atomic cross-chain settlement instead of trust-the-bridge.
A fee floor of 1–2 bps versus the 8–10 bps your CEX is paying internalised by spread.
A surface that the planner can hold in working memory across an entire trade lifecycle.

Most of the strategies an AI agent should run for an end-user — single-asset rebalancing, USD-out at a budgeted slippage, cross-chain hedging, paying a counterparty in a different stablecoin than they invoiced — fit cleanly into this surface. The strategies that don't fit (HFT, market-making at the venue, complex orderbook scalping) are not strategies an end-user wants their agent doing autonomously anyway.

"Six tools" is the headline. Pre-quote validation is the substrate.

The provocation works because the headline is short. The argument that holds it up is longer.

A reasonable follow-up — one that came up explicitly in our May 1 dev.to thread on single-venue CEX-MCPs versus Hashlock Markets and again in yesterday's piece on the four pre-settlement filters — is that "thin tool surface" only works if the protocol is doing the heavy lifting underneath. That's true. The four filters that quotes pass through before the agent ever sees them — counterparty KYC tier, bonded reputation, price-deviation guard, ring privacy — are part of why six tools is sufficient. The protocol absorbs the validation that would otherwise have been a dozen extra methods on the SDK side.

So the full thesis isn't just "fewer tools is better." It's "fewer agent-callable tools, plus a heavier protocol-side validation layer, is what an MCP-driven trading surface should look like."

Six on top, four underneath. That's the shape.

Closing question

The agent-shaped API thesis is a young one. We're 18 months into the MCP era and the right number of tools per protocol is still being argued out across DeFi, agent-runtime, and broker categories.

If you're building or evaluating MCPs in this space, here's the question I'd ask yourself before adding the next method:

What is the smallest tool surface you trust an AI agent with end-to-end on real money?

I'd argue it's smaller than your current SDK. Possibly much smaller. The trades you want an agent doing autonomously, on your funds, are the ones that fit in a state machine the planner can hold in working memory.

If you want to compare the surface yourself, the canonical npm package is at hashlock-tech/mcp (scoped, on npm — install with npx -y and the package name) or remote at hashlock.markets/mcp. Six tools. One auth flow. Three chains: Ethereum, Bitcoin, Sui — Base, Arbitrum, Solana, and TON on the roadmap.

Same surface either way.

If you build agent integrations against trading APIs and have opinions on what the right tool count is for your use case, I'd genuinely like to hear them — drop a comment. There are interesting open questions on both sides of this argument and the category is too young to be sure.

Counterparty validation in sealed-bid RFQ: the four filters before an HTLC locks in on Hashlock Markets

Baris Sozen — Mon, 04 May 2026 09:45:50 +0000

A reasonable critique we keep hearing about sealed-bid RFQ goes roughly: the model fixes intent leakage, sure — but six MCP tools sound thin. Who validates signal quality before settlement locks in?

It's a fair question. "Sealed-bid" tells you what other traders don't see. It doesn't tell you what the protocol does see. So this post walks through the four pre-settlement filters that a quote has to clear on Hashlock Markets before an agent ever sees a price, and before an HTLC ever funds.

The TL;DR: six tools is the surface that an MCP-capable agent calls. The substrate underneath is a four-stage filter chain that runs before respond_rfq ever returns a quote to the caller.

The flow, in one sentence

A trader (human or agent) calls create_rfq with an intent. The intent contains a counterparty_filter block. The protocol broadcasts the auction to the subset of registered market makers that pass the filter. Each maker that wants to quote calls respond_rfq. Their quote runs through three more filters before it lands in the trader's wallet as a quotable offer. Only after the trader picks a quote does an HTLC chain get armed with create_htlc.

So there are two distinct broadcast/filter passes — before auction (Layer 1) and per quote (Layers 2–3) — plus an audience-bounding option (Layer 4) that runs at the broadcast stage for the most selective intents.

Let's walk them.

Layer 1 — counterparty KYC tier (auction-time filter)

Every registered market maker carries a tier:

NONE — anonymous, fresh wallet, no attestation
BASIC — wallet plus light verification (jurisdiction signal, sanctions check)
INSTITUTIONAL — full KYC/KYB attestation with notarized credentials
RING — by-invitation set, pre-approved by a specific trader or trader collective

The trader's intent carries a counterparty_filter field. The simplest form is a minimum tier:

{
  "kind": "swap",
  "give": { "asset": "USDC", "amount": "250000.00", "chain": "ethereum" },
  "want": { "asset": "BTC", "min_amount": "0.0", "chain": "bitcoin" },
  "deadline": "2026-05-04T11:30:00Z",
  "counterparty_filter": {
    "min_tier": "INSTITUTIONAL",
    "exclude": ["did:hashlock:maker:0xabc...123"],
    "include": null
  }
}

When the protocol auctioneer receives this intent, it computes the eligible maker set as { all_registered_makers } ∩ { tier ≥ INSTITUTIONAL } \ { excluded }. A NONE-tier maker never receives the auction broadcast for this intent. No off-chain hint, no sniff of the size. They simply aren't on the wire.

This matters because the most common information-leakage attack on RFQ systems isn't a leak from the trader, it's a leak through the maker pool — a quoting maker walks the order to a backchannel before responding. Bounding the auction audience to attested makers cuts the attack surface up front.

Layer 2 — bonded reputation (per-quote filter)

A quote is not free. To call respond_rfq and have the quote land in the trader's wallet, the maker has to post a bond that is slashable on:

cancel-after-quote (maker walks back the quote before the trader's chosen-quote window closes)
failure-to-fund (maker is selected but doesn't lock the matching HTLC within the protocol's lock-window)
repeated stale quotes (a Sybil-style noise pattern that the auctioneer detects across windows)

The bond size scales with the maker's tier and the intent's notional. The accounting is per-pair, so a maker with a great track record on USDC↔BTC and a thin track record on USDC↔SUI carries different bond requirements per intent type.

The slash conditions are checked at three points: end of quote window, end of HTLC arming window, and end of HTLC settlement window. Slashed bond is paid out partly to the trader (as a settlement-failure cushion) and partly burnt — the second piece is what makes spam economically negative.

The visible effect is that a maker's quote isn't just a price — it's a price plus economic skin. That's the bit a "what validates the signal?" critique often misses: the quote-side bond is the answer to the maker's information advantage. The maker can know more than the trader, but they can't extract that information for free.

Layer 3 — price-deviation guard (per-quote filter)

Before a quote lands in the trader's wallet as a clickable offer, the protocol applies a hard sanity check against an internal mid-mark for the pair. Quotes whose midpoint is more than N basis points off mid are dropped. They don't reach the trader. The maker is not slashed (this isn't a malicious-quote condition, it could just be stale data on the maker side), but the quote is filtered.

The mid-mark itself is an oracle composite — a TWAP across the protocol's own internal trade history for the pair, blended with external feeds, with the blend weights tuned per pair (deeper pairs weight internal history more, shallow pairs weight external feeds more). The deviation threshold N is a per-pair parameter that the protocol tunes against the realised volatility of the pair, so a stable-stable pair has a tighter deviation threshold than a long-tail pair.

The point of this layer is not to enforce a "fair price" — sealed-bid auctions are explicitly designed so the trader picks among quotes — it's to drop quotes that would never be acceptable to any rational trader. It's a noise filter. An agent that hands a quote-list to its routing logic is then choosing between quotes that are all within a sane band, instead of having to reason over outlier garbage.

For an agent in particular, this is the layer that makes "quote shopping" tractable. Your LangChain or Claude Desktop or Cursor-driven agent doesn't have to write outlier-handling code; the protocol's already done it.

Layer 4 — ring privacy (auction-time, optional)

Ring privacy applies for the most sensitive intents. Instead of broadcasting to "all makers passing the tier filter", the trader can specify an inclusion list — a hand-picked set of counterparty DIDs:

"counterparty_filter": {
  "min_tier": "RING",
  "include": [
    "did:hashlock:maker:0x1f...aa",
    "did:hashlock:maker:0x82...c4",
    "did:hashlock:maker:0xb7...39"
  ],
  "exclude": null
}

Now the auction broadcasts only to those three makers. The intent isn't visible to the rest of the maker pool at all. This is the OTC-desk pattern: a trader who has a relationship with three institutional desks runs the RFQ across those three only. Sealed-bid (each maker's quote is private from the others) and audience-bounded (the intent itself is only visible to the chosen audience).

For agent-to-agent trading — two agents who already know each other's DIDs — Layer 4 is the natural default. The MCP server exposes the counterparty_filter field on create_rfq, so the agent's logic just sets include: [counterparty_did] for a known counterparty trade.

Putting it together

The quote that finally lands in the trader's wallet has cleared:

an auction-audience filter (Layer 1, optionally Layer 4)
a per-quote bonded reputation gate (Layer 2)
a per-quote price sanity check (Layer 3)

Then the trader picks a quote. Only then does create_htlc arm the cross-chain settlement, and the HTLC's hashlock+timelock primitives take over for the actual atomic exchange.

So the answer to "who validates signal quality before settlement locks in?" is: the protocol does, in four layers, before an agent ever sees the quote and before any chain's HTLC contract is touched. The MCP tools (create_rfq, respond_rfq, get_htlc, create_htlc, withdraw_htlc, refund_htlc) are the user-facing surface. The validation chain is the machinery underneath that makes the surface usable.

What this means for agent builders

If you're wiring an MCP-capable agent (Claude, GPT, LangChain, Cursor, custom runtime) into Hashlock Markets, three practical implications:

You don't need to write counterparty-quality logic. Set min_tier on the intent and let the protocol filter the audience. Default to BASIC for retail-size intents, INSTITUTIONAL for size, RING for desk-to-desk and agent-to-agent.
You don't need to write outlier-quote handling. Layer 3 already drops the noise. Your routing code chooses among quotes within a sane band.
You don't have to trust that a quote will be honored. Layer 2's bond is the maker's economic commitment. Cancel-after-quote and failure-to-fund both burn maker collateral.

That's the substrate the six tools sit on. Sealed-bid is the headline; the four-layer validation chain is what makes the headline true under load.

The MCP server is on npm as @hashlock-tech/mcp (scoped) and on the canonical MCP Registry at io.github.Hashlock-Tech/hashlock. Two transports: stdio via npx -y @hashlock-tech/mcp, or hosted Streamable HTTP at https://hashlock.markets/mcp. SIWE on the auth, six tools on the wire, and the four-layer filter underneath.

If you've been on the fence about pointing an agent at non-custodial OTC because counterparty quality felt like a black box — this is the box.

Hashlock Markets — sealed-bid RFQ + HTLC atomic settlement for AI agents.
Site: https://hashlock.markets
Hosted MCP: https://hashlock.markets/mcp
GitHub (canonical): https://github.com/Hashlock-Tech/hashlock-mcp

A week of intent-based trading for AI agents: five threads from the Hashlock Markets desk

Baris Sozen — Sun, 03 May 2026 06:18:26 +0000

A week of intent-based trading for AI agents: five threads from the Hashlock Markets desk

The Model Context Protocol surface for crypto trading filled out fast over the last few weeks. Bybit shipped MCP coverage. Gemini added an agentic platform. Alpaca, Kraken, Hummingbot, TraderEvolution, and a handful of community wrappers are all in the same SERP now. The category is real, and it is crowding.

This is a recap of the five threads we worked through here this week — what each one was about, why it matters in a category that is suddenly busy, and what we think is going to matter most going forward.

1. Why public order books are not the right primitive for AI traders

The week opened with the structural argument: public order books and transparent mempools were designed for humans clicking in browsers. Every assumption baked into that design — that the trader is patient, that signaling intent is a feature, that retrying a failed cross-chain swap is acceptable — breaks down when the trader is an autonomous agent operating at machine speed.

An agent that broadcasts a large order into the mempool is feeding free information to every searcher and frontrunner watching that mempool. The order book is supposed to be a price discovery mechanism, but for size, it is a leakage mechanism. The architectural answer is simple to state and hard to build: discovery should happen in private, and settlement should happen atomically.

That is the protocol shape Hashlock Markets settled on. Sealed-bid RFQ for price discovery — takers post a request, market makers respond with sealed quotes, the taker chooses. HTLC for settlement — both legs lock against the same hash, the hash is revealed, both legs unlock. Either the trade settles or it doesn't.

2. One URL for any agent runtime

The MCP spec originally shipped with stdio as the canonical transport: an agent spawns the server as a child process and talks to it over standard input and output. That is fine on a developer laptop, but it does not survive contact with a production agent runtime that lives in a serverless function or a remote container.

Streamable HTTP is the answer the spec landed on, and it is what Hashlock Markets serves at https://hashlock.markets/mcp. That single URL is all an agent runtime needs to know. Claude Desktop, Cursor, an OpenAI agent loop, a LangChain runner, a custom Python client — same endpoint, same six tools, same auth flow.

The npm package @hashlock-tech/mcp is still the right path for stdio deployments where you want the server in-process. Both paths are first-class.

3. Six MCP tools, full trading lifecycle

The whole surface is six tools, deliberately:

create_rfq — a taker posts a sealed-bid request describing what they want.
respond_rfq — a market maker posts a sealed quote against an open RFQ.
create_htlc — once a quote is selected, both sides lock funds against a hash.
withdraw_htlc — the holder of the preimage settles the trade.
refund_htlc — if the timeout expires, locked funds return.
get_htlc — read state for any HTLC by id.

There is no SDK to import. There is no fifty-method client class to pin to a major version. There is no separate auth library. SIWE handles authentication, the MCP server handles the rest. An agent that can call six functions has the full Hashlock Markets surface.

This minimalism is intentional. Tool surfaces grow in two ways: deliberately, when a real new capability arrives, or accidentally, when convenience methods accrete around a leaky core. The HTLC + RFQ core is what Hashlock Markets sells; everything else can be composed on the agent side.

4. Where Hashlock sits relative to the CEX-MCP wave

The single-venue CEX-MCPs are useful, and they are not the same thing. A Bybit MCP, an Alpaca MCP, a Kraken CLI wrapped into MCP — each of those gives an agent access to one venue's order book over one venue's API. Liquidity is whatever that venue has. Settlement is custodial, on the venue's books. Cross-asset moves require the agent to bridge between venues itself.

Hashlock Markets is a different shape. It is not a wrapper around one venue's API; it is a settlement protocol with a quoting layer on top. Liquidity comes from competing market makers via sealed-bid RFQ. Settlement is non-custodial — the protocol never holds either side of the trade. Cross-chain is native: an agent can swap ETH for BTC for Sui without touching a bridge, because the HTLC primitive handles cross-chain atomicity directly.

Both categories will exist. The single-venue CEX-MCP makes sense for an agent trading inside one liquidity pocket. Hashlock Markets makes sense when the trade has to cross venues, cross chains, or stay non-custodial.

5. Wire Claude in ten minutes

The most pragmatic thread was also the most concrete: a hands-on tutorial for getting Claude wired into Hashlock Markets in roughly ten minutes. Sign in with SIWE, point Claude Desktop at hashlock.markets/mcp, give the agent a prompt that describes a trade in natural language, watch it walk through create_rfq → respond_rfq → create_htlc → withdraw_htlc. Cross-chain swap, atomic settlement, no manual steps in between.

That ten-minute path is the intended entry point. The argument for intent-based trading is more compelling once you have actually watched an agent execute one.

What's coming next

Three things on the near horizon worth flagging.

First, more chains. Ethereum, Bitcoin, and Sui are live. Solana and Arbitrum are next. Each new chain expands what a single intent can route across.

Second, the differentiation page. The "AI agent trading MCP" category is crowded enough that a structured comparison — sealed-bid versus public quote, atomic versus custodial, cross-chain versus single-venue — earns its keep. Expect that to land soon as a public page rather than buried in docs.

Third, more tooling for market makers. The taker side of the protocol is well-trodden because of the agent narrative. The market-maker side is where pricing and inventory management get interesting, and where there is a lot of headroom for tools that haven't been built yet.

If you are running an agent today and the trading layer is the part that feels brittle, the ten-minute path is the place to start: hashlock.markets.

What's your current MCP trading runtime setup, and what is breaking?

The 6 MCP tools in Hashlock Markets — what each one does and when an agent calls it

Baris Sozen — Sat, 02 May 2026 06:24:47 +0000

When you wire an AI agent into Hashlock Markets, it gets exactly six MCP tools. That is the whole surface. There is no SDK to import, no fifty-method client to pin to a major version, no separate auth library. Six tools, one protocol, and a trade either settles atomically or it doesn't.

This post is the FAQ that I get most often from teams evaluating the surface for the first time: what are the six tools, what does each one do, and when does the agent actually call it?

Two halves of the surface

The six tools split cleanly into two halves:

Two RFQ-side tools — these are about price discovery without information leakage.
Four HTLC-side tools — these are about settlement without escrow or bridges.

Both halves are designed to be called directly by an autonomous agent. Every tool takes typed inputs, returns typed outputs, and corresponds to a single onchain state transition (or, in the RFQ case, a single signed off-chain action). Nothing in the surface assumes a human in the loop.

The two RFQ tools

`create_rfq` — post a sealed-bid intent

A taker calls this when it knows what it wants but doesn't know the price yet. The arguments describe the trade: which asset out, which asset in, the maximum slippage you're willing to tolerate, the deadline, and the chains involved. The output is an RFQ identifier that makers can quote against.

The "sealed-bid" part is the structural property: the bid is not broadcast to a public book the moment it's created. It's posted into a Request-for-Quote venue where makers see only the parameters they need to price the trade. Public order books can't do this — by the time a price is on a public book, the leakage has already happened. For agent flows where the same AI decides what to trade and how to trade it, the leakage difference compounds quickly.

`respond_rfq` — quote against an open RFQ

A maker (an agent or a desk running its own MCP-connected service) calls this with a quote against an open RFQ: the price, the size, and a signature committing to the maker's side of the trade. The taker then chooses among the responses based on its own decision logic.

Two shapes of agent populate this side: market-maker desks plugging their internal pricing into an agent runtime, and pure-play onchain takers that occasionally provide quotes when their inventory aligns. The same MCP surface works for both — respond_rfq doesn't know which kind of caller is on the other end.

The four HTLC tools

The settlement layer uses Hash Time-Locked Contracts. The mechanics are old (HTLCs predate cross-chain DEXes by years), but the property they give you is exactly what a sealed-bid trade needs: either both sides settle, or neither does, with no third party holding funds in between.

`create_htlc` — lock funds under a hashlock and a timelock

The party initiating settlement (typically the taker after an RFQ match) locks the funds they're paying with into a contract that releases them under one of two conditions: the counterparty reveals a secret preimage before the timelock expires, or the original sender reclaims them after the timelock expires. Every HTLC has both an absolute deadline and a hashlock derived from a secret only the initiator knows at first.

`withdraw_htlc` — claim with the secret preimage

When the counterparty has also locked their side and the trade is matched, both sides reveal the secret to claim the locked funds. Because the same secret is used on both sides of the swap, the moment one side claims, the other side learns the preimage and can claim too. Atomicity falls out of cryptography rather than out of trust in a custodian.

`refund_htlc` — reclaim if the counterparty disappears past the timelock

This is the tool agents don't want to call but the existence of which is what makes the system safe. If the maker quotes, the taker locks, and then the maker walks away (network failure, mispriced their book, malicious behavior — doesn't matter), the timelock expires and the taker calls refund_htlc to recover their funds. No human arbitration. No "open a ticket". The contract enforces it.

This is the answer to the most-asked question from new agent builders: what happens when an RFQ counterparty disappears? Counterparty risk is the unsolved problem in OTC. HTLC + sealed-bid + atomic refund is one concrete answer.

`get_htlc` — inspect an in-flight swap

Read-only. Given an HTLC identifier, return its current state: which chain, which assets, the hashlock, the timelock, whether it's been claimed or refunded, the counterparty addresses, and the relevant tx hashes. Most of the time an agent doesn't need to call this — it knows the state because it issued the prior calls. But for resumption after a crash, for monitoring, and for reasoning about its own portfolio, this is the inspector tool.

A typical trade is four calls per side

For a successful cross-chain trade, the call sequence is straightforward:

Taker side: create_rfq → wait for quotes → pick one → create_htlc on the source chain → withdraw_htlc on the destination chain once the maker has locked there.

Maker side: respond_rfq → wait for the taker to choose → create_htlc on the destination chain → withdraw_htlc on the source chain once the taker reveals the preimage.

refund_htlc is the failure path; get_htlc is the read path. In a healthy cross-chain trade, four calls per side, no human, no custodian, atomic.

Why this surface and not a bigger one

You could imagine a larger MCP server that exposes "send order", "cancel order", "open position", "close position", "transfer between accounts", "withdraw to wallet" — the kind of surface a CEX REST API has. That is the shape of single-venue exchange MCPs that have been landing recently in the same MCP category.

The Hashlock Markets surface is deliberately smaller because the protocol is deliberately smaller. There is no exchange-side account holding your funds. There is no "position" in a centralized ledger separate from your wallet. There is no internal transfer concept; settlement is the wallet movement. So the MCP surface only exposes the operations that exist: post intent, quote intent, lock, claim, refund, inspect.

If your agent is going to drive real money flows from inside a runtime, "every tool corresponds to a single onchain state transition" is a property worth a lot. It means there is no hidden exchange-side state for the agent to get out of sync with. It means a crash mid-trade leaves you with onchain state that any subsequent run can reason about with get_htlc. It means the auditing burden is bounded.

Two ways to wire it up

The same six tools are reachable through two transports.

stdio. Run npx -y against the hashlock-tech/mcp scoped package on npm and the MCP server runs locally inside your agent's process. This is the right transport for desktop agents, for CLI tools, and for anywhere your runtime can spawn local Node processes.

Streamable HTTP. Point any MCP-compatible client at https://hashlock.markets/mcp and the same six tools are reachable as a remote endpoint, authenticated with a SIWE-derived JWT. This is the right transport for serverless deployments, for managed runtimes that don't ship Node, and for cases where you'd rather pin to one URL than to a binary version.

The tool definitions are identical across both transports. There is no "stdio-only" or "HTTP-only" tool.

When evaluators ask "is this enough?"

The honest answer: the six tools are enough to execute real cross-chain trades end-to-end with atomic settlement, and that is the entire goal of the surface. Anything beyond that — portfolio analytics, historical pricing, liquidity routing across multiple intent venues, MEV-aware ordering — those live one layer above MCP, in the agent runtime itself. The MCP surface is the deterministic, auditable, minimal control plane.

If you're building an agent that needs to put real money on the line, you generally want the smallest tool surface that still lets you get the job done. Six is the answer here.

Try it. Canonical npm package: hashlock-tech/mcp (scoped) on npmjs.com. Hosted endpoint: https://hashlock.markets/mcp. Repository and full reference: https://github.com/Hashlock-Tech/hashlock-mcp. Project: https://hashlock.markets.

What's the smallest tool surface you've found that still lets an agent execute real trades end-to-end?

Single-venue CEX-MCPs vs Hashlock Markets: where the lines actually break

Baris Sozen — Fri, 01 May 2026 06:16:59 +0000

In the last few weeks the Model Context Protocol surface for crypto trading has filled out in a hurry. Bybit shipped MCP coverage. Gemini added an agentic trading platform that speaks MCP. Alpaca's MCP server has been stable for months and is currently the most prominent result for "AI agent trading MCP" on Google. Kraken has a CLI that wraps into MCP. Hummingbot's open-source bot framework now exposes an MCP server. TraderEvolution shipped one for institutional desks. Tradingview has community MCP wrappers. The category is real, growing, and increasingly crowded.

This is good news. MCP is becoming the lingua franca for "give an AI agent a venue and let it trade", which is exactly what it should become. But almost every server in that wave shares the same shape: it's a wrapper around one venue's REST and WebSocket APIs. The agent gets a tool surface that looks like place_order, cancel_order, get_balance, get_ticker. Underneath, there's a single exchange and a single account.

That shape is great for a lot of workloads. It's also where the lines start to break for three workloads that show up the moment you push agentic trading past hobby scope. This post walks through those three, what Hashlock Markets does differently, and when each design wins.

The shape of a single-venue CEX-MCP

A typical CEX-MCP exposes the venue's API as MCP tools:

place_order / cancel_order / get_open_orders
get_balance / get_position / get_account
get_ticker / get_orderbook / subscribe_trades

The agent authenticates once with API keys, the MCP holds them, and every call goes to that one exchange. This is the path of least resistance and it's the right answer for many situations: a single-venue strategy on Alpaca, a market-making loop on Bybit, a basis trade on Gemini. The MCP is doing what it's supposed to do: exposing the venue cleanly to an agent that already knows what it wants to do there.

Hashlock Markets is a different shape. Its current MCP surface is six tools centered on intents and atomic settlement:

create_rfq and respond_rfq for sealed-bid quote flow
create_htlc, withdraw_htlc, refund_htlc, get_htlc for hash time-locked atomic settlement

There is no place_limit_order because there is no public order book on Hashlock. There is no bridge_assets because cross-chain settlement happens inside the HTLC, not over a bridge. The agent's tool surface looks intent-shaped, not venue-shaped. That is a deliberate choice, and the rest of this post is the case for when that choice matters.

Workload 1: cross-venue price discovery without leaking the order

The cleanest use case for an agentic trader is also the one a single-venue MCP cannot answer by definition: I want the best price across multiple venues, and I do not want to broadcast my interest to public books while I look.

With a stack of single-venue MCPs, the agent can poll each venue's order book and sweep. That works for small sizes. It also leaks information: any taker reading the same books sees the same liquidity, and once the agent starts walking depth, the market sees it walking depth. For programmatic flow that is the price you pay. For larger sizes or for repeat trades, it accumulates into measurable execution shortfall.

Sealed-bid RFQ inverts that. The agent declares an intent ("I want X of asset A in exchange for asset B, settled by time T") and that intent is broadcast only to authorized market makers. Each maker quotes privately. The agent picks the best quote. The order never appears in any public book before it is committed.

In Hashlock Markets the flow is two MCP calls: create_rfq to post the intent, respond_rfq to accept the chosen quote. The agent does not have to manage venues or accounts. Makers compete privately on price, the winner settles, the rest see only that they lost.

When this matters: medium-and-up size, repeat trades, or any situation where information leakage is a measurable cost. When it doesn't: small spot orders where displayed liquidity already swallows the size.

Workload 2: cross-chain settlement without bridges

The second wall a single-venue MCP hits is anything that crosses chains. Most CEX-MCPs do not handle this at all - the venue holds custody on both sides and "cross-chain" is just a withdrawal. For DEX-MCPs, the answer historically has been a bridge: lock asset on chain A, mint or release a representation on chain B, swap there.

Bridges have a long and well-documented track record of being the most attacked surface in the entire ecosystem. They are also operationally awkward for an agent because the leg-by-leg flow has many failure modes and partial-state recoveries.

Hash Time-Locked Contracts solve the same problem with very different mechanics. Both legs of the swap are committed to the same secret hash. Either both legs reveal the secret and complete, or neither does and both refund after a timeout. There is no third party holding the assets. There is no bridge. The agent does not have to reason about partial states because there are no partial states; the swap is one logical operation that either completes or unwinds.

In Hashlock Markets this is the four *_htlc tools. For an agent, the loop is straightforward: create_htlc on chain A, create_htlc on chain B (or have the counterparty do it), withdraw_htlc to claim once both sides are funded, refund_htlc if the counterparty disappears. get_htlc exposes state for monitoring.

When this matters: any swap whose legs live on different chains. The current chain set is Ethereum, Bitcoin, and Sui, with Solana and Arbitrum on the near roadmap.

Workload 3: two AI agents trading directly

The third workload is the one most people aren't thinking about yet, and is the cleanest argument for why intent-shaped tooling matters going forward. As more trading is done by software agents, more counterparties are software agents. At some point two agents need to trade with each other - not through a venue's matching engine, but with each other directly.

That is hard to do well on a public order book because both sides are revealing intent into a market full of other agents looking for exactly that signal. It's also hard with a single-venue CEX-MCP because the venue is the counterparty model: an agent on Bybit and an agent on Gemini have no shared venue to trade in.

Sealed-bid intents handle agent-to-agent trading directly. Either agent can be a taker (create_rfq) or a maker (respond_rfq). The matching is on the protocol, not on a venue. Settlement is HTLC, so neither agent needs to trust the other's custody.

When this matters: as agentic flow grows, the share of trades that are agent-to-agent rather than agent-to-venue grows with it. Designing for that case now keeps the protocol from having to be retrofitted later.

When the single-venue shape is the right answer

This is not a "Hashlock vs everyone" pitch. The category sorts cleanly by workload:

If the agent's job is to operate a single venue well - a market-making loop, an algorithmic strategy on a specific exchange, a portfolio rebalance against custodied assets on one platform - a single-venue CEX-MCP is exactly the right tool. It is simpler, latency-optimized for that one venue, and the auth model is straightforward (API keys held by the MCP).

If the agent's job is to discover the best price across venues without leaking, settle across chains atomically, or trade with another agent directly, the venue-wrapper shape runs out of road. That is the surface Hashlock Markets is designed for.

In practice many agent stacks will end up with both: a single-venue MCP for the venue they execute in most often, and an intent-shaped MCP for the cross-venue, cross-chain, agent-to-agent workloads. The two compose cleanly because both speak the same MCP wire format.

Connecting an agent to Hashlock Markets

Two transports are supported, same six tools either way:

stdio (good for local development, IDE-embedded agents, anything that can spawn a child process):

npx -y @hashlock-tech/mcp

Streamable HTTP (good for hosted runtimes, containerized agents, anything where spawning local processes is awkward):

https://hashlock.markets/mcp

Auth is Sign-In with Ethereum (SIWE) - the agent signs a SIWE message with its wallet, gets back a JWT, and uses that on subsequent calls. The wallet that signs in is the wallet that settles HTLCs.

The package is @hashlock-tech/mcp on npm. Source and the canonical README are at https://github.com/Hashlock-Tech/hashlock-mcp.

The category direction

The "AI agent trading MCP" category is converging on two layers that will sit alongside each other for a while:

The venue layer - single-venue MCPs that wrap each major exchange or trading platform. This layer is filling out fast and is broadly a good thing.

The protocol layer - intent-shaped MCPs that handle the workloads no single venue can: cross-venue discovery without leakage, cross-chain atomic settlement, and agent-to-agent matching. This layer is much earlier and Hashlock Markets is one of the bets on it.

If you're picking what to wire your agent into, the question to ask is which layer your workload lives at. For single-venue work, pick a venue MCP. For the workloads that cross venues, chains, or agents, the intent layer is what you want.

More on the protocol design at https://hashlock.markets - the docs page walks through sealed-bid RFQ and HTLC settlement in more detail.

One URL for any agent runtime: the hosted Hashlock MCP endpoint

Baris Sozen — Thu, 30 Apr 2026 13:29:59 +0000

One URL for any agent runtime: the hosted Hashlock MCP endpoint

When the Model Context Protocol spec landed, the canonical transport was stdio: an agent spawns the MCP server as a child process and talks to it over standard input and output. That choice was reasonable. Stdio is fast, has no network surface, and on a developer's laptop it's the path of least resistance.

It is also a poor fit for almost every production deployment of an agent.

Hashlock Markets ships the same six MCP tools over both transports. The npm package, hashlock-tech/mcp (scoped on npmjs), is the stdio path. The other path is a hosted endpoint at https://hashlock.markets/mcp, served as Streamable HTTP MCP. This post is about the second one — what it is, why it matters, and when to reach for it instead of stdio.

The protocol home page is at https://hashlock.markets and the canonical repository is at https://github.com/Hashlock-Tech/hashlock-mcp.

Why a hosted endpoint matters

The short version: most agent runtimes that run anywhere other than a developer laptop have a hard time spawning local subprocesses, and a really hard time keeping one alive across requests.

Browser extensions can't spawn subprocesses at all. Claude in Chrome, for example, talks to MCP servers over HTTP, not stdio. Serverless platforms — Vercel functions, Cloudflare Workers, Lambda — either can't spawn subprocesses at all or spin up a fresh container per invocation, which means a stdio server would have to be cold-booted on every tool call. That's not workable for a tool surface that needs auth state, in-flight RFQs, and live HTLC subscriptions.

Hosted orchestration platforms — the kind of system a team builds to run agents at scale — usually centralize MCP routing through an HTTP layer for the same reasons they centralize everything else: load balancing, observability, secret management, and not having one fork-bomb of an agent take down the host.

For all of those, "spawn npx hashlock-tech/mcp and pipe its stdout" is the wrong question. The right question is "what URL do I point my MCP client at?" The answer is https://hashlock.markets/mcp.

What the endpoint is, technically

It's a Streamable HTTP MCP server. The transport is the standard one defined in the MCP specification: long-lived HTTP requests carrying JSON-RPC messages, with server-sent events for streaming responses back. Any MCP client that implements Streamable HTTP — which is most of them at this point — can connect.

The server exposes exactly the same six tools as the npm package:

create_rfq — declare a trading intent and open the auction window
respond_rfq — used by market makers to submit sealed bids
create_htlc — lock funds on-chain against a hash
get_htlc — read HTLC state across the supported chains
withdraw_htlc — claim with the preimage
refund_htlc — reclaim if the counterparty doesn't complete in time

Same names, same shapes, same semantics. The MCP client doesn't know it's talking to a hosted server versus a local one — that's the whole point of MCP as a protocol.

Authentication is SIWE — Sign-In with Ethereum — across both transports. The agent signs a message with the wallet you've delegated to it, the server verifies the signature, and a session is opened. There are no API keys, no bearer tokens to leak, no .env file to babysit.

When to pick which transport

The decision is mostly about where the agent runs.

Reach for stdio (npx -y hashlock-tech/mcp configured as a local MCP server) when:

You're developing or prototyping on a workstation. The local-process boot is fast and you don't pay any network round-trip.
Your agent runtime is a desktop application that already manages MCP server processes (Claude desktop is the canonical example).
You want zero network surface between the agent and the MCP server.
You're running the agent in a long-lived host where one process per agent is fine.

Reach for https://hashlock.markets/mcp (Streamable HTTP) when:

You're deploying to a hosted runtime, a serverless platform, or a browser extension. Anything that doesn't have a friendly relationship with subprocess spawning.
Your agent is going to be called with high concurrency and you don't want to hold N stdio servers open per tenant.
You want a single environment-independent URL — same one across local, staging, and production. The MCP client config doesn't change between environments.
You're integrating with a hosted orchestrator or platform that exposes MCP servers as HTTP routes.

A non-trivial number of teams use both. Local development against stdio for fast iteration; production against the hosted URL because the runtime can't spawn subprocesses. The MCP client config is the only thing that changes between the two.

What it doesn't change

It's worth being explicit about a few things that are identical between transports because the question comes up.

The trading guarantees are the same. Sealed-bid RFQ means quotes stay private until the trader picks one. HTLC settlement means both legs of a cross-chain trade complete or both refund. The chain coverage is the same — Ethereum, Bitcoin, and Sui live, with Solana and Arbitrum on the roadmap. The auth model is the same — SIWE with a delegated wallet that the agent never holds long-lived secrets for.

The set of tools is the same. The names are the same. The argument shapes are the same. If you've built an agent against the stdio version and you want to redeploy it against the hosted endpoint, the MCP server config is the only thing that changes. No business logic to rewrite, no second SDK to learn.

A small but important practical note

The hosted endpoint is a real production server, not a developer-mode demo. It's behind the same uptime monitoring, logging, and rate-limiting as the rest of the platform. A trading agent pointed at it can rely on it the way it would rely on any production API.

That said, if you're operating a high-volume agent and you want lower-latency local execution against the same protocol, stdio remains a perfectly good answer. The choice is yours, and it's not load-bearing — both transports are first-class.

Where to start

If you're building an MCP-capable agent and Hashlock Markets is somewhere on the integration list, here's the practical decision tree.

For a local development setup, configure your MCP client with npx -y hashlock-tech/mcp (the scoped package on npmjs) as a local server. Sign in via SIWE. Call create_rfq to test the connection.

For a production or hosted deployment, point your MCP client at https://hashlock.markets/mcp. Sign in via SIWE. Call create_rfq to test the connection.

The home page is https://hashlock.markets and the canonical repository — including the README, tool reference, and example configs — is at https://github.com/Hashlock-Tech/hashlock-mcp.

The point of the dual-transport design is that you should not have to rewrite your agent when you move it from a workstation to production. One URL when you need it, one local process when you don't, the same protocol underneath.

Public order books were built for humans. AI traders need a different market structure.

Baris Sozen — Wed, 29 Apr 2026 07:42:39 +0000

Public order books were built for humans. AI traders need a different market structure.

For about a decade, the question of how on-chain markets should be structured has been answered by humans, for humans. Open order books, public AMMs, transparent mempools, manual cross-chain bridges with retry buttons. Every choice in that stack assumes the trader at the keyboard is a person, working at human speed, with human patience for partial failures.

That assumption is on the way out.

The dominant on-chain trader of the next decade is going to be an autonomous agent — sometimes wrapped in a human-feeling chat UI, increasingly running headless against a strategy. And once you accept that, the architecture we built for humans starts to look like the bottleneck rather than the foundation.

This post is the thought-leadership version of that argument. The companion piece — how to wire an MCP-capable agent into the protocol — went up yesterday. Today's post is about why this matters at all.

The features of public order books are bugs for agents

Three properties of the standard DeFi venue look fine if you assume a human trader. They look terrible if you assume a software one.

Quotes are public. A market maker who posts a tight bid on a public book is announcing intent to every other participant. Faster bots reprice off it. Toxic flow targets it. The MM responds rationally: widen the spread, post less size, and let the trader pay the bid-ask premium. A human trader in this game accepts that as the price of liquidity. An agent running thousands of trades against the same regime is bleeding alpha to a structural feature, not a market move.

Intents leak to the mempool. Every public-book trade goes through a stage where the user's intent is visible to anyone watching pending transactions. MEV searchers compete to extract value from that visibility — sandwiches, frontruns, backruns — and the user pays for the privilege of having broadcasted what they wanted. The MEV tax is small per-trade, large in aggregate, and trivially scaled with trade volume. An agent that's running a strategy with a positive but thin edge will see that edge eroded by the leakage, not by competition.

Settlement is one-leg-at-a-time. Cross-chain swaps that go through bridges, wrappers, or trusted intermediaries are exposed to a class of failures that a human can recover from with a support ticket and a patient afternoon. An agent operating unattended cannot. A half-completed cross-chain swap, with funds locked on one side and the bridge offline on the other, is an unrecoverable loss for software that doesn't have the social graph to escalate it.

A human trader has learned to route around all three. They use private order flow, MEV-protect endpoints, and they pick chains where the bridges have a reputation. None of those workarounds scale to an agent placing hundreds of intents an hour across five chains.

What an agent-native market structure looks like

If you start from "the trader is software" and design forward, you get a different stack. Three primitives matter.

The first is sealed-bid RFQ. The trader declares an intent — what they want to swap, in what size, on what chains — and the network of market makers prices it privately. Each market maker sees the intent but not other market makers' quotes. The trader picks the best one. No public order book, no public visibility window, no mempool exposure. The bid-ask premium that public books charge for adverse selection collapses, because the adversarial selection isn't possible.

The second is HTLC atomic settlement — Hash Time-Locked Contracts. Both sides of a cross-chain trade lock funds against the same hash. The first claim publishes a preimage that the counterparty needs to claim their leg. The settlement guarantee is a property of the math, not of a bridge operator's uptime. Either both legs complete, or both legs refund after the timeout. There is no state where one side has been paid and the other hasn't. For a software trader, this is the difference between a recoverable error and a write-off.

The third is agent-native interface. The protocol exposes itself as an MCP server — Model Context Protocol — so any MCP-capable agent runtime can call it directly. There's no scraping a web UI, no glue code translating REST into intent, no per-runtime SDK to maintain. An agent built on Claude calls the same tools as one built on a custom orchestrator.

Each of those three is a feature on its own. Together they describe a venue that an agent can actually operate without human supervision: private quoting, atomic cross-chain settlement, native agent interface.

The compounding argument

The case isn't "human traders will disappear." Plenty of trading is going to remain human, and the venues that humans love — visible books, social signals, the satisfaction of a manual fill — will keep existing.

The case is that the cost structure of running software against human-designed venues compounds in a way that doesn't matter at one trade per hour but does matter at one trade per second. A 30-basis-point MEV tax on every fill is rounding error for a person making a few decisions a day. It's a death-by-a-thousand-cuts margin compression for an agent running a continuous strategy. A one-leg-failure rate of 0.1% is a story over coffee for a human; it's an unrecoverable expected loss line item for software.

When the marginal trader becomes the agent, the venue that costs them the least linearly wins the volume.

What this changes about how protocols compete

The implication for protocol design is the same as the implication for any infrastructure question: the consumer of the API gets to define what good looks like. For most of DeFi's history that consumer has been a human looking at a chart. The migration toward agent-driven trading flips that. Spread tightness, MEV exposure, atomic-settlement guarantees, and clean machine interfaces — these become the things a venue is benchmarked on, because those are the things the marginal trader cares about.

You can already see the early version of this happening. Protocols that look great in a UI but expose noisy or non-atomic surfaces are losing share to ones that look spartan to humans but feel deterministic to agents. RFQ-based venues are taking volume from public-orderbook DEXs in the size buckets where the trader is sophisticated enough to care. The trajectory of the next several years is more of that, not less.

Where Hashlock Markets fits

Hashlock Markets is built on those three primitives — sealed-bid RFQ, HTLC atomic settlement, and an MCP server interface — for exactly the agent-native trading environment described above. The protocol is live across Ethereum, Bitcoin, and Sui, with Solana and Arbitrum on the roadmap. Authentication is SIWE, so an agent never holds a long-lived secret; it signs with the wallet you delegate, and you revoke access by rotating the key. Tools are stable and well-documented, and the npm package is published as hashlock-tech/mcp (scoped on npmjs).

The protocol home is at hashlock.markets. The canonical repository is github.com/Hashlock-Tech/hashlock-mcp.

The takeaway

Whether you're building a strategy, a market-making operation, or just plugging an agent into a wallet to handle treasury swaps, the venue you pick is going to matter more as the trader on the other end becomes more software-shaped. The properties that matter — privacy of intent, atomicity of settlement, clean machine interfaces — aren't optional features. They're the basic structure of a market that software can actually operate in.

The next decade of on-chain trading is going to be driven by agents. The protocols that win that volume will be the ones that stopped pretending the trader is a human a long time before everyone else figured it out.

Wire Claude into Hashlock Markets in 10 minutes: a hands-on MCP tutorial

Baris Sozen — Tue, 28 Apr 2026 06:22:12 +0000

Hashlock Markets is an intent-based crypto trading platform built around two ideas that DeFi has talked about for years but rarely shipped together: sealed-bid RFQ so quotes are private, and HTLC atomic settlement so cross-chain trades complete or revert as a unit, with no escrow in the middle. Sitting in front of both is a Model Context Protocol (MCP) server, which means any MCP-capable AI agent — Claude, GPT, a custom runtime — can drive the entire trading lifecycle without a human at the console.

This post is the short, practical version: how to set that up, what each piece does, and the specific tool calls an agent will make in a normal trade.

If you want the protocol home page, it lives at hashlock.markets. The canonical repository is github.com/Hashlock-Tech/hashlock-mcp.

Step 1: pick a transport

There are two ways to connect an agent to the Hashlock MCP server.

stdio (local). Your agent spawns the server as a child process. Configure it like any other MCP server in your client of choice:

{
  "mcpServers": {
    "hashlock": {
      "command": "npx",
      "args": ["-y", "@hashlock-tech/mcp"]
    }
  }
}

This is the fastest option for development. The package auto-installs from npm, the scoped name is @hashlock-tech/mcp, and you don't have to worry about hosting anything.

Streamable HTTP (hosted). Point your agent at:

https://hashlock.markets/mcp

This is the right choice for any agent runtime that can speak Streamable HTTP MCP — including Claude in Chrome, custom orchestrators, hosted platforms, and anything that doesn't have a friendly relationship with spawning local processes. One URL, no install.

Both transports expose the same six tools described below, with the same semantics. Pick whichever fits your deployment.

Step 2: sign in with Ethereum

Authentication is SIWE — Sign-In with Ethereum. No passwords, no API keys to leak in a .env file, no long-lived bearer tokens.

The flow is the standard SIWE handshake:

The agent requests a nonce from the server.
The server returns a SIWE message containing the nonce, the domain, and an issued-at timestamp.
The agent signs the message with the wallet you've delegated to it.
The agent submits the signature; the server verifies it on-chain and opens a session.

A few practical implications worth being explicit about:

The agent never holds a long-lived secret. It holds a key. You can revoke access by rotating the key.
You can scope the wallet. Most operators give the agent a dedicated trading wallet rather than handing it the keys to their main treasury. Funded with a per-day budget, an agent with a scoped wallet has a hard ceiling on what it can do, and you can audit every action by following the on-chain footprint.
Sessions are per-wallet, not per-agent-runtime. If you swap from Claude to a different MCP client tomorrow, the same SIWE auth works as long as the same wallet signs.

If you're building this into a product, the SIWE flow takes about a screen of code per agent runtime. The MCP server handles the protocol details on the server side.

Step 3: understand the six tools

Once you're connected and authenticated, the agent has six tools available. They map cleanly onto the trading lifecycle.

RFQ (Request for Quote)

Tool	What it does
`create_rfq`	Declare an intent: "I want to swap X token for Y token, this size, on these chains."
`respond_rfq`	Used by market makers to submit a sealed bid against an RFQ.

create_rfq is the trader's entry point. Calling it broadcasts the intent privately to the network of market makers connected to Hashlock. Each market maker sees the request, prices it, and submits a quote with respond_rfq. No market maker sees a competitor's price. That's the "sealed-bid" part: the auction window stays private until the trader picks a winner.

This matters for two reasons. First, market makers can quote tighter, because they aren't worried about being copied or undercut by a faster competitor reading the same public order book. Second, the trader's intent doesn't leak into the public mempool, so there's no front-running and no MEV tax on the fill.

HTLC (Hash Time-Locked Contract) settlement

Tool	What it does
`create_htlc`	Lock the trader's side of the trade in an on-chain HTLC against a hash.
`get_htlc`	Read HTLC state — pending, claimed, refunded — across chains.
`withdraw_htlc`	Claim the counterparty's locked funds by revealing the preimage.
`refund_htlc`	Reclaim your own funds if the counterparty doesn't complete in time.

The atomic settlement guarantee falls out of the HTLC math. Both sides lock funds against the same hash. The first party to reveal the preimage to claim their counterparty's funds also publishes that preimage on-chain, which the other party can then use to claim their counterparty's funds. Either both legs of the swap complete, or both legs refund after the timeout. There is no state where one side has been paid and the other hasn't.

For an agent that's running unattended, the practical version of this is: failed steps are safe. A network error during withdraw_htlc doesn't leave the trader exposed — they can retry, and if they don't, the timeout triggers refund_htlc. An agent built on this primitive can be aggressive about retries without putting capital at risk.

Step 4: a normal trade, end to end

Here's the call sequence an agent makes to swap, say, ETH on Ethereum for SUI on Sui:

create_rfq with {from: "ETH", to: "SUI", amount, fromChain: "ethereum", toChain: "sui"}. The server returns an RFQ ID and starts the auction window.
Wait for respond_rfq quotes. Market makers submit sealed bids. The agent collects them, picks the best price (or applies whatever selection logic you've taught it), and accepts.
create_htlc on the source chain. The agent locks the ETH against the hash that the winning market maker will need to claim.
The market maker locks SUI on the destination chain against the same hash.
get_htlc to verify both legs are funded.
withdraw_htlc on the destination chain, revealing the preimage. The market maker watches the preimage hit the chain, then uses it to claim the ETH.
get_htlc again to confirm both legs are claimed. Trade is done.

If anything stalls — market maker disappears between steps 4 and 6, or a chain congests past the timeout — the agent calls refund_htlc and recovers its locked funds. No loss, no support ticket.

The whole sequence is six tool calls in the happy path, and idempotent end-to-end. An agent that crashes mid-flow and restarts will not double-spend; it'll observe the existing state via get_htlc and pick up where it left off.

Step 5: example agent prompt

Here's a minimal prompt that gives an agent enough context to operate Hashlock as a tool:

You have access to the Hashlock Markets MCP server. Your job is to swap [from-asset] for [to-asset] in the size the user requested. Use create_rfq to start the auction, wait for at least three quotes via respond_rfq events, and accept the best price. Then use create_htlc to lock funds, get_htlc to verify both legs, withdraw_htlc to claim, and refund_htlc if the counterparty doesn't complete within the timeout. Surface every step's output to the user.

For Claude specifically, that prompt plus the MCP config from Step 1 is enough to start. The model already knows how to call MCP tools; you don't need a custom orchestration layer.

What you get

When the pieces are wired together, the agent's trading surface has properties that are hard to assemble out of public-orderbook DEXs:

Private quoting. No information leakage in the auction window.
Atomic settlement. Both legs complete, or both refund. Nothing in between.
No front-running, no MEV tax. The intent never hits the public mempool until it's already been priced.
Cross-chain by default. Ethereum, Bitcoin, and Sui are live today. Solana and Arbitrum are next on the integration roadmap.
Safe to retry. Idempotency on the RFQ flow plus HTLC refunds means a crash-restart loop doesn't leave money on the table.

That set of guarantees is what makes the protocol usable by software, not just humans. An AI agent doesn't need to be careful in the way a human trader has to be careful, because the failure modes are bounded by the protocol itself.

Where to go next

Two pages will cover most of what you need:

Protocol home and live UI: hashlock.markets
Canonical repo, with docs and examples: github.com/Hashlock-Tech/hashlock-mcp

If you want the npm package directly: it's on npmjs at @hashlock-tech/mcp (scoped). Don't pin a version unless you have a reason; the latest tag tracks the active release.

The next decade of DeFi is going to be operated by software, not by humans clicking in browser tabs. The infrastructure for that has to be private, atomic, and cross-chain — and exposed to agents in a way they can actually use. That's the bet behind Hashlock Markets, and the MCP server is the part of it you can plug into your agent today.

Atomic cross-chain trades, explained: a hands-on walkthrough of HTLCs

Baris Sozen — Mon, 27 Apr 2026 07:07:04 +0000

Cross-chain trading has a hard problem at its core: how do you move value between two ledgers that don't speak to each other, without either side getting cheated and without parking the funds with a third party?

The answer the industry settled on, years before "intent-based DeFi" was a phrase, is the Hash Time-Locked Contract — an HTLC. It's the primitive underneath atomic swaps, the Lightning Network, most cross-chain bridges that don't trust an oracle, and the settlement leg of Hashlock Markets.

This post walks through the HTLC mechanism end-to-end, then shows how Hashlock Markets exposes it as four MCP tools your AI agent can call directly across Ethereum, Bitcoin, and SUI.

1. The two locks

An HTLC is a smart contract (or, on Bitcoin, a script) holding funds behind two conditions:

The hashlock. The contract knows a hash H = sha256(s). The funds release to the receiver if and only if the receiver presents the 32-byte preimage s. SHA-256 is a one-way function — knowing H tells you nothing about s — so only the party who originally generated s can reveal it.

The timelock. If nobody presents s before block height (or timestamp) T, the original sender can call refund and reclaim the funds. The receiver can no longer claim after T.

That's the whole primitive. Two release paths, mutually exclusive. Either the receiver wins by revealing s, or the sender wins by waiting.

2. Why this enables atomic cross-chain swaps

Consider Alice wanting to trade ETH for BTC with Bob.

Alice generates a random secret s and computes H = sha256(s).
Alice posts an HTLC on Ethereum locking her ETH, payable to Bob upon revealing s, with timelock T_ETH.
Bob sees Alice's HTLC, copies the same H, and posts a corresponding HTLC on Bitcoin locking his BTC, payable to Alice upon revealing s, with timelock T_BTC.
Alice claims the BTC by revealing s on Bitcoin. The reveal is a public on-chain action.
Bob now reads s off the Bitcoin chain and uses it to claim the ETH on Ethereum.

Either both trades fill or both refund. There is no scenario in which one side gets the asset and the other doesn't, provided one critical condition holds:

T_BTC (the receiver's leg, claimed first) must expire BEFORE T_ETH (the sender's leg).

If Bob's BTC HTLC could expire after Alice's ETH HTLC, Alice could wait until Bob's leg refunds, then reveal s and claim the ETH leg too — taking both sides. The standard ordering — receiver-first leg expires first, sender-first leg expires later — closes that attack. This timing rule is the only non-obvious part of the protocol; everything else is just hashing and signature checks.

3. How Hashlock Markets wraps this

Hashlock Markets is an intent-based trading protocol. Traders declare what they want; market makers respond with private sealed-bid quotes; the winning quote settles on-chain. The settlement leg is HTLC-atomic across Ethereum (EVM), Bitcoin (script HTLC), and SUI (Move HTLC).

The protocol exposes six MCP tools. Two are for the pricing side (create_rfq, respond_rfq), and four are for the HTLC settlement leg:

Tool	Who calls it	What it does
`create_htlc`	Both legs	Funds the on-chain HTLC and records the lock tx hash. Called once per leg of the swap.
`withdraw_htlc`	Receiver	Claims the funds by revealing the 32-byte preimage. The reveal is public; the counterparty uses it to claim the other leg.
`refund_htlc`	Sender, post-deadline	Returns the funds to the original sender if the timelock has passed and no one withdrew.
`get_htlc`	Either side	Reads current state for both legs of a trade: contract addresses, lock amounts, timelocks, status.

The MCP layer means an AI agent — Claude Desktop, Cursor, GPT, anything that speaks the Model Context Protocol — can drive the full settlement flow with no smart-contract code on your side. The agent calls create_htlc, polls get_htlc, calls withdraw_htlc when the counterparty's leg is funded, or calls refund_htlc if the deadline passes.

4. End-to-end example: an agent settles an ETH→BTC trade

Skipping the RFQ stage (assume the trader and market maker have already agreed on a price via create_rfq and respond_rfq):

[Trader agent — wants to sell ETH for BTC]

1. create_htlc { tradeId, side: "sender", chain: "ethereum",
                 amount: "2.0", token: "ETH",
                 hash: H, timelock: T_ETH }
   → returns tx hash, contract address

2. get_htlc { tradeId }
   → polls until both legs are funded
   → confirms MM has posted the BTC leg with the same H

3. withdraw_htlc { tradeId, leg: "btc", preimage: s }
   → claims BTC by revealing s
   → s is now public on the Bitcoin chain

[MM agent — was selling BTC for ETH]

4. get_htlc { tradeId }
   → sees the BTC leg has been withdrawn, reads s from on-chain

5. withdraw_htlc { tradeId, leg: "ethereum", preimage: s }
   → claims ETH

[Settled. Both legs filled atomically.]

If at any point the MM never funds their leg, or either side disappears mid-flow, refund_htlc recovers the funds after the timelock expires. The trader's leg is set with the longer timelock per the rule above, so the safe path is always: claim what's owed to you first, then refund anything still locked.

5. Why the design choice matters

Plenty of cross-chain venues skip HTLCs and use a wrapped-asset bridge or a custodial relayer. Both work for happy-path flows, both add a trust assumption that has been the source of nine of the ten largest exploits in the space.

HTLCs trade off a little latency (you pay for the timelock window) for a very specific guarantee: at no point does any party hold the other party's asset without an enforceable reason to release it. The protocol either fills both sides or returns both sides. There's no "stuck funds" state that requires governance intervention.

That property is what lets Hashlock Markets settle across heterogeneous chains — including Bitcoin, which has no smart contracts in the EVM sense — without trusting a custodian. The same hash works on all three chains because SHA-256 is universal; the script that checks it differs (Solidity, Bitcoin Script, Move), but the cryptographic contract is identical.

6. Try it

Connect your MCP client to Hashlock Markets:

Remote (preferred): point your MCP config at https://hashlock.markets/mcp with a SIWE bearer token from hashlock.markets/sign/login.

Local stdio: run the published package via npx -y @hashlock-tech/mcp with the same token in HASHLOCK_ACCESS_TOKEN.

Either way you get the six tools. Six tools, three chains, atomic settlement.

More: https://hashlock.markets
GitHub: https://github.com/Hashlock-Tech/hashlock-mcp
npm: https://www.npmjs.com/package/@hashlock-tech/mcp

DEV Community: Baris Sozen

Forward OTC settlement for agent treasuries: T+24h trades that don't depend on trust

The dimension agent payment rails skip

How OTC desks do it today, and what's missing

Forward OTC, mechanically

Why Sui makes this primitive cleaner

The 7 bps detail

Try it

Pay.sh pays for an API call. Hashlock settles a trade. Know the difference.

Pay.sh pays for an API call. Hashlock settles a trade. Know the difference.

The week in payment standards

What "payment" means in this stack

What "settlement" means

What Hashlock Markets actually does

The honest comparison

Where this goes

The autonomous economy has four standards — and a missing layer

A funding week, by the numbers

The four standards

What all four assume — and none of them build

The missing layer

How this fits the stack

Where we are vs where the standards are

Six tools for an agent, six hundred methods for a human: why agent-shaped APIs beat SDK-shaped APIs for trading

The SDK-shaped API is a human convenience

The agent-shaped API is the smallest surface that still completes the job

What "agent-shaped" actually means in practice

The MCP spec is what makes this auditable

What you actually lose by going agent-shaped

"Six tools" is the headline. Pre-quote validation is the substrate.

Closing question

Counterparty validation in sealed-bid RFQ: the four filters before an HTLC locks in on Hashlock Markets

The flow, in one sentence

Layer 1 — counterparty KYC tier (auction-time filter)

Layer 2 — bonded reputation (per-quote filter)

Layer 3 — price-deviation guard (per-quote filter)

Layer 4 — ring privacy (auction-time, optional)

Putting it together

What this means for agent builders

A week of intent-based trading for AI agents: five threads from the Hashlock Markets desk

A week of intent-based trading for AI agents: five threads from the Hashlock Markets desk

1. Why public order books are not the right primitive for AI traders

2. One URL for any agent runtime

3. Six MCP tools, full trading lifecycle

4. Where Hashlock sits relative to the CEX-MCP wave

5. Wire Claude in ten minutes

What's coming next

The 6 MCP tools in Hashlock Markets — what each one does and when an agent calls it

Two halves of the surface

The two RFQ tools

create_rfq — post a sealed-bid intent

respond_rfq — quote against an open RFQ

The four HTLC tools

create_htlc — lock funds under a hashlock and a timelock

withdraw_htlc — claim with the secret preimage

refund_htlc — reclaim if the counterparty disappears past the timelock

get_htlc — inspect an in-flight swap

A typical trade is four calls per side

Why this surface and not a bigger one

Two ways to wire it up

When evaluators ask "is this enough?"

Single-venue CEX-MCPs vs Hashlock Markets: where the lines actually break

The shape of a single-venue CEX-MCP

Workload 1: cross-venue price discovery without leaking the order

Workload 2: cross-chain settlement without bridges

Workload 3: two AI agents trading directly

When the single-venue shape is the right answer

Connecting an agent to Hashlock Markets

The category direction

One URL for any agent runtime: the hosted Hashlock MCP endpoint

One URL for any agent runtime: the hosted Hashlock MCP endpoint

Why a hosted endpoint matters

What the endpoint is, technically

When to pick which transport

What it doesn't change

A small but important practical note

Where to start

Public order books were built for humans. AI traders need a different market structure.

Public order books were built for humans. AI traders need a different market structure.

The features of public order books are bugs for agents

`create_rfq` — post a sealed-bid intent

`respond_rfq` — quote against an open RFQ

`create_htlc` — lock funds under a hashlock and a timelock

`withdraw_htlc` — claim with the secret preimage

`refund_htlc` — reclaim if the counterparty disappears past the timelock

`get_htlc` — inspect an in-flight swap