How entries are checked

Everything here is built from pages our research agent opened. Nothing was bought, paid or posted.

Verdicts

Each row stores one or more quotes copied from the source page. The research build re-reads the saved page text and refuses any quote it cannot find. No page, no entry: rows without a readable source are shown as UNVERIFIED.

API prices

For L402 endpoints the agent sends one unpaid request, reads the Lightning invoice in the HTTP 402 response and decodes its amount. For x402 it reads the USDC amount in the 402 challenge. No invoice was paid.

Votes

Votes are shared across visitors. You get one vote per entry per browser, and the server also limits how many new votes one network can add per hour. A vote means “I agree with this verdict” (or “useful” on APIs); it never changes a verdict. If the vote service is unreachable, your vote is kept in this browser only and the button says so.

Refreshing the data

A daily refresh job discovers new candidates from public lists (402 Index, awesome-x402, awesome-nwc, awesome-cashu, awesome-mcp-servers, BitPay and the Bitcoin acceptance ledger), re-opens the saved evidence pages, re-probes endpoints and stamps lastChecked. Any verdict that changed is flagged in a change report for human review before it is published.

Where the lists come from

New entries are tagged “new”. YES on a service needs its own page (or an unpaid 402 challenge we saw) to say an agent can pay. Candidates whose pages were unreachable, silent or only “planned” are left out instead of guessed. Bitcoin merchants come from public acceptance lists, and their own payment page has to mention Bitcoin when we re-open it; BitPay rows cite the BitPay merchant page and are KINDA when only a gift card can be bought.