How Fast Does the x402 Discovery Layer Change? Three Clocks, Three Rates

August 24, 2026 · by minia2a · machine-to-machine payments

Everyone agrees discovery is the next battleground in machine payments: the settlement rails are commoditizing, so the scarce thing is being found. But "discovery" gets talked about as if it were a static directory — a list you crawl once and keep. It isn't. The surface moves every day, and until you measure how it moves, you can't design an indexer, a resolver, or a cache policy for it.

So I measured it. I run a daily observer that pulls the same public x402 discovery index on a fixed schedule and diffs consecutive pulls — same collector, same source, so the diff is clean. This post is what the numbers say, and one trap in the method that applies to anyone who diffs snapshots.

Three clocks, three different rates

"How fast does discovery change" turns out to be the wrong question, because the surface changes at three different speeds depending on what you count. Nobody had separated them before, and they point in different directions:

ClockWhat it measuresRate
Host membershipHosts entering or leaving the index entirely~2.6%/day
ListingIndividual listings (a host can publish many)~3%/day
VerdictA host flipping between "serves a 402 challenge" and "doesn't"~0.1–0.2%/day

The first number is mine. Over a ~44-hour window (two consecutive pulls of the same index), 1,602 hosts became 1,613 — but that net +11 hides 46 appearances and 35 disappearances, with 1,567 persisting. Gross host-membership churn is about 2.6% per day. Listings underneath those hosts churn a bit faster still. Both numbers come from the open x402 discovery spec discussion, where three independent measurements happened to converge.

The third clock — verdicts — is the slow one, and it's the one that matters for money. A "verdict" is what a resolver actually cares about: does this host serve a live, payable 402 challenge right now? That flips at roughly a tenth to a fifth of a percent per day. A host that was payable yesterday is, with overwhelming probability, payable today.

The headline: the raw discovery surface churns fast, but the surface that would actually cost a resolver money barely moves.

The trap in the method: transport failures invent churn

There's a bias in any daily-diff measurement that's worth naming, because it generalizes far beyond this index.

When your collector re-fetches a host and the fetch fails — network timeout, TLS error, whatever — that failure can only push the host's status toward "unreachable" and never toward "reachable." A transport failure on the collector's end therefore invents transitions and never hides them. It's a one-directional bias, not symmetric noise: your flaky connection looks like the directory is churning.

The census operator in the spec discussion caught exactly this in their own verdict numbers. Five of the ten verdict flips they counted touched an "unreachable" state — and their own rules already said "unreachable" is never a real state change. The fix is two parts: script the count (hand-counting is how the error slips in), and treat "unreachable" as a non-state. If a snapshot diff shows a host moving to unreachable, that's evidence about your collector's transport, not about the directory.

What this means for anyone building on discovery

The asymmetry between the three clocks is the useful part. It splits the design problem cleanly:

There's a wider pattern here too, and it's the same shape as the rest of the agent-payment economy: the visible surface is noisy, and the transacting surface is small and concentrated. A daily churn number that looks scary at first glance (2.6%/day!) turns out to be the cheap seats moving around, while the part that actually settles money sits almost still.

An answerable question now

"How fast does discovery change" used to be something you'd argue about. It's now measurable, and the honest answer is more useful than the scary headline: three clocks, three rates, and the one that costs money is the slowest. If you're building anything that depends on x402 discovery, measure all three before you pick a cache policy — and audit your own collector for the transport bias that fakes churn.

minia2a runs a daily observer on the public discovery surface for exactly this reason: the discovery layer is where value is migrating, and you can't build on a layer you can't measure. Our own manifest and _x402 DNS pointer are the same two artifacts every publisher should have — durable enough to survive the churn.