vet402 — Independent Verification of the x402 Agent-Payment Economy
See whether an x402 API actually delivers before your agent pays it. We buy it and publish what happened.
- What this is
- x402 is how an agent pays an API. vet402 buys from those APIs itself and publishes whether what was paid for arrived.
- What you give us
- Nothing to look: no wallet, no account, no card. A free key only for API calls.
- What we do not do
- Guarantee a seller, refund, handle chargebacks, check identity (KYC), approve payments, or cap your spending.
We buy. We settle. We publish the measurements.
Abstract
vet402 buys what x402 endpoints actually sell, verifies fulfillment against the seller's own declaration, and publishes the results with evidence. A weaker tier of evidence is not rounded up into a stronger one: the settlements vet402 bound to its own signature and the ones matched on amount and payee alone are published as separate counts. See both counts.
What is x402?
x402 is a machine-payment protocol built on the HTTP 402 "Payment Required" status code. An API returns 402 with payment terms, the caller (often an AI agent) pays on-chain, and retries the request with proof of payment attached. There's no account, no invoice, and no human approving the transaction — which is what makes it fast for agent-to-agent commerce, and also what makes it blind: the provider sees the payment only after it has already settled.
1.The problem this memo addresses
x402 settles payments finally and irreversibly. Proof of payment exists on-chain. Proof of delivery does not exist anywhere.
Registries can be written for cents: 98.7% of ERC-8004 reputation feedback on Ethereum has no verifiable transaction behind it. [ARXIV-2606]
Directory metrics can be manufactured: 38.5% of x402 transactions fall away as wash or test activity before the totals mean anything. [VISA-ARTEMIS-2026]
2.Verification levels
Four levels, in order of what they cost us to run and what they prove. A result never moves up a level: an L0 probe cannot report settlement, and an L3 opinion is never folded into an L0–L2 fact.
- L0 Liveness
Does the endpoint answer correctly?
How: Probe, no purchase
Output: pass / fail / unverified
- L1 Settle-through
Does payment settle and a response arrive?
How: Real purchase
Output: n of m settled, n delivered
- L2 Conformance
Does the response match the seller's own declaration?
How: Purchase + machine diff
Output: match / mismatch / no_declaration / not_checked
- L3 Quality
Is the content any good?
How: Published rubric
Output: opinion — never mixed with L0–L2
The trust score this API returns today — 0–100, banded ALLOW / WARN / BLOCK — predates these levels. It stays available to API and SDK callers during the transition. Observatory verdicts (L0–L2) replace it as they ship, and both will run side by side until then. A score is never reported as an L0–L2 result. How the score is composed. Full definitions of pass / fail / unverified and the L1 purchase rules: observatory methodology (v2).
3.What a verdict must carry
A failing verdict publishes with raw log, transaction hash, timestamp and reproduction steps — or it does not publish.
Unverifiable is not a verdict. We say "unverified", never "bad". For a caller about to move money, a check that could not be completed returns a fail-closed BLOCK to the API and the SDK, while the public page prints “not verifiable right now” and no number. Why the two answers differ.
Sellers can dispute any result for free, which runs one fresh L0 probe of the endpoint straight away and records it like any other probe — the publication gate is unchanged, so one probe can lift a published fail back to unverified but cannot by itself produce a pass. A dispute does not trigger a new L1 purchase. How to dispute a result. Corrections are logged publicly — the corrections log.
4.Implemented and live
Everything in this section is running right now and can be checked without asking us.
publishedPassActive); 13,432 of them were last probed more than 7 days ago, and a further 11,594 endpoints whose latest probe passed are no longer listed and are not in this row (publishedPass = 39,982 includes them). The two L1 rows count endpoints, listed or not, with at least one paid attempt settled on-chain: first those where the seller named the transaction in its own settlement receipt, then those with no seller receipt, where none of the settled transfers was named by the seller and vet402's own settlements index found them (settlement_source in the ledger export). Together they are the 5,434 endpoints of l1.endpointsSettled in /api/v1/observatory/state. Their own denominator is the 7,678 endpoints L1 has attempted a paid purchase against, not the first row — read as a share of those, the two L1 rows together are 70.8%.The x402 Observatory
Every endpoint in the public discovery catalog: is it still listed, and does its payment wall answer a valid 402. The catalog is re-fetched daily; endpoints are probed on a rolling schedule — 50.8% of 34,483 active endpoints carry a probe from the last 7 days. The table shows L0 (payment-wall check) and L1 (real purchases whose transfer vet402 re-read on-chain, whether the seller's receipt or vet402's own index named the transaction) in separate cells; they are never mixed.
Wallet control, proved by signature
Prove control of a wallet by signature, get a public verification page and an SVG badge.
Drop-in middleware, REST API and MCP tool
An x402 middleware package, a REST API, and an MCP tool that answers the question a spending agent should ask before it pays.On npm: npm i @vet402/sdk, @vet402/middleware, @vet402/mcp-server. @vet402/* is the canonical scope; @vouchscore/* is the former name, same publisher. Unscoped vouch-sdk and @getvouch/sdk are unrelated.
Public accuracy ledger
The misfire rates vet402 already has a sample for are published: the L0 false-fail and false-pass rates against re-measurement ship as l0 on /api/v1/accuracy. The verdict-outcome rates wait for a sample — until enough issued verdicts have resolved, the page below says so instead of printing a number. What is printed goes up whether or not the numbers flatter us.
Impact ledger
Real purchases made and published with evidence — settled and failed alike — plus catalog coverage and a hash-anchored ledger (daily prev-hash chain; on-chain anchoring ships behind a flag, OFF by default), synthesized from the sections above into one page for grant reviewers and integrators.
5.Chains
What vet402 does on each chain today. A lane is marked implemented when the public ledger holds a settled purchase on that chain. A row marked live is a public product on that chain, not a purchase lane, so it carries no count. L1 figures by chain.
Base
USDC over x402. Settled and reconciled purchases are on record.
Settled purchases on record: 8,162
Solana
USDC over x402. Settled and reconciled purchases are on record.
Settled purchases on record: 481
Tempo
USDC.e over MPP, not x402. Settled and reconciled purchases are on record.
Settled purchases on record: 213
XRPL
RLUSD over x402, through the t54 facilitator. Settled and reconciled purchases are on record.
Settled purchases on record: 43
Arc
USDC over x402. Settled and reconciled purchases are on record.
Settled purchases on record: 36
Robinhood Chain (4663, mainnet)
vet402 /rwa rebuilds a wallet's Stock Token holdings and trade history from public chain data, and shows what it could not parse. The purchase lane and the settlement index are not supported.
6.Status of this work
Live work is in section 4. This section is only what has not shipped, and this page will not describe it as though it had.
Writing to the Validation Registry
Verification records will be written to the ERC-8004 Validation Registry, which is nearly unused so far and holds nothing from vet402.Why it has not happened yet, stated plainly: the registry is written in one direction only. An agent’s owner names a validator and opens the request; the validator answers it. A validator cannot open a request about someone else’s agent — validationRequest reverts with Not authorized, which is what our fourteen attempts between 2026-08-21 and 2026-09-03 did. So this is not a build problem. In the 750,000 blocks of Base we read on 2026-09-03 (roughly 17 days) the whole registry received two events, from one validator, about one agent, and none named us. We can answer the first request the day someone sends one; until then the honest number is zero.
Progress is posted as it lands, on X @vet402_com and GitHub.
A.Access tiers
Usage-based. The free tier is enough to wire a check into an x402 flow and see real results before committing to anything.
- Free$0
1,000 lookups / month
REST, MCP and x402 middleware, TypeScript SDK
- Pro$49/mo
50,000 lookups / month
Everything in Free, plus score history and priority support
- Scale$199/mo
500,000 lookups / month
Everything in Pro, at the highest rate limit
Paid tiers are upgraded from Billing once a key exists. No card is required to start. Already have a key? Open Billing.
B.References
- [ARXIV-2606]
- 98.7% of ERC-8004 reputation feedback on Ethereum has no verifiable transaction behind it. The paper reports this per chain; §1.2 quotes the Ethereum figure, which is the lowest of the three it measures. arXiv:2606.26028
- [VISA-ARTEMIS-2026]
- Raw x402 activity of $135.7M across 178.3M transactions falls to $15.0M across 109.6M once wash and test transactions are excluded — 38.5% of transactions, 88.9% of volume. Visa and Artemis, Agentic Payments from the Ground Up, July 2026 (archived copy; the live page returned HTTP 500 for part of September 2026 and answered HTTP 200 again when rechecked on 2026-09-29); Artemis Analytics on-chain data as of April 21, 2026. The split between self-dealing and wash trading inside that excluded share is not published, so this page does not state one.