For the past several weeks I've run a consecutive-daily observer against the largest public x402 discovery index — the Coinbase CDP Bazaar's discovery endpoint. Every pull is saved, every diff is checked against the pull's own accounting, and the same collector has run every time. The point was to answer one question: how stale is an agent-service index, really?
The answer is: staler than the "catalog" framing suggests. About 2.6% of hosts churn every day.
A catalog implies a shelf: things are put on it, and they stay until someone removes them. A discovery index is not that. It's a series of snapshots taken from crawling the internet, and between snapshots the underlying hosts move, flap, and die.
Across a ~44.5-hour window of consecutive pulls, the host set moved like this: 46 hosts appeared, 35 disappeared, 1,567 persisted. That's ~81 hosts changing state over ~1,600 — roughly 2.7% gross churn per day, even though the net count only grew by 11. Net movement hides the turnover: a flat headline number can be the sum of a lot of coming and going.
This is the part I keep coming back to, because it means a single "freshness" number is meaningless. There are at least three different things a discovery index can churn on, and they move at wildly different rates:
| Clock | What changes | Rate |
|---|---|---|
| Listing churn | A host adds or removes a listed resource | ~3%/day |
| Host-membership churn | A host enters or leaves the index entirely | ~2.6%/day |
| Verdict churn | A host's liveness/payability verdict flips | 0.13–0.66%/day |
The third clock — whether a host actually answers a payable 402 today — is the quietest of the three, and it's the one that would actually cost a resolver money if it got it wrong. Listing and membership churn are loud; the signal a paying agent depends on barely moves. That asymmetry is the interesting part.
The churn isn't evenly distributed. The disappear side skews toward free-tier platform subdomains — vercel.app, railway.app, workers.dev — where a single account re-deploying, or a platform suffix going dark, takes a handful of hosts with it in one window. That means host-level churn overstates the number of independent things that actually changed: collapse by platform suffix and 16 host transitions can resolve to ~5 independent operators.
It also means "absence from the index" and "doesn't exist" are not the same statement. A host can drop payment gating and fall out of a 402-only index; a host can re-platform and vanish; a host can be live and payable and still not be indexed at all. None of those are evidence the endpoint is gone — they're evidence the index is a lagging, lossy view of the network.
An agent that treats a discovery snapshot as ground truth will, within days, be holding a list where some fraction of the entries are already wrong. So the practical requirements for anyone building on agent-service discovery are concrete:
The payment rails are getting solved — the settlement, the 402 challenge, the wallets — all of it is becoming infrastructure. The part nobody has nailed is discovery: knowing, at the moment your agent needs a capability, which endpoint is live, what it costs, and whether it'll actually answer. That's a freshness problem, not a listing problem, and the 2.6%/day churn rate is the number that makes it concrete.
That's the problem minia2a works on. Not "we have the most endpoints" — a number that's true for a snapshot and wrong for a network — but discovery that's honest about churn, that verifies before it recommends, and that lets an agent try an endpoint before it pays for it.
Build agents that pay for APIs per call.
Explore minia2aData: consecutive-daily pulls of the Coinbase CDP Bazaar discovery endpoint, saved and diffed with pull-level accounting (claimed total = counted rows, 0 unexplained). The "three clocks" and churn rates are from this observer's own measurements; verdict-churn figures come from the discovery-spec review thread on the x402 Foundation repo.