Paid is on chain.Delivered is not.
x402 proves that an agent paid. Nothing in x402 proves that the API delivered. vet402 buys from x402 APIs itself and publishes what came back, so you can check a seller before your agent pays it.
Independent measurements of how AI agents pay with stablecoins over x402, including USDC where that is the pinned asset. Check a seller before paying on its own page. Counts for each chain are on the chain pages.
vet402 check
Public, no account
Example result
The latest settled purchase in the public export of the last day.
- Endpoint
- POST agent402.tools/api/extract
- L0
- pass probed 2026-10-29 16:40 UTC
- L1
- 2 of 2 settled, 2 delivered last 30 days
- L2
- match
The whole ledger
1,139 of 12,380 settled purchases got no 2xx answer.
Whole ledger, read : 18,831 paid attempts, 12,380 settled, 11,241 delivered. Lowest share among chains with 100 or more settled, over settled purchases that are not held: Tempo, 94 of 134. 700 answered 4xx, held as inconclusive because a 4xx can come from the shape of vet402's request. Source (CC BY 4.0).
One purchase
- Endpoint
- agent402.tools/api/extract
- Price
- 0.01 USDC
- Chain
- Stellar
- Payment
- settled, re-read on chain
- HTTP after payment
- 200
- Delivered
- yes, 2xx
- Against declaration
- match
- Transaction
- 95f108…4685
Reproduce this line
curl -sL "https://vet402.com/api/v1/observatory/export.csv?days=1" | grep 7ba26a02Latest settled purchases
| Time | Host | Chain | HTTP | Delivered |
|---|---|---|---|---|
| agent402.tools | Stellar | 200 | yes, 2xx | |
| api.arysphere.com | Arbitrum One | 200 | yes, 2xx | |
| api.sitecheck-api.workers.dev | Celo | 200 | yes, 2xx | |
| livecheck.fly.dev | Tempo | 200 | yes, 2xx | |
| agent402.tools | Stellar | 200 | yes, 2xx |
Two ways in
For agent developers
The same facts, inside your agent. Three lines after the import.
npm i @vet402/sdk
import { createVouchClient } from "@vet402/sdk"
const vet = createVouchClient({})
const { resource } = await vet.resolve("https://api.example.com/v1/quote")
const d = await vet.getDecision(resource!.resource_id)
// pay when d.recommendation is "ALLOW" and d.degraded is falseNo key needed up to 10 requests a minute.
For x402 sellers
vet402 may already have bought from your API. Put your domain in the check above to see each purchase.
- See
- Each purchase, with its transaction and HTTP status.
- Show
- The receipt badge on your endpoint's record page.
- Dispute
- Any record, free, no account. Corrections log
- 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.
Customer count and revenue: not published. Counts on this page are read from observatory/state, export.csv and the decision document for the purchase line, at the time of the read. Methodology.
Where purchases settled
One row per chain with a settled purchase in the public ledger. L1 figures by chain.
| Chain | Asset | Settled purchases | Delivered | Paid, not delivered |
|---|---|---|---|---|
| Base | USDC | 10,370 | 9,536 | 834 |
| Solana | USDC | 854 | 813 | 41 |
| Tempo | USDC.e | 318 | 94 | 224 |
| Celo | USDC | 237 | 232 | 5 |
| Arc | USDC | 148 | 147 | 1 |
| XRPL | RLUSD | 117 | 88 | 29 |
| Arbitrum One | USDC | 110 | 109 | 1 |
| Stellar | USDC | 162 | 162 | 0 |
| BNB Chain | USD1 | 54 | 51 | 3 |
| Avalanche C-Chain | USDC | 10 | 9 | 1 |
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.
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]
As of 2026-04-21, the Visa and Artemis PDF reports raw x402 activity of $135.7M across 178.3M transactions, and the article reports wash-and-test-adjusted totals of $15.0M across 109.6M transactions. The gap between those two published totals is 38.5% of transactions and 88.9% of volume. [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 L2 output words in that table are the ledger column l2_schema: match, mismatch, no_declaration, or not_checked. The decision document and the facts document store conform, mismatch, undeclared, or not_checked. conform is written when the re-read L2 value (l2_reading) of the latest delivery is match. mismatch is written when that re-read value is mismatch. An older mismatch row with no recorded reason is re-read first, and a cut body reads not_checked. In the other cases the decision word is not_checked when the current declaration names output (a required key or an example property), and undeclared when it does not.
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. A dispute filed on the record form puts an active listing on a priority list that an L0 run probes before its ordinary queue, up to 50 a run and 5 from one site, with published fails that need a re-probe ahead of disputes. A listing whose URL has an unfilled path parameter is not put on that list. A listing probed in the past 60 minutes waits for a later run, and a dispute that no run reaches within 7 days leaves the list. The scheduled L0 run is at 10:30 UTC, and an L0 run at another time can measure the listing first. A signed dispute, which runs one fresh L0 probe of the endpoint when it is accepted, records it like any other probe. The publication gate is unchanged. One failing probe does not publish a fail, and one passing probe becomes the published verdict until the next probe. 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); 27,805 of them were last probed more than 7 days ago, and a further 21,780 endpoints whose latest probe passed are no longer listed and are not in this row (publishedPass = 76,383 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 7,523 endpoints of l1.endpointsSettled in /api/v1/observatory/state. Their own denominator is the 10,160 endpoints L1 has attempted a paid purchase against, not the first row — read as a share of those, the two L1 rows together are 74.0%.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 read in runs roughly two hours apart; endpoints are probed on a rolling schedule. 26% of 110,787 active endpoints carry a probe from the last 7 days (page read 2026-10-30T14:10:18.142Z). The response at https://vet402.com/api/v1/observatory/state carries its own retrievedAt. This page reuses that shared read for up to 300 seconds. 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.
vet402's own agent identity
Registered on Celo mainnet as ERC-8004 agent #9907 and as agent #194 in the Self Agent ID registry, so an agent can look up who publishes these reports before it relies on them.
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.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]
- As of 2026-04-21, the Visa and Artemis PDF reports raw x402 activity of $135.7M across 178.3M transactions, and the article reports wash-and-test-adjusted totals of $15.0M across 109.6M transactions. The gap between those two published totals is 38.5% of transactions and 88.9% of volume. $135.7M and 178.3M are in the PDF. $15.0M and 109.6M are in the article and in the archived copy. The two rates are that gap, not a rate printed in either document. Visa and Artemis, Agentic Payments from the Ground Up, July 2026 (archived copy). The PDF is Agentic Payments report (PDF). The PDF states the raw totals and dates them as Artemis Analytics data as of April 21, 2026. The live article page returned HTTP 500 for part of September 2026 and answered HTTP 200 again when rechecked on 2026-09-29.