Part of a series on building cz-agents → under the hood

Where we left off

In June I compared the three camps of agent payments — x402, card tokens and banks — and concluded that x402 would most likely take machine-to-machine micropayments while cards and banks split the rest. So I will not repeat the basics here: what HTTP 402 is, how the protocol works, why cards cannot economically carry small amounts. That is all in the earlier piece.

This one is a different question. A few weeks have passed, the adoption numbers and the roster of backers have both jumped an order of magnitude — and for the first time I can hold those numbers next to what I actually see in my own logs. The gap between the two is the entire point of what follows.

The numbers you cannot wave away

Let me start with the case for x402, because that is the honest order. According to aggregate data from Chainalysis, the protocol has now processed more than 169 million payments, across roughly 590,000 buyers and 100,000 sellers. That is no longer a conference demo.

More telling than the volume is the shift in composition. The share of transactions above one dollar rose from 49% at the start of 2025 to roughly 95% at the start of 2026. In other words: x402 is ceasing to be a toy for fractions of a cent and is starting to move amounts that someone will eventually see in a ledger. Anyone who filed it away as a curiosity for paying sub-cent fees per API call was reading an old snapshot.

And the roster is hard to dismiss as crypto enthusiasm:

When Stripe, Amazon, Google and Ripple adopt the same standard within a single year and the foundation hands governance to a neutral body, that usually signals infrastructure being poured rather than theatre being staged. At least, that is how it reads from the outside.

What my servers see of it: nothing

I run eight public MCP servers — company registry lookups, due diligence, sanctions screening, insolvency, central-bank exchange rates, VAT checks, European business registers and distressed real estate — plus one paid tier. They are exactly the sort of service the agent economy is supposed to be about: machine-readable data, a small query, a bounded answer, no reason for a human to be sitting in front of a payment form.

Agent payments received through them, all-time: zero.

Before anyone turns that into a headline, let me say the uncomfortable part immediately, because otherwise the reader will work it out and be right: my servers do not accept x402. No wallet, no 402 response carrying payment terms, no verification of a signed stablecoin payment. Money reaches me through Stripe subscriptions and API keys gated by tier. An agent that wanted to pay me for a single query has nowhere to put the coin.

So zero payments is not evidence about x402. It is evidence about me. Turning it into "see, nobody uses that protocol" would be a cheap trick: build a straw man out of your own inaction, then knock it over. The absence of a payment on a server that cannot receive one says exactly nothing about demand.

The interesting thing is elsewhere. It is the thing that is in the logs.

The only part of the x402 economy that reached me is probes

My access logs regularly show a probe identifying itself as 402.ad-mcp-probe. It belongs to 402.ad, a catalogue that describes itself as a search engine for the agentic economy. It did not sample one server — it walked the entire set of nine, systematically. And it is not alone: the logs carry a whole fleet of indexing services mapping who can do what.

The catalogue's logic is the part that matters. It indexes two categories: "MCP server" and "x402 API". When its probe finds an endpoint that answers for free, it files it under the first. Had it found an endpoint returning 402 or 401, it would tag it as paid, plausibly x402. And submitting a service through its programmatic interface costs 0.10 USDC, paid over x402. The catalogue of the agent economy charges for entry using the protocol of the agent economy — so it does not merely index x402, it runs on it.

Which condenses into the sentence this whole post exists for: the only thing that has actually reached me from the entire x402 economy is probes checking whether I am payable. Not agents with wallets. Not demand. Surveyors.

The infrastructure is being laid first. Catalogues are taking inventory of who can accept a payment before there is any traffic that would pay. That is an observation, not a complaint — but it is an observation that admits two readings, and honesty demands showing both.

Two readings of the same fact

Reading one: the track before the train. This is how every payment network was born. Before anyone pays by card, a terminal must exist; before a terminal exists, someone must walk the shops and find out who wants one. The survey always precedes the demand — and the numbers above say a train is running somewhere, just not on my track. If this were pure hype, Stripe would not have shipped a product, AWS would not have wired it into the billing layer at CloudFront, and the Linux Foundation would not have taken it in.

Reading two: track the train never runs on. This is also how every technology bubble was born. Enthusiasts build infrastructure, catalogues index it, the ecosystem congratulates itself on its own growth — and the end customer never arrives, because their problem turned out to be solvable some other, cheaper way. Probes from a catalogue are not demand. They are someone else's cost of a bet that demand will come.

I do not know which reading is right, and I will not pretend I do. What I do know is how I will tell, which is more useful:

  1. Does a probe show up asking about price rather than existence? The difference between "I have you in my catalogue" and "how much is this query" is the whole difference between a map and a market.
  2. Does an agent appear that got a 401 and then tried to pay? Today, agents that get refused simply leave. The first one that tries to answer a refusal with money changes the character of the traffic.

    Correction, 26 July 2026. A reader on dev.to pointed out that this signal is mis-specified, and they are right. A 401 carries no price and no inline way to pay, so an agent that receives one has nothing to answer with money — it can only guess. The signal that means something is a 402 carrying terms, followed by an actual payment. I have left the original wording above rather than quietly rewriting it, because the mistake is the interesting part: I was watching the thermometer that was easiest to read instead of the one attached to the question.
  3. Does a human customer ask? The strongest signal is not a machine one. The day someone building an agent writes to say that a subscription does not fit and they want to pay per query, the argument is over.

I have seen none of those three. That is a fact, not an opinion — and it is the only thing about x402 demand that my own data lets me honestly claim.

So should I switch x402 on?

This is the question every API operator asks after reading the numbers above. I will work it through on my own case, because there is no general answer.

For. The barrier for an agent is zero: no registration, no key, no waiting for a human to approve access. My data is exactly the kind of small, bounded query worth paying for by the piece — one company check, one exchange rate, one sanctions scan. And with Stripe, AWS and Google pushing, the integration path will only get shorter; what is a week of work today may be a library and three lines of config a year from now.

Against. My paying customers are humans on subscriptions, not agents with wallets. Accounting for USDC in the Czech Republic is its own chapter of tax and bookkeeping work, taken on for demand nobody has yet expressed. And every additional payment path is one more thing that breaks: more code, more attack surface, more to watch in a system that already polices tiers, quotas and per-query caps.

Decision: not switching it on — but building the yardstick. Not because I disbelieve x402; I believe roughly what I believed in June, namely that it will end up owning machine-to-machine micropayments. I am not switching it on because between "the protocol is growing" and "someone will buy my specific data by the piece" sits a claim I have nothing to support with. Enabling x402 today would mean installing a terminal on the strength of somebody else's numbers and hoping the surveyors who visit me eventually bring buyers.

What I will do instead is cheaper and tells me more: measure those three signals. I already classify traffic on these servers — I can separate a catalogue probe from a real tool call, which is incidentally the distinction on which a great many confident adoption numbers in this field quietly fall apart. When the first agent that wants to pay lands in my logs, or the first human who wants per-query billing, the bet will rest on evidence rather than a trend. Until then, waiting is the cheapest option I have — and it is reversible, which is more than can be said for a half-built payment layer.

What I take from it

The answer to "is x402 exploding?" is, by every number available, yes — and my logs do not contradict that, because my logs know nothing about it. That is the honest version. Zero payments on a server with no payment gate is not a data point about the protocol; it is a data point about my priorities.

What is a data point about the protocol is the probe. Someone is spending money to map who in this country can accept a machine payment — and doing it before they have anyone to sell that map to. That is either the leading edge of something large, or an expensive inventory of a market that never forms. Anyone telling you today which of the two with confidence is selling you something.

Oddly, the uncertainty does not bother me. It means I do not have to decide now — I only have to know what to watch. When demand appears, it will appear in my logs before I read about it in a press release. That is the one advantage I hold over the big players: I do not have to bet in advance.

Source for the x402 adoption figures: Chainalysis — x402 agentic payments adoption. Traffic figures come from the access-log classification across my own portfolio of MCP servers.