The CDP Bazaar halved while the x402 corpus grew
Coinbase's x402 catalogue shrank 43.5% in under a month. The wider resource corpus grew over the same window. Here is what the crawl history shows and why the two are not in conflict.
DIRECT ANSWER
Between 10 July and 5 August 2026 the CDP Bazaar fell from 25,843 services to 14,599, a 43.5% drop. Over the same window the 402 Index grew from 74,997 to 85,418 entries and the TOLL·402 canonical corpus grew from 78,287 to 89,057 resources across 3,306 provider groups. One catalogue contracted; the discoverable ecosystem did not.
Key takeaways
- A registry count measures one registry, not the size of the ecosystem behind it.
- The contraction was real and verified before it was accepted, not silently absorbed as a crawl failure.
- Cross-source corpora survive a single upstream catalogue changing its mind; single-source counts do not.
What the crawl history records
TOLL·402 records upstream catalogue sizes on every discovery run and appends them to a dated history file, so a change in a source is visible as a change rather than inferred after the fact. The 10 July capture put the CDP Bazaar at 25,843 HTTP services and the 402 Index at 74,997 entries. The 5 August capture put the Bazaar at 14,599 and the Index at 85,418.
The two numbers moved in opposite directions over the same 26 days. A catalogue lost roughly eleven thousand services while an independent registry gained roughly ten thousand entries. Because both figures are captured by the same probe on the same schedule, the divergence is a property of the sources rather than an artifact of when each was measured.
| Measure | 2026-07-10 | 2026-08-05 | Change |
|---|---|---|---|
| CDP Bazaar services | 25,843 | 14,599 | -43.5% |
| 402 Index entries | 74,997 | 85,418 | +13.9% |
| Canonical resources | 78,287 | 89,057 | +13.8% |
| Provider groups | - | 3,306 | - |
Why a shrinking source is treated as a fault by default
A crawler that accepts any number its source returns will eventually publish a catastrophe caused by an upstream outage. A paginated API that fails halfway through, an authentication change, or a rate limit can all present as a smaller catalogue that looks perfectly well formed. The safe default is to refuse the run and keep the previous corpus.
That default is also why a genuine contraction needs an explicit override. The refresh that accepted these numbers ran with a deliberate acceptance flag after the drop was confirmed against a second capture taken eleven minutes apart, both of which agreed within two services. A single reading would not have been enough to distinguish a real catalogue event from a partial fetch.
What the corpus did while the catalogue fell
The canonical corpus is built from more than one source, so the loss of Bazaar entries did not translate into a loss of resources. After the refresh the corpus holds 89,057 canonical resources drawn from 14,599 Bazaar inputs and 85,418 Index inputs, deduplicated across 100,017 source associations, with 11,049 resources present in more than one source.
That cross-source overlap is the reason the corpus grew rather than shrank. A resource that appears in both the Bazaar and the Index survives the Bazaar dropping it, because the Index association still carries it. Only a resource that existed in the Bazaar alone and nowhere else could have disappeared entirely, and the net movement shows those were outnumbered by new Index entries.
The evidence was rebuilt, not carried over
A corpus that grows by ten thousand resources without re-verifying anything would report stale evidence against new records. The refresh re-checked 852 new origins and 18,692 route quotes so that every resource carries a current origin and quote outcome: 89,057 of 89,057 on both.
Confirmed exact-route quotes rose from 14,002 to 19,259 across the same refresh. Priced routes rose from 29,697 to 36,903 and distinct offers from 17,014 to 24,160. These are quote observations, not settled payments, and the distinction is load bearing everywhere it appears.
- Origin outcomes recorded: 89,057 of 89,057
- Quote outcomes recorded: 89,057 of 89,057
- Confirmed exact-route quotes: 19,259
- Routes attempted: 75,604; not safely testable: 11,248
A verification bug the refresh exposed
Re-crawling at this scale surfaced a fault in how cached quote outcomes were reused. A route previously probed as a concrete URL can be reclassified when upstream starts publishing a route template for it, because a templated path can no longer be called honestly with a guessed value. Nine routes carried a confirmed outcome from an earlier probe while newly classifying as templated.
The cache was keeping those outcomes because they fell inside the freshness window, and index validation correctly rejected the result. Cached outcomes are now re-derived whenever template safety no longer matches the recorded classification. The failure mode is worth naming because it only appears when a source materially changes its shape, which is exactly what happened here.
How to read a registry count
Registry totals are the most quoted numbers in the x402 ecosystem and among the least comparable. A service in one catalogue may be a provider, a deployment, a tool or a single route depending on who registered it. An entry count therefore measures registration behaviour at least as much as it measures supply.
The practical reading is that a catalogue number describes the catalogue. It supports statements about what one registry lists on one date. It does not support statements about how many services exist, how many are reachable, or how many would return a valid payment requirement if called.
- Ask which unit is counted: provider, service, deployment or route
- Ask when the count was captured and by whom
- Ask whether the source deduplicates against any other registry
- Treat a count from a single registry as a lower bound on nothing
What this does and does not prove about adoption
Nothing here shows that demand rose or fell. Discovery counts, quote confirmations and price publications all describe supply and its observability. A provider can register a thousand routes that no agent ever calls, and a valid 402 requirement proves a payment wall exists rather than that anyone paid it.
The honest claim is narrower and more useful: a headline catalogue figure can halve without the underlying discoverable supply shrinking, which is a direct demonstration that registry totals and ecosystem size are different quantities. Any argument about x402 adoption resting on a single registry count inherits that weakness.
What we changed as a result
The daily probe that captures upstream catalogue sizes now runs independently of the crawl, so a source moving is recorded even on days when the corpus is not rebuilt. The crawl gates on source completeness rather than on a third-party claim about how many records should be present.
The history file is published alongside the corpus so the same comparison can be run by anyone. Numbers in this report are as of the 5 August 2026 refresh; the canonical figures come from the generated resource index and quote summary rather than from any narrative written during the run.
Related directory entries
Sources and methodology
TOLL·402 distinguishes public claims, registry discovery, unpaid quote checks and settled paid-call verification. Sources below support the visible claims; presence in a registry is not treated as verification.
- TOLL·402 discovery corpus — Normalized crawl output the canonical corpus is built from.
- 402 Index API — Independent public registry used as a second crawl source.
- x402 Bazaar — Coinbase Developer Platform catalogue whose service count contracted.
- TOLL·402 resource explorer — Search across every canonical resource with its evidence level.
- x402 rate card — Provider-weighted price benchmarks built from the same refreshed corpus.