What these measurements mean
1.What L0 measures
An L0 probe sends one request to a catalog-listed endpoint using the HTTP method the catalog entry itself declares, with no payment attached. Under the x402 protocol a compliant server answers HTTP 402 Payment Required with an accepts array before executing anything, so the probe is free, side-effect free, and observable. We record: whether 402 came back, whether accepts parses, whether the advertised price, asset, network and receiving address agree with what the catalog declares, and the latency — each with a timestamp and a response digest kept as evidence.
2.The verdict vocabulary
pass — the probe received 402 and the challenge was consistent with the catalog declaration. fail — the probe contradicted that: no 402 (any other status), DNS/TLS/timeout failure, an unparseable challenge, or a challenge whose price or receiving address contradicts the catalog; the specific reason code is always recorded. unverified — the entry does not declare enough to measure (most commonly no declared method — probing with a guessed method reports false deaths), or the evidence threshold below is not met. unverified is not a failure and is never counted as one.
3.Publication gate
A single failing probe is never published as fail: transient network conditions — including ours — are indistinguishable from a dead endpoint in one sample. The register shows fail only after 2 consecutive failing probes; until then the published state is unverified. Every underlying probe, including single fails, remains visible in the endpoint's history with its evidence.
4.Delisting detection
The public discovery catalog is fetched in full daily. An endpoint present on an earlier day and absent from a complete fetch is recorded as delisted, with the before/after values kept on the event. On any day our own fetch is incomplete (fetched count below the catalog's reported total), no delisting judgements are made — a gap in our data must never read as a disappearance in yours. Reappearance is recorded as relisted. A fall in the catalog-reported 30-day call count of 70% or more, from a base of at least 100 calls, is recorded as settle_drop — a factual observation of the catalog's own telemetry, not a judgement.
5.What L0 cannot measure
Without purchasing, we cannot observe whether the endpoint actually delivers what it sells, the quality of what it returns, or settlement behaviour after payment. An endpoint with L0: pass has a standing payment wall — nothing more is claimed. L1 and L2 below cover settlement and conformance; L3, opinion on the quality of what is delivered, is not built and nothing on this site presents one.
6.What L1 measures
An L1 purchase is a real transaction: one covert purchase per endpoint, at most once per 6-day window, targeting endpoints whose most recent L0 verdict is pass, prioritised by real observed demand (30-day payer and call counts reported by the catalog). We request unpaid first to read the 402 challenge, then select a payment option and refuse to proceed unless every one of these holds: scheme exact, network Base, asset canonical Base USDC, and a price that matches what the catalog declared when we chose the target. Any deviation — a different asset, a different chain, a higher price — is recorded as a refusal, never paid. A hard per-purchase ceiling ($1.00) and a daily budget ($25) are checked against a database ledger, not memory, before every signature, so a restart or a concurrent run cannot double-spend. Once we sign, the spend is recorded whether or not the seller delivers — a signed EIP-3009 authorization is live money the moment it exists.
settled — the paid request returned a settlement receipt confirming success, with a transaction hash. delivered_no_receipt — the seller returned 200 but the response carried no settlement receipt. settle_failed — no successful paid response came back at all. Every attempt, including refusals before any money moved, is visible on the endpoint's page with its evidence.
7.What L2 measures
L2 runs only when the paid request in the same purchase returned 200. It is a minimal structural check, not a full JSON-Schema validation: the response must parse as JSON and carry the top-level keys the catalog's own declared output schema marks as required. no_declaration — the catalog entry does not declare an output schema; never counted as a failure. match — the response parses and every declared required key is present. mismatch — the body does not parse as JSON, a required key is missing, or the content type is not JSON despite a declaration. not_checked — the paid request did not return 200, so there was nothing to check. L2 does not verify that the values are correct or that the content is any good — that judgement is L3, and L3 is not built.
8.Fairness commitments
vet402's own endpoints, when listed in the catalog, are measured by exactly the same pipeline with no special casing — a verifier that special-cases itself is flagging its own fraud. These pages publish facts with reason codes and timestamps; they do not publish composite scores, rankings, or evaluative language about any operator. Corrections follow the site-wide corrections policy.