# I built a machine-payable API for AI agents and made $0.00 from strangers. Here's every number. > Source: > Published: 2026-07-23 19:20:43+00:00 Over a few weeks I built and shipped a small x402 service on Base: **token-risk.com**, a pay-per-call API that returns deterministic structural risk reports for ERC-20 tokens and wallet addresses. Agents pay $0.01 in USDC per call — no signup, no API key. It's live, it settles real money on-chain, and it's indexed in the discovery layer AI agents actually read. This is the honest write-up. Every number here is real, including the zeros. The settlement transactions are on Base and linked so you can verify them yourself. I pre-committed my stop criteria before writing this: eight weeks from launch; if external paid calls stay at zero, I stop spending time on it. As of today, on x402scan: And the number that matters most: **external buyers — zero.** Both buyer addresses are mine. One is a test client I use to verify the payment loop; the other is an AgentCash wallet I funded to run discovery experiments. I keep a small ledger file of every address I control, specifically so I can subtract myself when reading my own stats — in an ecosystem where a large share of "volume" is wash traffic, I'd rather show you a self-audited zero than an unqualified two. Every cent of that $0.15 is me paying myself — it literally moved from one of my wallets to another. So why write this? Because the *building* worked, the *selling* is unproven, and the gap between those two is the whole story — and I think it's a story a lot of people shipping into this ecosystem right now are living without saying it out loud. The API passed every unit test, every typecheck, every container smoke test — and still failed the first time a real third-party client tried to pay. Twice, for different reasons. **Incident 1: the description that was too long.** I'd enriched the service metadata to make it more discoverable — richer descriptions, clearer schemas. The richer description pushed a string from 55 characters to 717–756, past the 500-character hard limit the payment facilitator enforces on the payment requirements. Nothing crashed. No test went red. The facilitator just silently rejected every payment, because the constraint lives on the provider's side, where I had no test watching. I found the exact length overflow, fixed it with a boot-time length guard in the payment template, and confirmed the fix with a real paid settlement on Base (tx `0xf3d2504961...481b8e08` ). No future endpoint of mine can repeat it — the guard lives in the template every endpoint is built from. **Incident 2: a failure window I never fully explained.** Later, one route started failing again in a narrow time window. Here's the honest version: by the time I went looking, the server logs for that exact window had already rotated out — so I could form a leading hypothesis but I could never *prove* the root cause. I don't know for certain what caused those specific failures, and I'm not going to pretend I do. What I did fix, separately, was a real issue I found while investigating: my resource URL was advertised as `http://` after TLS termination at the edge, and the CDP discovery layer was rejecting it with a specific reason: *"resource must start with 'https://' when protocol type is http."* I fixed it by pinning an explicit public origin (HTTPS required on mainnet, no fallback), and the service showed up in the CDP Bazaar catalog shortly after the next settlement — "shortly" here is an observation from two data points, not a promise about how fast the facilitator indexes anyone. The lesson from both, and the one I'd tattoo on a new builder: **the failure lives at a boundary your tests can't see, and if you don't capture the evidence at the moment it happens, it evaporates.** A paid probe on mainnet is now a permanent item in my post-deploy checklist — not a test, a heartbeat — and I grab the logs *before* I do anything else. Here's the part I found most useful, and least flattering. One run, one token, three levels of hint — so treat this as a single anecdote (n=1), not a benchmark. I installed the most widely-used x402 client (AgentCash) into a fresh agent workspace and asked whether a specific Base token was safe. The token is a known honeypot — the "right" answer is unambiguous. The only question was whether the agent would *find and use my service* to get there. Only after I explicitly corrected it — "not that one, I mean token-risk.com" — did the agent discover the right origin, call it, and settle correctly (tx `0x8ac953da...98ed81` ). The report it got back matched every earlier scan exactly. Three rungs, three misses. Not one of them was the product failing — the engine was correct every time it ran. They were failures of **being found and chosen** among tens of thousands of catalog entries, at least one with a name identical to mine. One more honest number before the takeaways. I ran the wallet-risk endpoint against two addresses at opposite extremes: a wallet with years of on-chain history, and one I'd created five minutes earlier. The reports came back byte-for-byte identical. That's the current ceiling of that endpoint — it's structural-only (contract detection, verification status, ownership pattern), and it doesn't yet have any behavioral signal to tell those two wallets apart. I'm gating that work behind actual demand rather than building it speculatively. The bottleneck for a machine-payable API in mid-2026 is not whether the code works, and not whether the payment rail works — both are solved and settling real USDC today. The bottleneck is **discovery and disambiguation**: an agent has to know your service exists, decide it's the right tool for the intent, and pick it correctly out of a crowded, name-colliding catalog. That's a distribution problem, not an engineering one, and I spent most of my "distribution" effort learning that the hard way. Paid calls on a non-canonical host now get a machine-readable 421 carrying the canonical URL — refusing loudly instead of serving an untested cross-host payment path (no redirects: x402 clients aren't guaranteed to follow them mid-payment-flow). I identify the service by full origin URL now, never the bare name, and I filed the discovery friction behind it with the client maintainers: [https://github.com/Merit-Systems/agentcash-skills/issues/24](https://github.com/Merit-Systems/agentcash-skills/issues/24). I'm not going to pretend a single fix solves discovery. It might move the needle a little. The honest position is: I don't know yet, and I'll have real data in a few weeks. If you're building x402 services and getting external paid calls from agents you don't control — I'd genuinely like to know what made you findable, because from where I'm sitting the discovery layer is still "Yahoo, 1998," and I can't tell yet whether the buyers aren't there or just can't find the door. If you're an agent builder: what would make you trust and call a service like this without a human in the loop? That's the question I can't answer from my side of the transaction. Everything above is reproducible. The service is live at token-risk.com; there's a free sample report at /samples/index.json before you pay a cent. I'll post the follow-up when the 8-week window closes — with the same honesty, whatever the number is.