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. It is the only signal in this directory backed by an actual completed purchase. First-party listings (our own) are excluded by policy: we don't verify ourselves.

Check your endpoint

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

Why your endpoint may have failed

Across our first paid-verification waves (~450 third-party endpoints, real USDC), most of the catalog completed purchases successfully. The failures that remained were almost all one of these, in order of frequency:

• Required parameters, undeclared. The largest group. 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. Declare a request_schema on your listing and include a working sample_query so buyers can construct valid calls first.
• Listed as paid, actually free. 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.
• 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 at GET /v1/listings/:id/claim.

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.

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.