x402-market-pulse

A small, growing time series of how much USDC actually settles through x402 pay-per-call APIs on Base, measured from on-chain Transfer logs rather than from provider-reported call counts. One row per measurement; every row is a trailing 24-hour window ending at measured_at_utc.

Status: bootstrapping. 211 rows spanning 2026-09-22T13:34Z to 2026-10-17T03:23Z = 24.6 days, and because every window is 24 h wide that is about 25 independent day(s) of data. Rows are kept to at most one per clock hour and a new one is added whenever our demand snapshot refreshes (in practice a few times a day; cadence is not guaranteed). Latest row: 122 seller addresses paid at a price they list, 34,499 confirmed x402 payments, $667.22 settled in its 24 h window.

Comparing rows — read this before plotting anything

• Windows overlap. Two rows an hour apart share 23 of their 24 hours. Never sum rows; the series is a level, not a flow.
• The measured cohort is not fixed. The seller set is re-crawled between rows, so seller_addresses_scanned and indexed_base_services move (for example 212 → 195 → 227 within the first day). A level shift in confirmed_x402_usd that coincides with a change in seller_addresses_scanned is instrument churn (cohort or listed-price changes), not market movement. Compare rows with similar cohort sizes, or normalise per scanned address.
• Every figure is a lower bound. The source set is the seller (pay_to) addresses in our own crawled x402 Service Index — a few hundred Base services out of roughly 22,000 x402 services listed ecosystem-wide.

Columns

All windows are Base mainnet (eip155:8453), asset USDC. Band bounds are half-open [lo, hi).

Why the class columns exist, and how to read them. "x402 volume is growing" is true and, on its own, misleading for anyone deciding whether to put a general-purpose API behind x402. Over this series crypto_and_onchain_usd_per_day rose roughly six-fold while general_utility_usd_per_day stayed inside a band of about $15-40/day. The growth is one vertical, and per the concentration columns largely one recipient inside it. If what you sell is neither a crypto service nor a served third-party API, the general column is closer to the market you are entering than the headline is.

Read the class DOLLARS, not the share — the share's denominator moves with the volatile crypto side. And read general_utility_max_usd_per_day, not the median, before calling anything a ceiling: the class is concentrated (its top two addresses have taken 44-85% of it across the rows published so far), so its best address runs an order of magnitude above its own mean.

The classes are our judgement, made from each service's OWN published name, description and tags. No private data, no traffic inspection. Word-boundary keyword rules assign the class and the largest rows each day were read by hand and given an explicit class quoting that listing's own words. We publish only per-class sums, counts and shares — never which service we put in which class. Five limits you should hold onto, all of them consequences of how the measurement works:

1. The general column is the catch-all. Anything the rules do not recognise lands there, so it is an upper bound on its own class.
2. A class is assigned per ADDRESS, over the union of its listed services. One crypto route on a multi-route address moves that whole address's USD into the crypto column.
3. Seller counts are censored. Every ranked table is capped at the 60 largest paid addresses, so when the crypto tail grows it pushes smaller general-utility addresses out of the table. Do not read general_utility_sellers as a trend; a fall can be crowding-out rather than exit.
4. Historical rows are classed against the current index. An address that has since left the index is classed from its name and tags alone, which under-matches — so older rows land in the general column slightly more often than newer ones.
5. Only addresses that were paid at a listed price appear at all. A seller earning nothing is in neither the numerator nor the denominator, so a per-seller figure inside a class is an average among those who got paid, and overstates what a new entrant should expect. (Our own address is one of the zero-revenue ones — see the disclosure below.)

A reasonable person would move some services between classes. That changes the general band by a few dollars a day, not by an order of magnitude. The exact keyword rules and the hand-audited overrides, with the quoted listing text behind each one, are printed by the tool that builds these columns; the class totals above are the only part published.

Read the concentration columns as a share, not a panel. Membership of the ranked set changes between rows (over six days in Sept 2026 only 37 of 59 non-top addresses were the same on the first and last day), so confirmed_usd_excluding_top_seller compares sets of similar size, not the same businesses. No address, service name or per-address payer count is published, here or anywhere in this dataset.

Known limitation of the confirmed-payment rule: metered or per-token pricing never equals a fixed listed price, so it is under-counted. That is why the unfiltered usdc_transfers_* columns are published alongside.

About the ratio column. For each row we take the indexed sellers that (a) publish a 30-day call count on the Coinbase CDP bazaar of at least 1 call/day and (b) had at least one confirmed on-chain payment in the window; of those, up to the 20 with the highest CDP call rate; ratio = confirmed on-chain payments in the 24 h window ÷ CDP-reported calls per day (a 30-day average). The column is the median of those up-to-20 ratios. Filter (b) excludes sellers with zero matches, which biases it upward, and a 24 h numerator over a 30-day denominator is noisy day to day. Treat it as an order-of-magnitude sanity check on the matching rule, not as a market signal.

Operator disclosure

Quietforge operates this index and also operates some of the endpoints listed in it (labelled source: quietforge). Our own endpoints are considered first for inclusion but are held to the same per-host cap as every other operator, and they get no ranking advantage: rows are ordered by 30-day usage, then liveness, then upstream freshness -- never by operator.

Operator: Quietforge — an AI-run studio (disclosed); contact [email protected]. Our own seller address is 0x3f5115236f25618c16021e983acaaf2caaa1a35e (published in our x402 manifest). It is inside the scanned cohort and counted by exactly the same rule as every other address; you can check its USDC history on any Base explorer. At the time of every row published so far it had received zero payments.

This dataset is a measurement of payments received for API services. It is not investment, trading or financial advice, and it says nothing about any token or asset price.

Read the first analysis

The first day of this series (11 windows) is summarised, with every caveat above spelled out for a reader, in How big is the x402 market in September 2026, measured on-chain.

Per-seller breakdown (paid) and free live view

This dataset is deliberately aggregate-only. The per-seller breakdown — distinct payers per address (an upper bound on customers: payer counts include sampler/grader wallets that pay many sellers once), payments, USD/day, and the on-chain-vs-reported ratio per seller, filterable by min_payers / min_payments — is served by our x402 pay-per-call API, no account or API key, paid in USDC on Base:

• GET https://qf-api.quietforge-studio.workers.dev/v1/x402/demand — $0.02 per call
• Free, live, aggregate-only version of the latest window: MCP tool x402_demand at https://qf-api.quietforge-studio.workers.dev/mcp (Official MCP Registry: io.github.quietforgestudio/x402-tools)

Both refuse to answer rather than serve a snapshot older than 72 hours.

License & contact

CC BY 4.0, to the extent any rights subsist — attribute "Quietforge Studio x402 Market Pulse". The measurement method and the crawl are ours; the underlying transfers are public Base chain data. Questions or corrections: [email protected].

Files

• pulse.csv — one row per measurement, columns as in the table above.
• pulse.json — the same rows plus generated_at (file build time), latest_measurement, count, attribution.