If your trading agent asks for a price out loud, it has already paid for it

#mcp #ai #cryptocurrency #blockchain

This is a short, practical one — a Saturday tip rather than a deep dive. But it's a mistake I keep seeing in agent trading code, and it's worth thirty seconds of your attention.

Here it is: the moment your agent asks for a price, it has already given something away.

The naive quote flow

Picture a trading agent that wants to sell 10 ETH for BTC. To find a price, the obvious move is to ask around. Broadcast the intent to an open order book, ping a list of market makers, drop it into a public mempool-adjacent venue. Collect the quotes that come back, pick the best one, trade.

That feels like comparison shopping. It is not. It is publishing.

A quote request is not a neutral question. It carries direction (you're a seller), size (10 ETH), and — by the fact that you're asking right now — urgency. Anyone who sees the request before you trade is reading your hand.

Three ways that leak costs you

Once your intent is visible, three things happen, and none of them are in your favour.

Front-running. A faster party sees "seller of 10 ETH incoming" and trades ahead of you, moving the price into the spot you were about to take. You arrive late at your own trade.

Quote shading. Market makers who can see that you're a committed seller — and can see what their competitors are showing — quietly widen their quotes. You're not getting their best price. You're getting the worst price they think you'll still accept.

Last look. This is the quiet one. A maker shows you an attractive quote, you commit to it, and then — in the moment between your commitment and settlement — the maker re-prices or simply declines. "Sorry, the market moved." The optionality was theirs the whole time. You carried the risk; they kept the exit.

Your agent thinks it ran a competitive auction. What it actually did was advertise its position and then hand counterparties a free option on it.

What a sealed-bid RFQ changes

A sealed-bid request-for-quote flips the information asymmetry back.

The agent posts an RFQ. Makers submit bids — but the bids are sealed: each maker prices the request without seeing the other makers' bids, and without seeing any reaction from the taker. There is no live book to shade against, no competitor's number to undercut by a hair, no read on how badly you want the fill.

When the bidding window closes, the taker sees the bids and picks the best one. Crucially, the maker who quoted has committed to that price. There is no "let me look again" — because the next thing that happens is settlement, not a renegotiation.

That's the pre-trade half. The post-commit half is where atomic settlement matters.

Sealed bid plus atomic settlement — why both

A sealed bid removes the pre-trade leak: nobody shades or front-runs a request they can't read.

Atomic settlement removes the post-commit leak: last look only exists because there's a gap between "agreed" and "settled" where one side still holds an option. Close that gap and the option disappears.

Hashlock fuses the two into one operation. The RFQ and the settlement are not separate steps a counterparty can wedge themselves between. The winning bid settles through a hashed-timelock contract (HTLC): either both legs of the swap complete, or both sides refund. There is no state in which the maker has re-priced, walked, or kept your asset. The deadline is enforced by the chain, not by anyone's good intentions.

For an agent, the whole thing is a few tool calls over MCP — the open protocol Anthropic introduced for connecting models to external systems. The MCP server exposes six tools; the RFQ path is create_rfq to post the request, list_open_rfqs to see what's live, respond_rfq for makers to submit a sealed bid, and the swap tools to settle the winner. Your agent doesn't manage timelocks or watch the chain — it calls a tool and gets an atomic outcome.

The honest limits

A sealed-bid RFQ is not an invisibility cloak. It protects the quote phase — the window where your intent would otherwise be readable and exploitable. Once a trade settles on-chain, the settlement transaction is public, like any other; sealed bidding doesn't and can't hide a completed trade. What it removes is the free option that counterparties get when they can see your hand before you've traded.

And the usual chain-status caveat, because we keep this honest: atomic settlement is live end-to-end on Ethereum mainnet today. Sui contracts are deployed and CLI-tested with gateway wiring in progress; the Bitcoin P2WSH HTLC is validated on signet with mainnet still pending. When this post says "live," it means Ethereum mainnet.

The takeaway

If you're building a trading agent, treat the quote request as part of the trade, not as a free lookup before it. The cheapest spread in the world doesn't help if getting to it leaked your position to everyone who could act on it.

So here's the question I'd genuinely like builders to sit with: if shopping for a price is itself a leak, how much of what we call "best execution" was ever really best — and how much was just the least-bad price we could get after tipping our hand?

Hashlock Markets — atomic settlement for the agent economy. Sealed-bid RFQ + HTLC settlement, fused into one operation. No bridges, no custodians.