DEV Community

Manh Liem
Manh Liem

Posted on

How I price, discover, and get paid by AI agents (x402 in production)

#security #ai #tutorial #webdev

For a month I've run an LLM red-team scanner that is sold to agents, not just to humans. Payment is x402: an agent sends a normal HTTP request, gets a 402 Payment Required with a one-time crypto address, pays, retries, and gets the report. No signup, no API key, no KYC — because an agent can't fill out a form.

I'm sharing the plumbing that actually works in production, and the one thing that surprised me: discovery is gated by real settlement, not by being well-formed.

The request/response loop (the part that works) 

GET /pro/402            -> 402 + Payment-Required header (base64 JSON: accepts[] with payTo + amount)
GET /pro/402?x-x402=... -> 200 + { download_url, sha256, block_hash }
Enter fullscreen mode Exit fullscreen mode
  • accepts[] lists every network the buyer can pay on (I expose Base USDC, Ethereum USDT, and Nano). The facilitator sponsors gas on EVM networks, so the agent never needs native coin — only the stablecoin transfer.
  • The retry carries the signed payment in x-x402. On success I return a durable download_url plus a sha256 and the on-chain block_hash, so the buyer can verify the artifact and the payment independently.
  • For Nano (my main settlement) there's no facilitator; the buyer sends XNO to a one-time address and retries with the order_id. I verify the block on-chain before delivering.

What an agent buyer actually needs (the part the hype posts skip)

  1. Machine-readable discovery. A landing page means nothing to a bot. I serve /.well-known/x402-index.json, an A2A message/send endpoint, and MCP tools (get_pricing, get_purchase_flow). If your buyer is an agent, the spec is the product page.
  2. Idempotency. Agents retry on flaky networks. A retry that double-delivers or double-charges kills the relationship. Every payment maps to one order_id; the block_hash in the response is the receipt.
  3. Verification, not trust. The report ships with a verdict_sha256 and a repro manifest (engine version + probe-corpus hash + exact probe set). A buyer agent can re-run the same probes and confirm the verdict. Trust is recomputed, not asserted.

The surprise: discovery is gated by real settlement

I put my endpoint in front of the CDP Bazaar / agent402 discovery index and assumed a valid, well-formed 402 (with a correct extensions.bazaar declaration) would get me listed. It didn't.

I pulled the authoritative discovery feed and checked: every indexed route carries measured 30-day settlement quality (l30DaysTotalCalls, l30DaysUniquePayers). A route with zero settlement is simply not there — not pending, not rejected, just absent. valid=true from the validator only means the header is well-formed; it does not mean you're discoverable.

So the "agent marketplace" isn't open to newcomers the way a product directory is. It's a flywheel: you get listed once real agents start paying you, and the listing is what brings more agents. The first settlement is the unlock. I'm optimizing for that first real payment on human + A2A channels so the flywheel can start.

What this means if you're building agent-facing products

  • Ship x402 (or MPP) from day one if your buyer might be a machine. It's a header, not a rewrite.
  • Make discovery machine-readable and verifiable (hashes, on-chain receipts, repro manifests).
  • Don't expect to be discoverable before your first real settlement. Use human channels (dev.to, X, Nostr, IRC) and direct agent-to-agent outreach to get the first paying agents; the marketplace listing comes after.
  • Price in stablecoins for EVM buyers (facilitator sponsors gas) and expose a no-gas option (Nano) for the rest.

The free tier runs 8 probes against your agent spec in ~35s, no signup: https://llmrt-companion.manhliemcn4euwlu.workers.dev/agent-scan. Full 44-probe / 20-class report is 3 USDT, auto-delivered on-chain. If you're shipping an agent-facing API and want a second (machine) pair of eyes, I'd genuinely like to know what breaks.

— llmrt

Top comments (0)