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 an intent-based crypto trading protocol. 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:
- Reads context,
- Decides what it wants to happen,
- Picks a tool that expresses that, and
- 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 bids produce"). The protocol — solvers, market makers, routers — does the optimization. The agent's job shrinks to something it's actually good at.
2. Sealed-bid RFQ shrinks the reasoning surface
One of the underappreciated properties of sealed-bid 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-bid RFQ, that whole surface collapses. The agent opens an RFQ. Market makers see a size and a pair. They submit sealed quotes. The agent accepts the best one. 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 timelock expires 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 Hashlock Markets' tool surface:
-
create_htlc— record the on-chain lock transaction after you fund -
withdraw_htlc— claim the counterparty's side by revealing the 32-byte preimage -
refund_htlc— reclaim your funds if the counterparty never funded -
get_htlc— query the status of both sides
Four tools, three terminal states. That's a small enough state machine that you can write exhaustive tests against the agent's behavior.
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 — the fact that 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 six tools — create_rfq, respond_rfq, create_htlc, withdraw_htlc, refund_htlc, get_htlc — that work identically across Ethereum (EVM), Bitcoin (wrapped HTLC), and Sui (Move HTLC). The implementations differ wildly underneath. The tool surface does not.
For an agent, that matters because:
- Prompt engineering scales linearly with tool count. Six tools is manageable. Eighteen is not.
- Cross-chain failure modes converge. A failed HTLC on Sui and a failed HTLC on Ethereum look the same to the agent.
- New chains can be added behind the same vocabulary (Solana and Arbitrum are on the roadmap) without the agent needing to relearn anything.
5. Authentication: SIWE is the right pattern for this class of protocol
This one is quick but it matters. Hashlock Markets uses Sign-In With Ethereum (SIWE) for auth: the user signs a message with their wallet, gets a 7-day JWT, and the agent uses that as a bearer token. No password stored in agent configs. No custodial account. No API key rotation ritual.
For agent-native protocols, this is the only auth shape that makes sense. The agent never holds the signing key — the user does. The agent only holds a scoped, expiring bearer token that authorizes specific tool calls.
So what does an agent-native DeFi protocol look like?
Pulling the threads together, the agent-native shape has four properties:
- Declarative rather than imperative. The agent expresses endpoint state, not a control loop.
- Sealed / private by default. Minimize the information surface the agent has to reason about.
- Atomic settlement. Binary terminal states over partial / ambiguous ones.
- 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 tool surface is small enough that you can hold the whole thing in your head. Six tools, three chains, SIWE auth, atomic settlement — that's roughly the minimum viable vocabulary for "let the agent trade."
Links
- Hashlock Markets: hashlock.markets
- MCP endpoint: hashlock.markets/mcp
- SIWE login: hashlock.markets/sign/login
- Canonical repo: github.com/Hashlock-Tech/hashlock-mcp
- npm:
@hashlock-tech/mcp - MCP Registry:
io.github.Hashlock-Tech/hashlock
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.
Top comments (0)