Note · 2026-09-23

How big is the x402 market in September 2026, measured on-chain

Across the few hundred Base x402 services we index, about 11,900 to 13,500 amount-matched pay-per-call payments settle every 24 hours, worth roughly $230 to $360 in USDC, to 140 to 200 seller addresses. Measured from on-chain USDC transfers, not provider claims. First day of data, every caveat stated, dataset attached.

Short answer: in the trailing 24-hour windows we measured between 22 and 23 September 2026, the x402 services in our index settled 11,900 to 13,500 confirmed pay-per-call payments per day, worth $229 to $357 in USDC, to 142 to 199 distinct seller addresses. Taken column by column across the eleven windows, the medians are 12,697 payments, $243 settled, and 172 paid sellers; those three medians come from three different rows, not one representative window. That is small money at a high call count: the average confirmed payment is about two cents, which matches the price distribution we published on 21 September.

Coverage and metered pricing push these figures down; exact-amount matching can also push them up, by catching ordinary USDC transfers that happen to equal a listed price. So read "confirmed" as amount-matched, not verified as a customer payment. The series is less than one day old. Treat this note as the first reading of an instrument, not as a market report.

Where the numbers come from

We crawl the public x402 catalogs, keep the endpoints that answer a probe with a valid HTTP 402 challenge, and record the pay_to address and listed price of each. That gives a cohort of a few hundred services on Base mainnet with roughly 200 seller addresses. For every measurement we then scan the Base USDC Transfer logs for the trailing 24 hours and count, for each seller address, the transfers whose amount exactly equals a price that address lists. A transfer that matches a listed price is counted as a confirmed x402 payment.

The per-window results are published as the x402 Market Pulse dataset on Hugging Face (CC BY 4.0), one row per measurement. Each row is reproducible from its measured_at_utc; the table below is computed across all eleven rows.

The first day of readings

Eleven measurements, each a trailing 24-hour window, taken between 2026-09-22 13:34 UTC and 2026-09-23 03:01 UTC.

| Metric (per trailing 24 h) | Min | Median | Max | |---|---|---|---| | Base services in the index | 357 | 361 | 368 | | Seller addresses scanned | 192 | 212 | 227 | | Seller addresses that received any USDC | 156 | 181 | 207 | | Sellers paid at a price they list | 142 | 172 | 199 | | Confirmed x402 payments | 11,896 | 12,697 | 13,504 | | Confirmed x402 USD settled | $229 | $243 | $357 | | All USDC transfers of $50 or less to the cohort | $1,618 | $1,879 | $2,299 |

Each column is minimised, medianed and maximised independently across the eleven windows; no single row holds all three values in a column.

Two readings from that table matter more than the headline:

• Most addresses in the cohort receive at least one transfer matching a listed price. Computed per row, between 67% and 88% of scanned addresses were paid at a listed price (median 86%); the 67% low is the very first crawl, before the cohort settled. This does not establish that they have customers: the aggregate cannot distinguish a paying user from an operator paying their own endpoint, or from a coincidental amount match.
• Confirmed payments are a fraction of the USDC these addresses receive. The same addresses took in $1,600 to $2,300 per day in transfers of $50 or less, against $229 to $357 in exact-price matches. Some of the gap is metered or per-token pricing, which never equals a fixed listed price and so is never confirmed. Some of it is ordinary USDC traffic to a wallet that also happens to sell an API. The true figure very likely sits between the two columns, though a listed price above $50 would fall outside the upper column too. We publish both so you can pick your own assumption.

Why the figures are biased, in both directions

• Coverage. Our index holds a few hundred live Base services. The two large catalogs listed about 22,000 entries when we fetched them (15,191 on the Coinbase CDP bazaar and 6,599 on PayAI on 21 September), though a large share of those are duplicates, testnet stubs, or dead hosts. We only count sellers we have crawled and probed.
• One chain, one asset. Base mainnet, USDC. Solana x402 traffic and any other asset are not measured.
• Exact-price matching under-counts. Metered, per-token, or discounted payments never equal a fixed listed price, so they are never confirmed.
• Exact-price matching also over-counts. A transfer that happens to equal a listed price is counted whether or not it was an API call, and on sub-cent prices such collisions are plausible. The dataset's validation column (median_ratio_onchain_over_provider_reported, on-chain matches divided by provider-reported calls per day for up to 20 sellers) came out above 1.0 in six of the ten rows where it ran, so the matching rule catches more than the providers report. The confirmed count is a lower bound on coverage and an upper bound on match precision.
• Cohort churn. The seller set is re-crawled between measurements, so the scanned-address count moves (192 to 227 in the first day). A change in settled USD that coincides with a change in cohort size is instrument churn, not market movement. Compare windows with similar cohort sizes, or normalise per scanned address.
• Settled USD is not a smooth series. Between the 18:01 and 23:42 UTC windows on 22 September (a 5.7 h gap in measurement) settled USD fell from $355 to $241 while the payment count rose from 12,697 to 13,415 and the cohort grew from 193 to 227 addresses. That is a listed-price or cohort change, not a demand collapse. Do not quote the $229 to $357 range as daily variance.

How not to read the dataset

• Windows overlap. Two rows an hour apart share 23 of their 24 hours. Never sum rows. The series is a level, not a flow.
• It is one day old. Eleven overlapping windows are not eleven independent observations. Weekly or seasonal patterns cannot be read from it yet. The dataset grows by at most one row per clock hour whenever our demand snapshot refreshes, which in practice is a few times a day with no guaranteed cadence.
• We are in the cohort. Quietforge operates this measurement and also sells x402 endpoints that are listed in the same index. Our own address is treated exactly like every other seller's, and for transparency: our own confirmed payments are zero in every window so far. Our seller address is 0x3f5115236f25618c16021e983acaaf2caaa1a35e; check it on any Base explorer rather than taking our word for it.

Use the data

• Download the series as CSV or JSON from the Hugging Face dataset, or browse both of our x402 datasets in the x402 agent payments collection.
• The per-seller breakdown behind the aggregate (payments, distinct payers and USD per seller address) is the paid /v1/x402/demand route on the Docs API. The free x402_demand tool on our MCP server returns the aggregate.
• The endpoint catalog the cohort is drawn from is the x402 Service Index.