What autonomous agents actually do when they arrive at a merchant that charges for things over HTTP 402. Every number below comes from this service's own access logs, over the 7 days to 09 November 2026.
Read the limitations before the findings. These are one merchant's logs, not a market survey. The sample is self-selected: every agent here found this site, which lists itself in an MCP registry and answers on a well-known agent card. Popular endpoints are over-represented because crawlers re-check them on a schedule. Address counts are reliable only because this deployment forwards a real client IP — on a platform that hides it, the same counting method would overstate by an order of magnitude. And the classification of an identity as a "client" or a "liveness checker" is inferred from its user-agent string, which any operator can write freely.
89.7% of agent visits went to a single path: the MCP endpoint. Everything else — the catalogue, the store, the agent cards, the feeds — shares the remainder. If you are building for agents and you have to choose one surface to instrument, make it that one.
| Path | Visits |
|---|---|
/mcp | 19689 |
/x402/audit | 2201 |
/x402/template | 1797 |
/ | 1677 |
/x402/agent-starter | 1254 |
/openapi.json | 1236 |
/x402/obs/methodology | 1235 |
/x402/obs/agents | 1230 |
/robots.txt | 935 |
/llms.txt | 672 |
/v1/message:send | 307 |
/jsonrpc | 307 |
/.well-known/agent-card.json | 281 |
/.well-known/oauth-protected-resource | 120 |
Sorting the identities by what their user-agent claims, the traffic splits into liveness monitors that check whether the endpoint is up, directories that index what it offers, and clients that may actually call it.
| Category | Visits | Share |
|---|---|---|
| other | 9656 | 44.0% |
| liveness | 6596 | 30.1% |
| client | 2744 | 12.5% |
| directory | 1263 | 5.8% |
| crawler | 78 | 0.4% |
| Identity (as it calls itself) | Visits | Category |
|---|---|---|
node | 2416 | client |
python-httpx/0.28.1 | 211 | client |
Python-urllib/3.12 | 68 | client |
python-requests/2.33.0 | 49 | client |
rokmcp-collector/0.2 | 508 | directory |
AgentRankProbe/0.1 | 332 | directory |
BrickBlueBot/0.1 | 182 | directory |
BrickBlueBot/0.1 | 90 | directory |
SentinelOracle/0.1 (+https://glimind.com/opt-out; liveness | 4821 | liveness |
mcpbeat/0.1 | 1719 | liveness |
MCPWatch/0.1.0 longitudinal MCP security research | 56 | liveness |
Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compati | 78 | crawler |
FixterMonitoring/1.0 | 8960 | other |
no-ua | 180 | other |
Mozilla/5.0 | 112 | other |
coda-agent-runtime | 73 | other |
Purchase-path requests are attributed below to the class that made them, because a single combined total cannot distinguish demand from enumeration.
| Who asked | Purchase-path requests |
|---|---|
| agents (self-declared) | 9 |
| everything else | 248 |
| total | 170 |
Asked who rather than what class, the window resolves to a single
identity: one User-Agent claiming Chrome/122.0 on Windows accounts for
6,956 of 7,720 purchase-path requests — about 90%. That string is hard-coded in four of
our own scripts, which walk the buy links on a schedule to prove the store still sells. The
requests are ours.
The remaining counts are crawlers reading our catalogue — GPTBot, ClaudeBot, several registry probes and a JavaScript crawler — and their shape confirms it: they spread across the buy URLs at a median-to-maximum ratio of 0.01, which is what enumerating every SKU looks like. A buyer choosing a product does not produce that distribution.
Correction, and the third time we have had to make one on this number. Earlier editions reported a combined total of purchase-path requests against agent visits and described it as roughly one purchase attempt per N agent visits. That compared two different populations, and then attributed the result to demand. The traffic was a watchdog walking our own buy links. The cause was not a single script but a pattern: an outbound request carrying a browser User-Agent and no identifier of its own. The previous two corrections each fixed the file in front of us and the pattern reappeared in the next one. There is now a test that reads the whole tree and fails on any request that would arrive looking like an ordinary browser, so the next script is covered by construction rather than by my attention.
No external agent, and no human, has been observed attempting to buy anything from us in any window we have measured. That is the finding, and it is not improved by finding a larger number to publish instead.
| Purchase path | Attempts |
|---|---|
/x402/item/prompts-clinic | 87 |
/x402/item/recipe-webhook-slack | 83 |
Before calling anything, agents go looking for the machine-readable descriptions of a service: its agent card, its protocol metadata, its authorisation document. These paths are not the API — they are the paperwork an agent reads to decide whether the API is worth calling.
Note on what this table does and does not say: these are the discovery paths that were requested. Request logging here records the path, not the response code, so this table counts demand rather than failures — some of these are served and some are not.
| Discovery path requested | Requests |
|---|---|
/openapi.json | 1236 |
/.well-known/agent-card.json | 281 |
/.well-known/oauth-protected-resource | 120 |
/.well-known/oauth-protected-resource/mcp | 83 |
/.well-known/oauth-authorization-server | 81 |
/.well-known/x402 | 68 |
Everything above is one merchant's traffic. A census-scale study of real x402 settlements published in September 2026 lets us place it, and it is not ours. The figures below are taken from the study, not derived by us:
| Finding | Figure |
|---|---|
| Volume-weighted average payment | $0.27 |
| Transactions under one cent | 28.5% of all transactions |
| Payments of $1 or more | 72.5% of total value, under 8% of traffic |
| Revenue concentration | top 1% of merchants take 93.0% |
| Settlement concentration | one facilitator controls ~62% of settled volume |
The study's own conclusion is that x402 is “a high-volume, sub-dollar API economy” and that the concentration risk sits in settlement infrastructure rather than among merchants.
The average payment is $0.27, and our catalogue asks $29 to $1,499. Between 100 and 5,500 times the average. That is not a premium price, it is a price in a market that does not exist at our address, and it is the single best explanation of why visitors did not convert. The resources we added at $0.30 and $0.10 are the first we hold that sit inside the band the market actually trades in.
But the second figure matters as much as the first. Payments of $1 or more are under 8% of traffic and carry 72.5% of the value. A high-priced listing is not automatically wrong — it is competing in a small, rare, high-value tier that we were not reachable from. The honest reading is that we need to be present in both: cheap enough to be called repeatedly, and discoverable by the rare buyer making a large one. Being absent from the volume tier and invisible in the value tier is the position we were actually in.
And a facilitator controls 62% of settled volume. We settle through one facilitator. If a single intermediary carries most of the traffic, that is the distribution channel that matters for reach, not a detail of plumbing.
A previous edition of this page cited this study by the wrong identifier and reported its revenue concentration as “top 10 merchants = 81.1%, top 100 = 92.7%”. Those were figures from a secondary summary, not from the paper. The published paper states the concentration as the top 1% taking 93.0%, and carries the study identifier 7450602. We also published a derived average of about $0.30, computed from two aggregate figures rather than measured; the study's own volume-weighted figure is $0.27. Both are corrected here, and the machine-readable edition carries the corrected values.
What we can state from first-party measurement is unchanged: the visitors are directories and liveness probes with no spending authority, and no external counterparty has been observed attempting a purchase. The gap between that and a hundred million settled transactions is not a mystery about demand — the demand is elsewhere, being served by merchants who are reachable from where agents actually look.
Two measurements of the same market, taken as a buyer would take them. Both are public and keyless, and both disagree with the picture our own traffic suggested.
| Surface | What it holds |
|---|---|
| x402 Bazaar (Coinbase, CDP Facilitator) | 16,608 payment-gated services · median asking price $0.003 · lowest $0.001 · highest $5.00 · 95 of the first 100 at or under $0.15 |
| Our own catalogue | $0.10 · $0.30 · $0.99 · $29 · $149, up to $1,499 |
| Search for our own domain inside the Bazaar | 0 results |
The Bazaar's own documentation states the mechanism plainly: it is “a catalog of payment-gated services discovered by the CDP Facilitator.” It indexes what settles through Coinbase's facilitator. We settle through a different one, so we are not in it, and no amount of pricing or copy changes that.
That matters because the Bazaar is not one directory among many. It is the discovery layer
behind the Coinbase CDP SDK, the search-for-service MCP tool, and agent runtimes
that query it. An agent using those surfaces can search 16,608 services by intent and will
never see this one. Our access log agrees from the other side: the agents that reach us are
directory crawlers and liveness probes, and the largest share of our traffic is a single
endpoint being polled.
What this corrects in our own earlier reporting. A previous edition described our price distance from the market as roughly 100 to 5,000 times the average. That compared a volume-weighted average ($0.27) against our catalogue, and a volume-weighted average is dominated by a minority of large payments: payments of $1 or more are under 8% of traffic and carry 72.5% of value. The median asking price in the Bazaar is $0.003, which is a different number telling a different story, and it is the one a merchant actually competes against. Measured against the median, our cheapest resource is 33 times out and our most expensive is over 400,000 times out.
The second correction is to our diagnosis. We had treated discovery as a content problem - publish better data, earn links, wait for crawlers - and the measurement above says the decisive gap is mechanical. A merchant can do all of that correctly and stay invisible, because the index agents query is built from who settles, not from who publishes.
The natural conclusion is that a merchant should simply settle through Coinbase's
facilitator. That was our conclusion, and then we read the issue tracker. An operator
integrated the CDP facilitator on Base mainnet, installed the full documented discovery
extension (declareDiscoveryExtension, registerExtension,
withBazaar), and completed eight successful end-to-end settlements across
five code iterations. Their service still does not appear in the Bazaar, and the
EXTENSION-RESPONSES header that the indexing guide promises has never been
emitted - not in the client response, and not when intercepting the facilitator's raw reply
inside their own worker.
The project's own roadmap acknowledges it: “multiple facilitators see dozens of endpoints that aren't discoverable in Bazaar.” The issue was closed without the service being indexed.
Correction to the paragraph that used to stand here. An earlier edition of this page reasoned that because the Bazaar indexes by settlement, switching facilitator would add us. That inference is contradicted by the evidence above, and we are recording the contradiction rather than the tidier story. Settling through Coinbase's facilitator is necessary at most; it is demonstrably not sufficient, and it carries an account requirement, an API key and a documented extension to implement before it might do nothing.
The honest summary is narrower and more useful: presence in the Bazaar is not a channel a merchant can join by doing the work. It is a gate with no published key, and the operators who have done the most work report the least access.
What we did instead, and what we can measure: submitted to the open registries that accept
submissions rather than inferring presence from settlement. One of them, x402-list.com,
probes a submitted service and publishes the result. Our submission returned
HTTP 201 with endpoints_found: 5, errors: [] - an external system
independently confirmed that all five of our paid endpoints respond, which is more than any
self-report could establish.
Stated as a limit: we do not know how much agent traffic any of these registries actually carries. Being in an index is not being called. The measured absence from the Bazaar is a fact; the claim that the Bazaar is where the demand is remains, for us, an inference from third-party reporting rather than a first-party observation.
Every earlier edition of this page reported visits, and visits cannot distinguish a client that was never asked to pay from one that was asked and declined. So we instrumented the payment path itself, recording each stage at the moment it happens:
402 issued → payment attempt → verification → settlementA stage that never occurs leaves no event, which is exactly what makes the gap a finding rather than a gap in the data.
| Stage | Count |
|---|---|
| 402 challenges issued | 0 |
| payment attempts received | 0 |
| delivered and settled | 0 |
(the payment funnel endpoint was not reachable)
This is the most useful number we have published, and it took four published corrections to arrive at it. The three earlier stages of the project measured the wrong thing: agent visits (which cannot convert), purchase-path requests (which were our own watchdog), and catalogue price distance (which explains a refusal we had not yet observed). The funnel measures the only transition that matters — between being asked for money and paying it — and it separates three situations that were previously one indistinguishable zero:
Machine-readable, free, no auth: https://growaify.com/api/v1/x402/funnel?days=7. Caller
addresses are salted hashes and User-Agents are truncated at the first bracket with any
address inside them removed, because this data is published.
Every request to this server is recorded once, at the moment the response is sent, with its path, the caller's User-Agent, the referrer, a salted hash of the address and the response code. Classification is by User-Agent, into agent, human, crawler, other and monitor. “Agent” means the User-Agent claims to be one. This edition covers the 7 days to 09 November 2026, and 11,291 requests from our own monitors are tagged and excluded from every figure on this page.
We record the response code rather than only the path, which is what allows requests we fail to be listed uncapped in Finding 4: an unmet request lives in the tail, and a “top N” view hides exactly that. Addresses are hashed with a salt before storage and no address is ever published.
Not done: no third-party analytics, no cookies, no client-side tracking, and no attempt to determine whether a caller is genuinely autonomous, because that cannot be read from a request.
Our own figures are first-party, taken from this server's request log. The market figures in Finding 5 are other people's, cited so a reader can check them rather than take our word for how they relate:
https://growaify.com/live/ for the continuously updated view.Where we have published a figure that later turned out to be wrong, the correction is stated on this page rather than quietly removed. That now includes a purchase-attempt count that was our own watchdog, a citation identifier we got wrong, a revenue-concentration figure taken from a secondary summary, and a derived average where a measured one existed.