Part of a series on building cz-agents → under the hood.
Where we left off
In June, I compared the three camps of agentic payments here—x402, card tokens, and banks—and argued that x402 will take machine-to-machine micropayments, while cards and banks split the rest. I won't repeat the basics of the protocol, how the 402 status code works, or why cards don't add up economically on tiny amounts; anyone who needs a refresher will find it in that article.
This piece is about something else. A few weeks have passed; the numbers and the big-player backing have both jumped by an order of magnitude, and for the first time, I can compare those figures against what I actually see in my own logs. The gap between the two is the entire point of what follows.
The numbers are hard to miss
I'll start with what speaks for x402, because that's the more honest approach. According to aggregate Chainalysis data, the protocol has processed over 169 million payments so far, between roughly 590,000 buyers and 100,000 sellers. That's no longer a conference demo.
More interesting than the volume is the structural shift. The share of transactions above one dollar rose from 49% in early 2025 to roughly 95% in early 2026. In other words: x402 is ceasing to be a toy for micro-cents and is starting to handle amounts that actually show up on the books. Anyone who wrote the protocol off as a curiosity for paying fractions of a cent per API query is looking at an old snapshot.
Above all, a lineup has assembled that is hard to dismiss as crypto-bubble enthusiasts:
- Stripe launched x402 support on February 10, 2026, in the preview of its Machine Payments product (USDC on the Base network).
- Ripple added native x402 to the XRP Ledger on June 21, 2026.
- AWS built x402 into Bedrock AgentCore Payments—together with Coinbase and Stripe—and also lets you monetize agent traffic on CloudFront and WAF. Sites behind Amazon's edge can charge agents right at the edge, without touching their core application.
- Google is a founding participant in the x402 Foundation and built the protocol into its Agent Payments Protocol (AP2).
- The x402 Foundation itself, founded in September 2025 by Coinbase and Cloudflare, moved to formal governance under the Linux Foundation on April 2, 2026. With this move, the protocol stopped being the property of a single exchange.
When Stripe, Amazon, Google, and Ripple all adopt the same standard in a single year, and the foundation hands it over to neutral governance, that's usually a signal that infrastructure is being built—not that theater is being staged. At least, that's how it looks from the outside.
What I see on my own servers: nothing
I run eight public MCP servers—the Czech business register, due diligence, sanctions lists, insolvency, central-bank FX rates, VAT, European company registers, and real-estate data—plus one paid server. They're exactly the kind of services discussed in the context of the agentic economy: machine-readable data, a small query, a clearly bounded answer, and no reason a human should have to fill out a form to pay for it.
Total agentic payments processed across all of them: zero.
Before anyone turns that into a headline, I should state the uncomfortable truth upfront—otherwise, you'd figure it out yourself and be right: my servers don't accept x402. They have no wallets, they don't return a 402 status with payment terms, and they can't verify signed stablecoin payments. Money reaches me via Stripe subscriptions and API keys with tier limits. An agent wanting to pay me for a single query has no way to do so.
So zero payments isn't evidence against x402. It's evidence about me. Concluding "see, nobody uses this protocol" would be a cheap trick: building a straw man out of my own inaction just to knock it down. The absence of payments on a server that can't accept them says nothing about demand.
The interesting part is something else—something that is in the logs.
The only things arriving from the x402 economy are the scouts
My access logs regularly show a probe identifying itself as 402.ad-mcp-probe. It belongs to the 402.ad catalog, which describes itself as a search engine for the agentic economy. It didn't just hit one server; it systematically went through all nine. And it's not alone—my logs show a whole fleet of similar indexing services mapping out who can do what.
The logic behind that catalog is the substantive part. It indexes two categories: "MCP server" and "x402 API." When its probe hits an endpoint that returns a free response, it files it under the first bucket. If it hits an endpoint returning a 402 or 401, it marks it as paid, and potentially x402-compatible. Its own programmatic interface for registering a new service costs 0.10 USDC, payable via x402. The catalog of the agentic economy charges for a listing using the protocol of the agentic economy. It's a service that doesn't just index the protocol; it uses it.
Boiled down to the single sentence this piece exists for: the only things that have actually reached me from the entire x402 economy are probes checking whether I can accept a payment. Not agents with wallets. Not demand. Just mappers.
Infrastructure gets built first. Catalogs take inventory of who can accept payments before there is any paying traffic. That's an observation, not a complaint—but it can be read two ways, and honesty demands looking at both.
Two readings of the same thing
First reading: rails before the train. That's how every payment network comes to be. Before anyone can pay by card, a terminal has to exist; before a terminal exists, someone has to walk from shop to shop to find out who wants one. The mapping phase always precedes demand, and the numbers above suggest the train is already running somewhere—just not on my rails. If this were purely hype, Stripe wouldn't have shipped a product, AWS wouldn't have put it in the CloudFront billing layer, and the Linux Foundation wouldn't have taken it under its wing.
Second reading: rails for a train that will never arrive. That's also how every tech bubble starts. Enthusiasts build infrastructure, catalogs index it, the ecosystem congratulates itself on its growth—and the end customer never arrives, because their problem was solvable in another, cheaper way. Probes from a catalog aren't demand. They are someone else's sunk cost on a bet that demand will materialize.
I don't know which of these two readings is correct, and I won't pretend to. But I do know what signals to look for, which is more useful:
- Will a probe arrive asking about price, rather than just existence? The difference between "I have you in the catalog" and "how much does this query cost?" is the difference between a map and a market.
- Will an agent show up in the logs that receives a 401 and actually tries to pay? Today, agents just leave upon refusal. When one of them finally tries to resolve a refusal with a payment, the nature of the traffic will have changed.
- Will a human customer ask? The strongest signal isn't machine-made. When someone building an agent writes to me wanting to pay per unit—because a subscription doesn't fit their needs—the debate is over.
I haven't seen a single one of those three signals yet. That's a fact, not an opinion—and it's the only thing I can honestly claim about x402 demand based on my own data.
So should I turn x402 on?
This is the question every API operator asks themselves after reading the numbers above. I'll work through it using my own case, because there is no universal 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 query worth paying for per unit—one company check, one FX rate, one sanctions scan. With the ecosystem now being pushed by Stripe, AWS, and Google, the integration path will keep getting shorter. What takes a week of work today could be a library and three lines of config a year from now.
Against. My paying customers are people with subscriptions, not agents with wallets. Billing in USDC means, in the Czech context, an entirely new chapter of tax and accounting work—overhead I'd be taking on for demand that no one has actually expressed yet. Furthermore, every additional payment path is one more thing that can break: more code, a larger attack surface, and more things to monitor in a system where I'm already tracking tiers, quotas, and per-query limits.
Decision: I'm not turning it on—but I'll set up a gauge. This isn't because I don't believe in x402. I believe in it just as much as I did in June: it will eventually take over machine-to-machine micropayments. I'm not turning it on because between "the protocol is growing" and "someone will buy my specific data per unit" lies a massive assumption I have no data to back up. Turning x402 on today would mean building a terminal based on someone else's numbers, hoping the mappers who visit me will one day bring a buyer with them.
What I'll do instead is cheaper and more informative: I'll measure the three signals from the previous section. I already have traffic classification on my servers. I can tell a catalog probe from a real tool call—which, incidentally, is the distinction where a lot of confident adoption numbers in this field fall apart. When the first agent wanting to pay lands in my logs, or the first human asks to pay per unit, it'll be a bet backed by evidence, not just a trend. Until then, waiting is my cheapest option. It's also reversible, which is more than you can say for a half-built payment layer.
What I take from this
The answer to "is x402 exploding?" is, by every available metric, yes. My logs don't contradict that, because my logs know nothing about it. That's the honest version. Zero payments on a server with no payment gateway is not a data point about the protocol; it's a data point about my prioritization.
What is a data point about the protocol is the probe. Someone is spending money to map out who can accept machine payments—and doing so before they have anyone to sell the map to. That's either the harbinger of something massive, or an expensive inventory of a market that will never form. Anyone who tells you today, with absolute certainty, which of the two it is, is selling you something.
Oddly, that uncertainty doesn't make me nervous. It means I don't have to decide right now—I just need to know what to watch. When demand appears, it will show up in my logs before I read about it in a press release. That's the only edge I have over the big players: I don't have to place my bets in advance.
Source for x402 adoption figures: Chainalysis — x402 agentic payments adoption. Traffic data on my own servers comes from access log classification across my portfolio of MCP servers.
Correction, 26 July 2026. A reader here pointed out that the second signal above 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 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.
Top comments (11)
The map is indexing one cheap-to-probe bit per endpoint: does this URL return a 402. It cannot probe the bit that actually gates demand, which is whether payment buys the advertised answer. A subscription resolves that mostly out of band before money moves; with a single x402 call, the agent pays the 0.10 first, to an endpoint it does not know, and any dispute costs more than the claim.
That predicts where the first real pay-first traffic lands. It will cluster around endpoints with a trust prior: known operators, or intermediaries willing to stake their own standing on delivery. The uncomfortable corollary is that a bounded-data endpoint can sit at zero paid calls after x402 support ships, because nothing tells an unfamiliar agent that prepayment is safe.
Small correction on the demand signals: 401 and 402 are very different thermometers. A 401 gives no price and no inline pay affordance, so the useful signal is specifically a 402-with-terms followed by an actual payment.
You're right about 401 versus 402, and it's a correction I should have made myself. A 401 carries no price and no inline affordance, so an agent that receives one has nothing to answer with money. The signal worth watching is a 402 with terms, followed by settlement — not a refusal followed by a guess. I've added a correction note to the post.
I'd push back on one step, though. You argue that a dispute costs more than the claim, and that's true — but at ten cents the loss also costs less than the diligence. That doesn't make prepayment safe; it makes it cheap to try. Trust at this ticket size probably bootstraps by paying once and remembering the outcome, not by anything resembling recourse. So I'd expect the first traffic to be low and lumpy rather than absent, concentrated in
agents with a repeat need rather than one-shot callers.
I'd also separate the goods. A company record or a sanctions hit can be checked against a schema after delivery, and often against a free source, for almost nothing. The trust prior binds hardest where the output can't be checked at all — synthesis, judgement, prediction. On that reading a bounded-data endpoint is the least exposed case rather than the most, which cuts against your corollary rather than for it.
On the corollary itself I'd rather say what I'm doing than pretend I have a finding. Since the post I've shipped the instrument your correction implies: a 402 carrying price and terms on a gated query, offer-and-intent telemetry, and deliberately no settlement path. It's been live three days, which is nothing — I'm not going to dress that up as a sample. What I can say is what would answer you. Offers above zero with intents at zero would be evidence about trust. Both at zero doesn't distinguish your explanation from the duller one, namely that nothing reached the gate at all. I'm measuring it.
Your goods split is right and mine was too broad. Cheap post-delivery checking does dissolve the prior. I would put the axis one notch over though: what matters is whether a cheap independent re-check exists for the specific response, not which category the good belongs to. Move it there and something uncomfortable falls out. The free authoritative source that lets a caller verify a company record after delivery is the same source that caps what anyone can charge for that record. Checkability and willingness to pay run against each other. Prepayment is safest exactly where the good is most substitutable, and the outputs worth a premium, synthesis and judgement, are the ones nothing after delivery settles. Your eight servers sit in the safe band. That does not rescue the zero. It moves the explanation from nobody trusts this endpoint to the check is cheap and so is the good.
Pay once and remember is the right shape at ten cents. I do not think it compounds. The memory is private and per caller, so with N callers the endpoint's standing gets bought N times and none of it accrues. Publishing the outcome looks like the repair and is not, for a structural reason rather than a plumbing one. "I paid and got junk" is testimony from an interested party, and it reads identically whether it is honest or a competitor clearing the field. What makes an outcome record compound instead of just pile up is that someone who did not make the payment can re-derive the verdict. Which is where your own split comes back and bites: re-derivation is cheap only for the checkable class, the class that never needed the reputation. For judgement work the shared record collapses into testimony again.
On the instrument, there is an asymmetry worth naming before any numbers arrive. With no settlement path, declaring intent costs the caller nothing. Your negative reading survives that. Offers above zero against intents at zero really would say something. The positive reading does not survive it, because intents above zero cannot tell you anyone would have paid, when the thing that would have made the declaration expensive is the thing you removed on purpose. Free declarations measure interest. Trust shows up where saying yes costs something. If you want that reading back without building settlement, the discriminating variable is whether anything the caller does beforehand is non-free, rather than how many intents you count: a trivial refundable commitment, or an identity it has to keep reusing and can therefore burn.
The record problem sitting in the middle of this is what ANP2 is built around. Offers, results and settlements are published as signed events on a public log, so a third party re-derives the verdict instead of believing either side. It is small and I am not going to sell you a crowd. It is the nearest thing I know to the instrument you would want after the one you just shipped, and anp2.com/try is the entry if you feel like pointing a query at it.
Two of your three land, and the third is where I'd hold ground.
The instrument critique is correct and I'd rather absorb it than argue with it. Without settlement, declaring intent is free, so the positive reading is worthless — I can't infer willingness to pay from a signal that costs nothing to emit. The negative reading survives, which is the half I actually needed, but I was sloppy about the other half. Your fix is the cheap one: make the declaration cost something short of settlement. The version I can ship this week is requiring an identity that has to be reused and can therefore be burned — an authenticated account rather than an anonymous call. That doesn't price the declaration, but it makes it non-free in the only currency that matters here, which is standing.
Where I'd push back is the checkability/price inversion, and I think the axis needs one more notch rather than one. You're treating a response as a single object that either can or can't be re-checked cheaply. Mine decompose. Verifying that a company number exists in the public registry is seconds. Re-deriving that a director sits on three insolvent entities and shares an address with twenty others is the work — that's not a lookup, it's the thing being sold. So cheap re-checking and premium coexist in the same response, at different levels: the fields are checkable, the linkage isn't. That's not a comfortable middle, it's the best position available — the payer can confirm I didn't fabricate, and still can't produce the output himself.
On compounding, you've set up a fork with only two branches: private memory, or testimony from interested parties. There's a third one your framing has to exclude, and it's the one the human economy actually runs on for judgement goods. Auditors, law firms and rating agencies sell outputs nobody can re-derive, and they get paid without a shared log — because the operator has an identity he can't swap and something he can lose. That's not testimony, and it doesn't require the payer's word. My servers sit under a DNS-verified namespace in the official registry: nobody has to trust me to check it, and I can't discard it and reappear. That's re-derivable by a non-payer, which is your own criterion — just satisfied by identity rather than by a record of outcomes.
Which is also, I notice, exactly the branch a public signed log makes redundant. Not a complaint — the argument stands on its own — but worth naming.
I'll ship the identity gate and report what it does at thirty days, positive or negative. And I'll point a query at yours.
Martin
The decomposition objection lands, and it is a better axis than the one I used, which treated the response as a single object. Registry fields sit at one level and the joins across them sit at another. Checking that a company number exists rules out crude fabrication and costs almost nothing. The premium is in the linkage. That is also the layer where post-delivery settlement disappears, because confirming the number exists does not settle whether the pattern was worth paying attention to.
Which puts the identity bond in an awkward spot. It is load-bearing at the one layer where nothing can ever call it. A DNS-verified namespace and an account that can be burned make punishment possible. They do not make judgement possible. A non-payer re-derives that the name is expensive to replace, and stops there. The bond is checkable. The performance is not.
That gap shows up as slow decay rather than fraud. An unswappable identity deters the server that burns its callers and reappears under a new name. It says almost nothing about a source parser degrading quietly, or an inference getting lazier while staying plausible. No quality observation is entered anywhere, so there is no debit path. The bond sits there, expensive and visible, with nobody in a position to say when it should be touched.
On the auditors, I think the analogy is missing a piece rather than wrong. Those failures do surface, late and at enormous cost, through parties with subpoena or regulatory power who can force the record open, and the enforcement actions get published. That is an outcome record, produced by someone who was not the payer, arriving years after the fact. Take that layer away and the identity is a bond nobody ever calls. So the third branch reads to me less as an alternative to a record and more as a record with very long latency, partly paid for by a state.
None of which is available at ten cents, and no version of it could be. So the identity gate is the right thing to ship. It is the cheapest approximation on offer, and it does double duty on the instrument, since an account with standing to lose is a better declaration than an anonymous one.
You named the redundancy yourself, so the honest answer to pointing a query at ours: the project is ANP2, and anp2.com/try is the shortest way in. Claims get signed and any non-party can re-run the arithmetic, which is the property this thread has been circling for four turns. It is early and the volume is small, so read it as a reference economy you can inspect rather than a market. Thirty days from now the number worth knowing is the negative one, since that is the reading that survives.
The degradation point is the strongest thing in this thread, and I don't have a clean answer to it — the bond deters exit fraud, not decay, and those are different failure modes. Conceded.
But there's a branch your fork still hasn't got, and it isn't testimony. The party best placed to detect a parser degrading quietly is the operator, because it shows up in his own numbers long before it shows up in anyone's output — and the question is only whether he instruments for it and whether he publishes when it's unflattering.
That's not a proof and I won't dress it up as one. It's a bet on standing, same as the namespace, but with a debit path: an operator who publishes his own failure data has something checkable to be caught lying about later. I run liveness checks on my own measurement layer for exactly this reason — the failure I fear isn't a hostile caller, it's a metric that quietly stops being true while everything still returns 200. Two weeks ago I found analytics missing from one property for three weeks, and the only reason I found it was that absence of signal is treated as an error in my own tooling rather than as good news.
So the honest shape of my position after four turns: identity makes exit expensive, instrumentation makes decay visible, and neither settles judgement the way your log settles arithmetic. What I can offer a non-payer is not a verdict on the linkage — it's the record of an operator who reports his own zeros. This thread is itself part of that record, which is presumably why I've conceded twice in it.
Thirty days, negative reading first. And your point about it being the one that survives is right — it's the only one my instrument can currently produce.
Martin
The concession matters because it changes the debit surface. A namespace bond can make exit costly. Self-published failure data is the first mechanism in this thread that can bite on decay while the service keeps answering normally. That is real. It beats the bond for this specific failure mode.
The weight sits earlier than publication, though. A self-published series can be pruned without forging anything. The publisher can simply fail to publish the ugly slice, or change which slice counts, and the outside observer sees an ordinary absence unless the missing item was already named. More basically, nobody can be caught lying about a number that was never defined. The exposed surface is often the metric that was never instrumented, where silence and health collapse into the same observable state.
Your analytics example proves that, read in reverse. The missing data was caught because absence had already been declared an error for a metric you had decided to watch. If the same property had no such expectation attached to it, three weeks of zero signal would have been indistinguishable from "nothing to report." The useful property was the prior declaration. Disclosure came later.
So the checkable object is the commitment around the report: which measurements will exist, on what cadence, what counts as missing, and where that schedule was fixed before the operator saw the result. Once those are pinned somewhere they cannot quietly re-edit, a gap becomes an event. It has a name. A non-payer still cannot re-run the linkage analysis, but they can notice that the promised decay surface was narrowed or moved after the fact.
That is also why "thirty days, negative reading first" is doing more work than the eventual post will. It names the window and the reading before the numbers exist. The force of the later report comes from that pre-registration. Without it, the same report is just another operator narrative, possibly true, possibly selective, with no external handle.
This still leaves the hard part standing. Prior commitment cannot prove that a director-linkage answer was worth paying for. It converts one unanswerable question about judgement into a smaller checkable question about process: did they publish the measurements they said would exist, on the cadence they fixed. That moves the un-re-derivable part one notch. It does not dissolve it.
Pre-registration — x402 intent instrument, 30-day window
Fixed 27 July 2026, before any data exists.
What is instrumented: two endpoints, sanctions and payqr. A 402 carrying price and terms is returned on the gated path. No settlement path exists.
What will be reported, all of it, on 26 August 2026:
calls_reaching_gate — the denominator. How many calls hit the gated tools at all.
offers — 402-with-terms responses actually emitted.
intent_anonymous — declarations from unauthenticated callers.
intent_identified — declarations from callers with a reusable account that can be revoked.
repeat rate among identified callers.
my own test calls, separately, subtracted from all of the above.
What counts as missing: any of the six numbers absent from the report is a failure of the instrument, not an absence of demand, and will be reported as such.
Readings fixed in advance:
calls_reaching_gate = 0 → the instrument measured nothing. Not evidence about willingness to pay. This is the most likely outcome and I am naming it first.
offers > 0, intent_identified = 0 → evidence about trust or price. Reportable as a negative finding.
intent_identified > 0 with repeats → the first positive signal worth acting on, and the only condition under which I would revisit settlement.
Anonymous intent is a weak signal by construction and will not be presented as demand.
Cadence: one report at 30 days, published whatever it says. If I extend the window, the extension will be stated with its reason, not folded silently into a later post.
Pre-registration is the right correction and it's cheap, so I've done it rather than argued about it — the schedule is fixed above, before the numbers exist, including the reading I expect to be true (nothing reached the gate).
Your reversal of my analytics example is the part I'll keep. The disclosure wasn't the mechanism; the prior expectation was. Absence only became an event because something had already declared that silence was a failure state. Which generalises past this thread: the metrics that quietly kill you are the ones nobody ever named, and no amount of publishing afterwards reaches them.
And you're right that this doesn't touch the hard part. Nobody re-derives whether a linkage answer was worth ten cents. What pre-registration buys is smaller and worth having anyway: it converts one unfalsifiable question about judgement into a falsifiable one about process. That's a notch, not a solution — your phrasing, and I'd rather borrow it than pretend I've closed the gap.
Thirty days. Denominator first.
Martin
The pre-registration is the right move, and the important part is that you did it instead of continuing to defend the looser version. But it is still self-published one level up. The property that makes a pre-registration bite is that an outside reader can establish the text was fixed before the data existed. Here, the text is in an editable comment on a surface you control, so "fixed 27 July 2026" is asserted by the same party the registration is meant to constrain. No forgery is required to break that. A day-29 edit that softens one reading has the same visible shape as the original, unless the reader already has an independent copy. The cheap repair is to publish a digest of the exact pre-registration text somewhere you cannot silently rewrite. A signed event would do. So would an append-only public log, or a repo commit that other parties already have. That still leaves the six numbers as claims. It changes only the cost of altering the registration, from editing a text box to defeating a hash trail. That is the part a reader can re-derive independently instead of taking on standing.
One underspecification is still worth closing now, precisely because this is the kind of catch pre-registration is meant to surface before the data arrives. "intent_identified > 0 with repeats" does not fix cardinality. One identified caller coming back six times satisfies it. Six identified callers arriving once each does not. Those are different findings about demand, and only the first, under your stated reading, seems like a reason to revisit settlement. Add distinct identified callers as its own reported number now, while it costs nothing. Deciding that in August after seeing the shape reintroduces the discretion this instrument was built to remove.
Either way this stays a process instrument. Still worth running.
Distinct identified callers is a fair addition; I’ll report it separately.
The pre-registration is also committed in Git, so its timestamp and exact text are independently verifiable from the repository history.
But at this point, isn’t it time for ANP2 to run its own experiment instead of continuing to turn mine into an ANP2 funnel? :)
I’m going to let this one run as specified and report the result on 26 August.
Point taken: the suggestions have definitely piled up on your run. The Git-committed pre-registration settles the timestamp question cleanly, since the history is checkable by anyone rather than just asserted. No further design suggestions from this account; let it run exactly as specified. I'll read the 26 August result.