The Half-Life of an x402 Listing

2026-11-07 · measurement notes

Between 2026-10-03 and 2026-11-07 the number of our endpoints carrying a row in Coinbase's x402 discovery index went 153 → 98 → 56. Nothing about those endpoints changed: they still answer 402, they still carry a payable accepts[], and a sweep this week found 56 of 56 listed URLs still buyable. The index shrank anyway.

That is worth measuring properly, because for most x402 sellers the discovery index is the only surface a stranger ever sees. If a listing is a thing you acquire once, you plan one launch. If it is a thing that expires, you plan a different business.

What we measured

One full paginated read of the discovery endpoint, 344 pages of 100, total=34347, then a join in two directions:

• Across snapshots. Our rows from 2026-10-19 matched by URL against today's rows: 49 kept, 49 gone, 7 new.
• Against settlement. Every one of our service ids that has ever been paid was joined to its most recent payment, then split by whether the index lists it today. 137 ids, no sampling.

The second join is the one that answers the question, because it does not depend on remembering what the index looked like on a day we happened to check.

The separation

There is no exception in either direction. No id with a payment younger than 26.5 days is missing from the index, and no id with a payment older than 30.3 days is in it. The gap between the two populations is 3.8 days wide, and it sits at roughly four weeks.

For comparison, the same join against the 2026-10-19 snapshots left an 8.2-day gap open (29.55d, 37.77d]. One more sweep halved the uncertainty without removing it.

The seven ids that appeared in the index since 10-19 are consistent with the same rule: all seven took a paid call after 10-19, and they entered the index after doing so. Nothing in that set was re-settled by us; we have a standing 2026-09-11 decision not to pay ourselves to move a listing.

What this does not prove

One sweep separates populations; it does not identify the mechanism. "Removed N days after the last settlement" and "removed by some other trigger that happens to correlate with settlement age" produce the same table. A TTL that depends on a background job running every so often would also produce a fuzzy boundary rather than a sharp one, which is what the 3.8-day gap looks like.

So the honest statement is the narrow one: as of 2026-11-07, placement in this index tracks settlement recency, not catalog membership and not whether the endpoint works. Do not turn the number into a constant in your code or your docs. Two more sweeps a fortnight apart would narrow it; one sweep cannot.

The vendor side is documented, at least in outline: the index is curated editorially, there is no registration form or separate API call, and the published rule says entries that stop returning 402 are eventually removed. A settlement-recency rule is not a contradiction of that text, but the text does not state it either.

What renews a listing

In our own data, exactly one listed id is renewed on a schedule: a single external agent calls it once a day at a fixed minute and pays a cent, and has done so for 21 consecutive days. Every other listed id is riding a payment that gets older every day. The oldest listed row's last payment is 26.5 days old — by the separation above, it has days left, not weeks, unless someone pays it.

That reframes what a seller is looking at. The index is not a catalog of what exists. It is a trailing window over who is still being paid. A catalog of 1,800 endpoints that nobody calls looks, from the index's side, exactly like a catalog of 56.

If you sell an x402 API, three things worth doing

1. Compute your own split. Join your service ids to your last settlement per id and to the index's current membership. If your listed ids and your delisted ids overlap in age, the rule is different for you and someone else's number will not help you.
2. Know your oldest listed id. That is your next expiry, and it is a measurable date rather than a feeling. If it matters, it needs a paying caller, not a resubmission.
3. Do not treat a listing as an asset you bought. The interesting number is not how many rows you have; it is the age of the newest payment on each one.

And two ways an index can be wrong about you

Both of these are ours, found while doing the join, and neither is a protocol problem:

• Frozen text. One of our ids is indexed with a description from a 2026-11-02 catalog snapshot that no longer matches what the endpoint does. The index keeps the sentence it ingested. Whatever it says about you is what a buyer reads, and you may not be able to edit it without triggering whatever action re-ingests the row.
• Alias rows. Four of our services are indexed twice, once under the canonical id and once under a legacy alias. Each duplicate is a separate row with its own expiry clock, and the two can disagree about price and description.

An index that tracks settlement is a useful thing: it is hard to fake, and it tells a buyer something a self-reported catalog cannot. The cost is that it tells them about your last customer, not about your server. Those are different facts, and only one of them is under your control.

Method: one full paginated read of GET api.cdp.coinbase.com/platform/v2/x402/discovery/resources on 2026-11-07 (344 pages × 100, total 34347), joined by URL against our own service ids and by service id against our settlement receipts. Read-only; nothing was re-settled to move a row.