For sellers: paid verification

We pay listed endpoints real USDC on Base and inspect what comes back. An endpoint that delivers valid data for real money earns $ paid-verified — shown on its listing, in API and MCP results, and as an embeddable badge, with the settlement transaction hash published as on-chain proof. Every outcome, including the failures and the ones caused by our own client, is published at /stats. We list nothing we operate: our own 17 remaining first-party listings were retired on 2026-08-25 (reason first_party_retired in the changes feed). A directory operator shouldn't be a seller in its own index — and we never verified our own listings even while they existed.

Check your endpoint

Find your listing id via /v1/discover. Verified listings can embed the badge:

Why your endpoint may have failed

Across our paid-verification waves (3,471 third-party endpoints, real USDC), most of the catalog completed purchases successfully. Counting each endpoint by its most recent attempt, the failures that remained were almost all one of these, in order of frequency (full outcome table: /stats):

• Listed as paid, actually free. The largest group. The endpoint returns 200 with no payment required while the listing declares a per-call price. Fine either way — but one of them is wrong; fix one or the other.
• Required parameters, undeclared. The most common paid failure we measure. Your payment gate fires before request validation, so a paid request without the right query params commits a payment attempt and then receives a 400/422 — the buyer's money is gone and they have no recourse, while your endpoint still passes every liveness probe. In our 2026-08-26 wave, 99 of 359 endpoints did this, usually naming the missing parameter in the error body. It is a one-day fix: one operator shipped it within a day of being told and re-verified with a real paid call. Declare a request_schema on your listing and include a working sample_query so buyers can construct valid calls before paying — and validate the request before you settle.
• Correctly-paid requests still refused with 402. Usually a facilitator or verification config mismatch on the server side; sometimes a protocol-version mismatch with the buyer's client (see below).
• Protocol version compatibility. x402 v2 servers put payment requirements in the base64 payment-required header; v1 puts an accepts array in the 402 body. Both are correct — and we say this from experience: our own scout initially only read v1 bodies and we initially misflagged 192 v2-conformant servers as broken before catching and correcting it. The practical takeaway cuts both ways: much deployed buyer tooling is still v1-only, so serving both forms maximizes who can actually pay you. A correct v1 body looks like: {"x402Version":1,"accepts":[{"scheme":"exact","network":"eip155:8453", "maxAmountRequired":"10000","resource":"https://your.api/route", "description":"...","mimeType":"application/json","payTo":"0x...", "maxTimeoutSeconds":60,"asset":"0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913"}]}

After you fix it

Liveness probes observe your 402 terms continuously, so protocol fixes are noticed within minutes. Paid re-verification runs in occasional waves, as resources allow; a fixed endpoint earns the badge on the next pass. If you've fixed a payment-path bug and want to flag it, or want your listing claimed to your contact address: hello@nohumans.directory or the claim flow (GET /v1/listings/:id/claim explains it).

Verification requests from our scout always identify themselves with an X-Verified-By: nohumans.directory header. We never probe with hidden identities, and we publish what verification does and does not prove on every listing page.

What does listing cost?

The first 5 listings per registered domain are free. Each further new listing is $0.25 USDC on Base, paid over x402 on the same POST /v1/listings: the unpaid call answers 402 with the terms, the paid retry returns your listing. Edits, claims and resubmitting an endpoint that was listed before are free, and a submission that fails validation is never charged. The fee buys the entry, never a status or a place in the order. Full rule.

How long until my listing is verified?

Measured, not promised: of 169 listings submitted through the public form in the seven days to 2026-09-09, the median time from submission to verified was 12 minutes, and 92% earned it inside 15. New submissions sit in a priority tier and are probed on nearly every cycle, so the badge is three consecutive clean probes away. The slowest in that window were submitted on 2026-09-03, before that tier existed.

This is the free path, and it is the only path to the badge. Nothing on this page can be paid for: what money buys is when a paid purchase happens (below), never what it finds and never a status.

My payment address changed. What do I need to do?

Nothing. We read the payment address from your live 402 challenge on every probe, never from what you typed at submission, so a rotation is picked up within a probe cycle without you telling us. (A seller asked us this by email on 2026-08-31 and noted there was no documented update path — correct, because there is nothing to update.)

What happens automatically: when the address changes, the listing's reputation resets — score, probe count and failure streak all zeroed — and its status drops to unverified. That is deliberate: a score earned by one payment destination says nothing about a new one. It re-earns verified on clean probes: because the reset starts the score at zero, that takes about sixteen consecutive passes (22 of the 24 resets in the week to 2026-09-23 took 11 to 20; correction #23). Such a listing is re-checked on every probe run while it climbs, so that is about half an hour of clean answers. The rotation on 2026-08-30 mentioned above was detected in the same probe cycle and back to verified eighty minutes later.

We never change a payment address because someone emailed us, and no directory should: that is exactly the shape a payment hijack takes. To change listing metadata that is not visible in your challenge — name, description, schemas, sample query — use PATCH /v1/listings/:id with your claim token in the x-claim-token header.

Paid verification — $3 for one purchase, $5 for three

Waves buy from the catalogue on a budget, so a route can wait weeks for its first purchase and longer for its second. You can buy the turn. Two plans, both for listings quoting up to $0.50 per call:

• single — $3 USDC on Base. One real purchase from your endpoint within 24 hours.
• pack — $5 USDC on Base. Three real purchases inside 30 days, the first within 24 hours, the other two when we choose. This is the plan that can move the badge: two deliveries at least 48 hours apart earn paid-verified ×2; two deliveries across a payment-address change earn held through change; deliveries spanning three or more weeks earn N wk.

Above $0.50 per call, write to hello@nohumans.directory and we price the purchases by hand.

What the money buys is when, never what. Every purchase runs the same code as a wave, and publishes whatever it finds: settlement transaction, delivery outcome, failure reason. That includes the bad news — an endpoint that delivered once and fails a later purchase drops to failed re-buy, in red, on a public badge. No plan can prevent that, and that is exactly why the gold ones mean something. Ranking, verdict, status and score never know who paid. A failure caused by our client (wrong verb, quote parsing, payload) does not count against your plan and is re-run.

Sold only to the listing’s owner. Anyone can read the price — the unpaid request answers an ordinary 402. The paid request must carry your claim token in the x-claim-token header, the same one you use to edit the listing. We will not sell purchases against a listing to anyone else: a competitor must not be able to buy three attempts against your route hoping for a red badge. No token yet? GET /v1/listings/:id/claim explains the flow.

Fulfilment is manual in this phase and runs happen on weekdays; the record shows progress (purchases_done of purchases_total). One open plan per listing at a time. Rule and what it does not establish: /methodology#verify-now.

If your endpoint serves a different address on each request, we detect that too and stop resetting, because there is no stable destination to reset to. The listing is flagged payto_unstable and agents reading it are told to verify the address in the challenge they receive immediately before paying, rather than trusting an earlier one.

The scout address

Paid verifications settle from 0x54E163e9B8eDDa194D83F46AdD921bfA5fc5f4E0 (nohumans-scout). If you received a small USDC payment from it, that was us verifying your endpoint with a real transaction — the result is on your listing page. Verification is point-in-time, not a subscription: re-verification happens in occasional waves as resources allow, not on a schedule. You never need to do anything to receive it, and it cannot be purchased.

state of the network · methodology · stats · sellers · integrate · terms · privacy