In part 1 we listed what broke while selling four small services over x402 (pay per request, USDC on Base). In part 2 we wrapped the shop in an MCP server. Part 2 ended with a promise: who actually buys in x402, once we have numbers we trust.
This part is about why that took longer than planned. Our numbers were wrong three times in one week: twice about other sellers, once about ourselves. There is also one gotcha that has nothing to do with payments, and it took our agent offline for 30 hours.
The lesson that matters most: before you trust a number, ask what it counts: which product, which time window, which files. Every number below was right about something. Just not about what we had asked.
A seller's buyers are not a product's buyers
Before building a new service, we check for demand. Our rule: a similar x402 service must already have 5 or more distinct buyers in the last 30 days, not counting probes. The obvious source is on-chain. x402 payments land on the seller's payTo address, and explorers count buyers per address.
The catch is that many sellers use one wallet for their whole catalog. A candidate looked like it had real buyers. But the wallet behind it also took payments for security scans, trademark checks and other products. Those buyers proved the seller sells something. They said nothing about that one product.
Fix: a seller only counts as evidence for a product when it sells just that product, or when the calls can be split by route. The clearest example we found was a single-product site-checking service: 35 buyers, about 41 payments each. That is demand you can read.
Cumulative is not "last 30 days"
Same week, second trap. The stats snapshot we used gives three fields per address:
recipient -> tx_count, unique_buyers, latest_block_timestamp
We asked for buyers in the last 30 days, and the snapshot can't answer that. unique_buyers counts from the address's first payment, and the timestamp is only the latest one. 500 buyers could be 500 in the first month and none since. Nothing in the field names tells you which.
Our agent answered "not computable from this data" instead of making up a number. That was the right answer. If you need a time window, you need the payments themselves, each with its timestamp, not a summary.
For the wider picture, per-service numbers do exist. graded.sh's August report,, built from its own probes, counted 292,967 paid calls in 30 days. The ten biggest services took about 80% of them, and one domain alone took 41%. 81% of the services with any demand had fewer than 10 calls. The median price was $0.01. So who buys in x402? A few agents, buying a few cheap things many times.
Read every log file, not just the newest
Then our own numbers were wrong, in the other direction. On 10 Oct our agent reported that no payment had ever completed on our shop: 568 quotes, 0 paid calls. It had read nginx's access.log. But logrotate had moved older days to access.log.1 and compressed the rest. The paid calls were in those files.
What it read (result: 0):
grep ' /services/' /var/log/nginx/access.log | awk '$9 == 200' | wc -l
What it should have read:
zcat -f /var/log/nginx/access.log* | grep ' /services/' | awk '$9 == 200' | wc -l
Now the less flattering part. All 8 paid calls in those files were ours (test purchases from our own wallet) or from an inspector checking that payment works. Not one customer. So "no customer has paid yet" was true. "No payment ever completes" was false. The difference matters: the first is a demand problem, the second a broken checkout. Had we believed it, we would have spent days fixing a checkout that works.
Fix: count across every rotated file, and take out your own wallet's payments before you count anything. Better still, count settled payments on-chain, which never rotate.
The API key expired, and nothing alerted
This one isn't about x402. SWARM thinks through the Anthropic API. When we created its key, we set it to expire after 30 days. That's a sensible precaution, until you forget it. On 11 Oct it expired, and every model call returned:
401 authentication_error: invalid x-api-key
The server stayed up, the shop kept answering, and the agent's process kept running and retrying. It just couldn't think, for about 30 hours. We have a Telegram alert for model calls failing, but it only matches one error: out of credit. An invalid key is a different error, so the alert stayed silent. We only noticed at the next morning's check.
Fix: a new key, with its expiry date in the calendar and a reminder a few days before. The sturdier fix is to alert when success stops, as in "no successful model call in N hours", instead of matching error messages one by one. We haven't built that: for a hobby project, the calendar reminder is enough. If your agent earns money while it thinks, build the heartbeat first.
Where it stands
Customer sales are still zero. Every paid call on our shop so far was ours or an inspector's. What changed is that we now trust that zero, and we know what the numbers about other sellers mean. We're choosing the next product by per-product demand.
If your agent buys x402 services, we'd like to know what it pays for: contact@swarm-agent.net.
The shop: swarm-agent.net · the MCP server is open source (MIT): github.com/swarm-agent-operator/swarm-x402-mcp.
Top comments (0)