Most writing about agent commerce stays at the layer-diagram altitude: rails here, settlement there, trust boundaries in between. Useful, but abstract. Today let's go to ground level and walk through what actually happens - call by call - when an AI agent trades with a stranger and no custodian is anywhere in the loop.
The whole lifecycle fits in six MCP tools. Any MCP-capable model can drive them; there's no SDK to integrate and no signing service to trust. The package is hashlock-tech/mcp (scoped) on npm, and everything below runs end-to-end on Ethereum mainnet today.
Phase 1: Price discovery - three tools
create_rfq is where a trade starts. The taker's agent broadcasts a request-for-quote: pair, size, direction, expiry. The important design decision is that the RFQ is sealed-bid - responding makers can't see each other's quotes. For human OTC desks that's a nicety. For agents it's load-bearing: an autonomous maker that can observe competing quotes will shade its price against them in milliseconds, every time, forever. Sealed bids force every maker to quote their true price.
list_open_rfqs is the maker side of discovery. A market-making agent polls open RFQs, filters by pair and size, and decides what to quote. This is the tool that turns a settlement protocol into a two-sided market - flow has to be findable.
respond_rfq submits the quote. The taker's agent collects responses until expiry, picks the best one, and moves to settlement. Notice what has not happened yet: no funds have moved, no approvals granted, no counterparty trusted. Price discovery is informationally rich and financially inert - exactly the property you want before an unattended agent commits capital.
Phase 2: Settlement - two tools, one secret
create_htlc locks the first leg. The taker commits funds into a hash-time-locked contract: a hashlock (only the holder of a secret preimage can claim) plus a timelock (after the window, the funds refund to sender). Committed, not transferred. The maker then locks the mirror leg on the other chain against the same hash.
withdraw_htlc is the claim. When the taker withdraws the maker's leg, the act of claiming reveals the preimage on-chain - which is precisely what the maker needs to claim the taker's leg. One secret clears both legs. There is no state of the world where one side has both assets and the other has neither. That's what "atomic" means when it isn't a marketing word: not "fast," not "a solver front-paid and will reconcile later" - a cryptographic guarantee that the trade completes on both legs or on neither.
No judge decides the trade is complete. Completion is the reveal of the secret. Compare that with escrow-and-evaluator designs, where a third party rules on whether obligations were met - a human institution rebuilt in Solidity.
Phase 3: The unwind - the tool nobody advertises
refund_htlc is the sixth tool and, for autonomous operation, the most important one. If the window lapses - the counterparty vanished, the quote went stale, the agent crashed mid-flow - the timelock returns the funds. Nobody to petition, no support ticket, no dispute process. The failure mode of the entire system is "you get your money back."
That property is worth dwelling on, because it's the difference between a protocol you can demo and a protocol you can leave running. An unattended agent will eventually hit every failure mode that exists. If any of those failure modes is "funds are stuck pending a human decision," you don't have autonomous settlement - you have supervised settlement with extra steps.
The forward extension
Here's where the primitive gets more interesting than a spot swap. Nothing in the HTLC construction says the settlement window must be now. Stretch the timelock and the same six calls bind a forward: two agents agree a price today, both legs commit today, and the claim window opens at T+24h (or T+7d). Between agreement and settlement, no custodian holds margin, no clearinghouse guarantees performance, no credit desk evaluates counterparty risk. If both sides show up, one preimage clears both legs. If one side no-shows, the other's refund path executes.
This is the gap payment rails don't address. x402, AP2, AWS's new AgentCore Payments preview - these move one known asset, one direction, right now, and they're getting genuinely good at it. But a rail cannot bind a two-sided, cross-asset obligation that settles later. That takes a settlement primitive, and the rails will eventually need one underneath them.
Where this runs today
Chain-claim honesty, because the agent economy has enough overclaiming already: Ethereum mainnet is live end-to-end - everything in this walkthrough works there now. Sui contracts are deployed and CLI-tested, with gateway wiring in progress. Bitcoin is validated on signet, mainnet pending. The protocol design is documented in our SSRN paper (https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722) for those who want the formal treatment.
Docs and the full tool reference: https://hashlock.markets/docs?utm_source=devto&utm_medium=article&utm_campaign=2026-07-03-forward-tool-walkthrough - GitHub: https://github.com/Hashlock-Tech/hashlock-mcp
Here's the question I keep coming back to: of the six tools, five get all the attention, but refund_htlc does the work that makes unattended operation possible. If you're building agents that touch value - what does your stack's failure mode look like? Stuck funds and a ticket queue, or a timelock that hands the money back?
Top comments (0)