How to Vet an x402 Endpoint Before You Pay It

Step 1 — Has anyone been charged at this endpoint at all?

The single strongest filter is the CDP Bazaar's quality.l30DaysUniquePayers field: the count of distinct payer addresses that settled a payment with the endpoint in the last 30 days. Anything at or above 1 tells you the endpoint has been touched by at least one wallet; the cohort ladder below shows how quickly the population thins as the threshold rises.

Denominator: 14,689 endpoints in the current CDP Bazaar snapshot. Endpoints with a missing or non-numeric l30DaysUniquePayers field are excluded from every threshold (they cannot have crossed one) — that is why the row counts do not always sum in obvious ways against the catalog total.

Step 2 — Is the endpoint diffuse or concentrated?

A single-payer endpoint is indistinguishable, from on-chain data alone, from self-dealing. The exclusive bucket distribution tells you which shape the endpoint sits in. Read the numbers as a signal, not a verdict — a legitimate endpoint can be in the 1-payer bucket on its first week live — but the prior-probability difference between the 1-payer and ≥10-payer cohorts is large enough that a serious buyer looks at it.

Full 8-bucket histogram lives on /x402-bazaar-market-map. The buckets are exclusive: an endpoint is in exactly one row and the counts (plus no_data) sum to the full catalog. See also Report 10 for why the call-weighted view of this same distribution inverts the picture.

Step 3 — Does the pay_to walk back to a registry-owned identity?

A payment address without an identity is just an address. The ERC-8004 IdentityRegistry lets us walk from an on-chain pay_to back to a registered owner: an agentId, a resolvable metadata URI, and (for the small cohort that has any) a ReputationRegistry footprint. The join below is the reference cut we publish at /x402-paid-but-unrated; the whole summary lives in one paragraph so the endpoint-level cut can never be read without the publisher-level cut beside it.

The join, both levels, one paragraph. 14,338 earning Base x402 endpoints → 1,291 (9.00%) ERC-8004-owned → 9 rated → 0 commerce-backed; publisher level = 26 distinct pay_tos, top one 67.2% (875 endpoints), 4 rated, 0 commerce-backed. Per-publisher dedup capped at 50 on the base-resolvable count — disclosing this cap on-page is part of the finding, not an addendum.

Sample: 14,338 x402 endpoints on Base with quality.l30DaysUniquePayers >= 1 in the 2026-09-01T11:23:10Z bazaar catalog snapshot. Every share here is a LOWER BOUND — pay_to may be a treasury wallet distinct from the ERC-8004 registration owner, so the true ownership footprint of the earning cohort is at least this large. Full derivation and the byte-identical projection in the market-map JSON under reputation_join_base.

Step 4 — Is the publisher one endpoint or fifty?

Concentration at the publisher level is a different signal from concentration at the endpoint level. The same pay_to can be the receiving address for dozens of catalog entries; that pattern is not illegitimate, but it changes the interpretation of the endpoint-level numbers upstream. Our per-publisher dedup cap is 50 — we count at most that many endpoints per pay_to in the base-resolvable count so a single publisher cannot dominate the shape by listing more surfaces. The cap is disclosed on every surface it applies to, including this one.

Step 5 — Does any of it carry commerce-backed reputation?

The strongest identity signal available is a ReputationRegistry row that ties back to a real, paid on-chain job (via ERC-8183 / Virtuals ACP). Every commerce-backed agent we index (44 as of the frozen join) currently ships over Virtuals ACP, not as an x402 HTTP endpoint in the CDP Bazaar — that is why the endpoint-level commerce-backed count in the paragraph above is 0. See the commerce-backed cohort dataset for the got-paid cut in its own frame; the null overlap with the x402 endpoint cohort is a boundary condition of the two surfaces, not a data bug.

A 402 is a challenge, not a buyer

The hinge of this whole checklist. When a URL responds with an HTTP 402 Payment Required, that is a challenge: it advertises the terms of payment. It says nothing about whether anybody has ever met those terms. An endpoint can serve a well-formed 402 for years without ever being paid once, and the payer-count cohort ladder above is why we can measure that. Probe-liveness measurement — asking every catalogued URL whether it answers a probe — is a genuinely useful, genuinely different, complementary layer of signal; the sibling piece at /blog/probe-vs-paid works through why the layers are strictly nested and why they cannot substitute for one another. This page is the buyer's-side checklist for the paid layer.

Methodology and disclosures

Snapshot. All payer-cohort figures come from the CDP Bazaar snapshot at https://api.cdp.coinbase.com/platform/v2/x402/discovery/resources, fetched 2026-09-07T09:00:55Z. The 30-day windows are ROLLING — every figure moves each time the snapshot moves. Read these as the current cut, not as permanent statistics.

Exclusion. Endpoints with a missing or non-numeric l30DaysUniquePayers field are excluded from every threshold cohort AND from every exclusive histogram bucket except the no_data row — nothing is silently dropped, the missing-quality cohort has its own row so the denominators reconcile.

Dedup. On the ownership-join, endpoints-per-publisher are capped at 50 in the base-resolvable count. Disclosing the cap is the whole point: the reader knows the shape has been dedup-protected and can adjust their prior accordingly.

Lower bound. Every share on the ownership join is a lower bound; pay_to may be a treasury wallet distinct from the ERC-8004 registration owner. The real ownership footprint of the earning cohort is at least as large as what we quote, never smaller.

Not a rail comparison. This page vets a single endpoint against public data. It does not compare payment rails, protocol families, or account-abstraction stacks — those live in their own pieces.

Suggested citation: On-Chain Agent Intel. "How to Vet an x402 Endpoint Before You Pay It (2026-09-03)." Snapshot 2026-09-07T09:00:55Z. https://onchainagentintel.io/blog/how-to-vet-an-x402-endpoint. Published under CC BY 4.0 — attribution back to On-Chain Agent Intel is required.