Why Intent-Based Trading Is the Natural Protocol Shape for AI Agents

Declarative intents, sealed RFQ, atomic HTLC settlement, and one tool vocabulary across six chains.

Update, October 2026. This post was first published in April 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 AI-agent-meets-DeFi conversation tends to skip a basic question: what shape of protocol actually suits an agent? Not every DeFi primitive is equally agent-native. Orderbook-style venues, perpetual DEXes, liquidity manager vaults: each has a different interaction model, and some of them line up very poorly with how an LLM agent actually reasons.

This post argues that intent-based trading, where the user (or agent) declares what should happen and the protocol figures out how, is the shape of protocol that lines up most cleanly with agent execution. Hashlock Markets is a useful reference implementation, so I'll use it to make the point concrete.

Housekeeping note up front: Hashlock Markets (hashlock.markets) by Hashlock-Tech is a non-custodial atomic P2P cross-chain swap protocol built on sealed RFQ and HTLCs. It is not affiliated with Hashlock Pty Ltd (hashlock.com), an independent Australian smart contract auditing firm. Similar name, separate organization.

1. Agents are good at intent. They're weaker at tight feedback loops.

An LLM agent is essentially a policy that:

1. Reads context,
2. Decides what it wants to happen,
3. Picks a tool that expresses that, and
4. Submits a single call.

That shape is a great fit for "I want to sell 2 ETH for USDT at the best available price," because the model can emit that as a single typed call. It is a much worse fit for "maintain a live limit order, reprice every 300ms as the top-of-book moves, cancel and requote if depth evaporates, watch for partial fills." That second shape is a control loop, not a language problem. A dedicated execution algo does it better than an LLM will.

Intent-based trading takes the control loop out of the agent's job. The agent expresses the endpoint state ("I want to be out of 2 ETH, paid in USDT, at the best price sealed quotes produce"). The protocol, and the market makers competing inside it, do the optimization. The agent's job shrinks to something it's actually good at.

2. Sealed RFQ shrinks the reasoning surface

One of the underappreciated properties of sealed RFQ for agent execution is how much state it removes from the agent.

With an orderbook, an agent that wants to execute well has to reason about:

• Current best bid/ask and depth
• Whether its order will move the book
• Whether other participants will front-run its intent if it posts on-chain
• Slippage tolerance, partial fill risk, adverse selection

With a sealed RFQ, that whole surface collapses. The agent opens an RFQ with create_rfq. Market makers see a size and a pair. They answer with sealed quotes, each one opening a private negotiation thread. The agent reads the threads with list_rfq_threads, takes the best terms with accept_proposal or accept_terms, and is done. There is no public orderbook to infer from, nothing for adversaries to front-run, no slippage tolerance parameter to tune. Clean input, clean output.

This isn't only a security win against MEV. It's an agent design win. A smaller reasoning surface means fewer places the agent can be wrong.

3. Atomic settlement gives agents a binary state machine

The other property that matters for agents is how settlement behaves under failure. Agents handle binary state machines much better than they handle partial, ambiguous outcomes.

Hash Time-Locked Contracts (HTLCs) give you exactly that. Both sides fund. Either the preimage is revealed and both claims succeed, or the timelocks expire and both sides refund. There is no "trade executed at 82% of the intended size," no "your swap went through but your slippage check failed halfway," no custodian holding funds in between. An agent that can reason about {funded, claimed, refunded} is already most of the way to a correct implementation.

The practical shape in the hosted Hashlock Markets MCP server:

• build_fund builds the unsigned funding transaction for the leg you give
• build_claim builds the claim that reveals the 32-byte secret (the hashlock is its sha256)
• build_refund builds the refund, valid once your leg's timelock has passed
• swap_status returns both legs, their timelocks, addresses and transaction hashes

Four settlement tools, three terminal states. That's a small enough state machine that you can write exhaustive tests against the agent's behavior. The local server mirrors it with fund_leg, claim_leg, refund_leg and deal_status.

The timelocks are asymmetric: the initiator, who holds the secret, funds the long leg (24 hours on Bitcoin, 4 hours elsewhere), so the counterparty always has time to claim once the secret is public.

4. One vocabulary across chains matters more than you'd think

Cross-chain is usually discussed in terms of bridge risk, liquidity fragmentation, or UX. For agents specifically, the biggest cost of multi-chain execution is vocabulary drift: every chain exposes its primitives slightly differently, so the agent has to learn N different tool surfaces that do the same thing.

Hashlock Markets' MCP server collapses that into one tool set that works identically across Bitcoin (P2WSH script), Ethereum, Base and Robinhood Chain (EVM contracts), TRON and Solana. The implementations differ wildly underneath. The tool surface does not: one sha256 hashlock, one 32-byte secret, the same build_fund, build_claim, build_refund on every chain.

For an agent, that matters because:

• Prompt engineering scales with the number of distinct vocabularies, not the number of chains. One settlement vocabulary for six chains is manageable. Six chain-specific ones are not.
• Cross-chain failure modes converge. A refunded leg on Solana and a refunded leg on Ethereum look the same to the agent.
• A new chain lands behind the same vocabulary. Base and Robinhood Chain were added without the agent needing to relearn anything.

5. Authentication: wallet signatures and scoped keys are the right pattern

This one is quick but it matters. The hosted Hashlock Markets MCP server authenticates over OAuth 2.1: the client is sent to Hashlock, the user approves with a signature from their wallet, and the client receives its own API key, valid for 90 days and revocable from the Developers page. Clients that don't speak OAuth send a key you minted yourself: Authorization: Bearer hk_live_.... No password in agent configs. No custodial account.

For agent-native protocols, this is the right auth shape. In the hosted mode the server never holds the signing key; whoever owns the wallet, the user or the agent itself, signs the unsigned transactions the server returns. The agent only holds a scoped, expiring API key that authorizes specific tool calls. An autonomous agent that holds its own keys either runs the local server, which logs in with those keys by itself, or mints an API key with a wallet signature alone (GET /v1/keys/nonce, then POST /v1/keys) and uses the hosted server or REST, no browser or email needed.

So what does an agent-native DeFi protocol look like?

Pulling the threads together, the agent-native shape has four properties:

1. Declarative rather than imperative. The agent expresses endpoint state, not a control loop.
2. Sealed / private by default. Minimize the information surface the agent has to reason about.
3. Atomic settlement. Binary terminal states over partial / ambiguous ones.
4. One vocabulary across chains. Consistent typed tool surface, regardless of what's underneath.

Hashlock Markets happens to implement all four. It isn't the only protocol that could; intent-based architectures are a growing category. But it's a useful reference because the settlement surface is small enough that you can hold the whole thing in your head. Four settlement tools, six chains, wallet-signed keys, atomic settlement: that's roughly the minimum viable vocabulary for "let the agent trade."

Links

• Hashlock Markets: hashlock.markets
• Docs: docs.hashlock.markets
• MCP endpoint: https://hashlock.markets/mcp
• Canonical repo: github.com/Hashlock-Tech/hashlock-mcp
• npm: @hashlock-tech/mcp

---

Reminder: Hashlock Markets (hashlock.markets) is the Hashlock-Tech trading protocol described here. It is not affiliated with Hashlock Pty Ltd (hashlock.com), an independent Australian smart contract auditing firm.