A marketplace listing is a lease, not a trophy

November 12, 2026

Six weeks ago we counted our rows in the CDP x402 Bazaar index: 153. This week the same count read 56. In between, the index itself nearly doubled.

Date	Bazaar resources (total)	Our rows
2026-09-29	19,126	154
2026-10-03	24,418	153
2026-10-19	25,800	98
2026-11-08	34,188	56
2026-11-12	33,655	56

Read naively, that is a collapse: our share of the index went from about 0.8% to about 0.17%. Read correctly, it is something more boring and more useful. The rows that left are still selling.

The rows that dropped out still answer 402

We took the 49 URLs that disappeared from the index between the 19 October and 8 November snapshots and requested each one:

GET https://minia2a.uk/x402/<slug>
→ 402 Payment Required, accepts[0].amount, payTo, network all present
49 / 49

Every one of them is payable, priced, and unchanged in behaviour. They are simply no longer findable through that index. The four most expensive endpoints we run — integration-audit at $50, ai-audit at $20, payment-audit at $5, content-studio at $3 — are all in the dropped set today, and all four still hand a buyer a valid challenge.

This is the distinction that costs builders the most time: can this endpoint be paid and can a stranger find this endpoint are two separate properties maintained by two different systems. A 402 is your code. A directory row is somebody else's crawler deciding you were recently interesting.

What actually writes the row

On 7 November we joined every service id of ours that had ever been paid (137 of them, no sampling) to its last payment, then grouped by presence in the index. One full paginated read, 344 pages.

In the index?	Rows	Last paid call, age at join
yes	52	0.4 – 26.5 days
no	85	30.3 – 89.4 days

Zero exceptions in either direction. Nothing that had been paid within 26 days was missing; nothing paid more than 31 days ago was present. The boundary sits somewhere in a 3.8-day gap between the two populations.

This is an observed separation, not a proven TTL. One snapshot cannot distinguish "removed at exactly N days" from "some other trigger correlated with settlement age". A 3.8-day gap looks more like a periodic sweep than an exact expiry, and we do not write the 26.5 / 30.3 numbers into code or docs as constants. The only safe prediction is directional: rows age out, and a payment resets the clock.

The one listing that never ages out

In the same dataset, exactly one of our listings was being renewed on a schedule: an external agent pays 1¢ for x402-format-bytes every day around 04:30Z. It had done so 21 days running. Every other row was living on an ever-staler meal.

That is the whole mechanism in one line. Discovery surfaces of this kind are fed by settlement: the index row is a snapshot written when someone pays, and it carries the timestamp of that payment. Keep paying and the row stays current; stop and it drifts out roughly a month later. The catalog the buyer sees is a side effect of the payment stream, not a registry you join once.

The same mechanism explains something that looked like a bug earlier: 20 rows sat in the index advertising prices up to 5,000× below what the endpoint actually charged, and stayed that way for weeks. Of course they did. A row that only refreshes on payment refreshes never for endpoints nobody pays, in either direction.

What we did not do about it

The tempting fix is to pay yourself. A self-settlement resets the row, and at 1¢ it looks cheap. We did not do it, for three reasons:

It is not free. Each settlement pays a facilitator fee and gas, and it is real USDC moving between wallets we control.
It corrupts every downstream number. Self-settlements land in the payment ledger, in on-chain counts, and in any adoption metric that counts "distinct paying wallets" — including the ones we publish.
It buys a row, not a buyer. A refreshed row that nobody calls ages out again on the same schedule. You would be paying rent on an empty shop.

If you do choose to pay for presence, budget it openly as marketing spend, keep it in a wallet you already exclude from customer metrics, and label it — the same discipline you would apply to any paid placement. What you should not do is let it quietly inflate the numbers you report.

What a seller should actually check

Separate your two dashboards. "Is my endpoint payable" is a test you can run in one request. "Is my endpoint findable" is a query against each discovery surface, and each one has its own admission and eviction rule.
Record where you are listed, and when. A row is not a fact about your service; it is a fact about your last settlement, with a date on it. Snapshot the index periodically and diff it — the diff is the only honest listing metric.
Do not read "not listed" as "broken". We spent an afternoon confirming 49 rows were still payable before publishing this. The default assumption in the other direction — that a missing row means a dead endpoint — would have been wrong 49 times out of 49.
Price for the gate, not for the index. The index is a stale snapshot by construction. The number a buyer will actually be asked to sign lives in the 402 you return, and that is the only one you can be held to.

The lesson we are applying to ourselves

We are not going to chase the index back up with self-payments. The count is a measurement of demand, and a measurement you can buy is not a measurement. What we can do is keep the underlying surface healthy — every dropped row still answers 402 with a correct price, correct payee, and correct rail, which the parity check confirms for all 56 rows still listed and for the 49 that left — and let the count say what it says.

If you run an endpoint on any x402 discovery surface, the question worth asking is not "am I listed". It is "when was I last paid, and what does that date predict about next month".

All figures above were read on the dates shown: catalogue totals from the Bazaar discovery index (paginated sweep, 258 / 342 / 336 pages), our row counts from the same sweeps, presence-vs-settlement join from our own payment ledger, and the 402 checks from plain unauthenticated GETs. Nothing above was estimated.

← All posts