Intent-based trading fits AI agents better than orderbooks
Baris Sozen argues that intent-based trading protocols — where an agent declares a desired outcome and the protocol handles execution — are a natural fit for LLM agents, using Hashlock Markets as a concrete reference implementation.
Score breakdown
Developers building AI agents for DeFi should evaluate intent-based protocols and HTLC-based settlement as a design pattern that minimizes agent reasoning surface, eliminates MEV exposure, and enables exhaustive state-machine testing across multiple chains with a single unified tool vocabulary.
- 01Author Baris Sozen argues intent-based trading — where the agent declares an outcome and the protocol handles execution — is the most agent-native DeFi protocol shape.
- 02LLM agents are well-suited to single-call, endpoint-state declarations but poorly suited to continuous control loops like live orderbook repricing.
- 03Sealed-bid RFQ eliminates the need for agents to reason about orderbook depth, front-running risk, and slippage tolerance.
Baris Sozen's post makes the case that the protocol shape of intent-based trading aligns naturally with how LLM agents operate. An LLM agent reads context, decides what it wants to happen, picks a tool, and submits a single call — a pattern that maps cleanly onto "I want to sell 2 ETH for USDT at the best available price," but maps poorly onto maintaining a live limit order with continuous repricing, cancel-and-requote logic, and partial fill monitoring. That second pattern is a control loop, not a language problem, and Sozen argues a dedicated execution algo will always outperform an LLM there. Intent-based protocols remove the control loop from the agent's responsibilities entirely.
Sozen uses Hashlock Markets as a reference implementation to make the argument concrete.
Sozen uses Hashlock Markets as a reference implementation to make the argument concrete. Its sealed-bid RFQ mechanism collapses the agent's reasoning surface: instead of reasoning about orderbook depth, front-running risk, and slippage tolerance, the agent opens an RFQ, market makers submit sealed quotes, and the agent accepts the best one. Settlement is handled via Hash Time-Locked Contracts (HTLCs), which produce exactly three terminal states — `funded`, `claimed`, `refunded` — enabling exhaustive behavioral testing. The MCP server exposes just 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), with Solana and Arbitrum on the roadmap.
The cross-chain vocabulary unification is highlighted as a key agent-design win: prompt engineering scales linearly with tool count, so six unified tools is manageable where eighteen chain-specific variants would not be. Cross-chain failure modes also converge — a failed HTLC on Sui and a failed HTLC on Ethereum look identical to the agent. Authentication uses Sign-In With Ethereum (SIWE), where the user signs a message with their wallet to receive a 7-day JWT used as a bearer token by the agent.
Key facts
- 01Author Baris Sozen argues intent-based trading — where the agent declares an outcome and the protocol handles execution — is the most agent-native DeFi protocol shape.
- 02LLM agents are well-suited to single-call, endpoint-state declarations but poorly suited to continuous control loops like live orderbook repricing.
- 03Sealed-bid RFQ eliminates the need for agents to reason about orderbook depth, front-running risk, and slippage tolerance.
- 04Hash Time-Locked Contracts (HTLCs) provide three clean terminal states — funded, claimed, refunded — enabling exhaustive agent behavior testing.