A week of intent-based trading for AI agents: five threads from the Hashlock Markets desk
Update, October 2026. This post was first published in May 2026. It has been revised to match the product as it is live today: six mainnet chains (Bitcoin, Ethereum, TRON, Solana, Base, Robinhood Chain), API key authentication, and the current MCP tool set. Current reference: https://docs.hashlock.markets
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 RFQ for price discovery: takers post a request, market makers respond with sealed quotes, the two sides negotiate in a private thread and agree. HTLC for settlement: both legs lock against the same sha256 hashlock, the initiator reveals the 32-byte secret by claiming, and the counterparty uses it to claim the other leg. Either the trade settles or both legs refund after their timelocks (24 hours on Bitcoin, 4 hours elsewhere; the initiator funds the long leg).
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, ChatGPT, Cursor, a custom Python client: same endpoint, same tool set, same auth flow. The client is sent to Hashlock to approve with a wallet signature and receives its own API key over OAuth 2.1; clients that do not speak OAuth send Authorization: Bearer hk_live_... (keys expire after 90 days).
The npm package @hashlock-tech/mcp (npx -y @hashlock-tech/mcp, with HASHLOCK_API_URL and your chain keys in the environment) is still the right path for stdio deployments where the agent should sign and settle without a human in the loop. Both paths are first-class.
3. One tool set, full trading lifecycle
The hosted server exposes 24 tools covering the whole loop:
-
Discovery:
whoami,list_assets,list_open_rfqs,get_rfq -
Taker side:
create_rfq,cancel_rfq,list_my_rfqs,request_listing -
Maker side:
quote_rfq,list_rfq_threads,get_thread -
Negotiation:
propose_price,accept_proposal,accept_terms -
Settlement:
set_swap_address,build_fund,build_claim,build_refund,broadcast_tx,swap_status,list_swaps -
Wallet proofs:
wallet_proof_message,prove_wallet,remove_wallet_proof
The local stdio server has 17 tools of the same shape (create_rfq, respond_to_rfq, negotiate, fund_leg, claim_leg, refund_leg and so on) and can sign with the keys in its environment.
There is no SDK to import, no fifty-method client class to pin to a major version, no separate auth library. An API key handles authentication, the MCP server handles the rest. An agent that can call these tools has the full Hashlock Markets surface.
The scope is deliberate. Tool surfaces grow 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 RFQ. Settlement is non-custodial: the protocol never holds either side of the trade. Cross-chain is native: an agent can swap ETH on Ethereum for BTC on Bitcoin 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. Add https://hashlock.markets/mcp to your MCP client, approve with a wallet signature when prompted, give the agent a prompt that describes a trade in natural language, and watch it walk through create_rfq, quote_rfq or propose_price, accept_terms, build_fund and build_claim. Cross-chain swap, atomic settlement, nothing manual beyond signing what the server hands back.
That ten-minute path is the intended entry point. The argument for intent-based trading is more compelling once you have watched an agent execute one.
What's coming next
Three things worth flagging.
First, chains. Bitcoin, Ethereum, TRON, Solana, Base and Robinhood Chain are live on mainnet, and one sha256 hashlock on every chain lets a single intent route across any pair of them.
Second, the differentiation. The "AI agent trading MCP" category is crowded enough that a structured comparison (sealed versus public quote, atomic versus custodial, cross-chain versus single-venue) earns its keep. Expect us to keep making that case in the open.
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 and docs.hashlock.markets.
What's your current MCP trading runtime setup, and what is breaking?
Top comments (1)
no comment from anyone?