Skip to main content
Network Working GroupRequest for Verification: 402Category: Independent MeasurementStatus: Building in publicETHOnline 2026 judges →
vet402x402 EconomySeptember 2026Updates: trust scores

vet402 — Independent Verification of the x402 Agent-Payment Economy

We buy. We settle. We publish the measurements.

Before an agent pays an x402 endpoint, vet402 checks whether that endpoint actually delivers — by buying it.

402

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.

More questionsLive measurementsScore a wallet

1.The problem this memo addresses

1.1

x402 settles payments finally and irreversibly. Proof of payment exists on-chain. Proof of delivery does not exist anywhere.

1.2

Registries can be written for cents: 98.7% of ERC-8004 reputation feedback on Ethereum has no verifiable transaction behind it. [ARXIV-2606]

1.3

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

2.1

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

3.1

A failing verdict publishes with raw log, transaction hash, timestamp and reproduction steps — or it does not publish.

3.2

Unverifiable is not a verdict. We say "unverified", never "bad". A caller about to move money gets the safe answer instead: 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.

3.3

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.

Figure 1. Endpoints at each level of evidence as of the 2026-09-27 catalog snapshot. Bars are proportional to the first row. The first row is every endpoint on record, including the 15,135 no longer listed in the catalog; 18,667 are active. L1 counts endpoints where at least one paid attempt returned an on-chain receipt, as reported by /api/v1/observatory/state. Its own denominator is the 5,501 endpoints L1 has attempted a paid purchase against, not the first row — read as a share of those, the L1 row is 49.3%.
implemented

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 — 92.5% of 18,667 active endpoints carry a probe from the last 7 days. The table shows L0 (payment-wall check) and L1 (real purchases that returned an on-chain receipt) in separate cells; they are never mixed.

Open the observatory

implemented

Verified Payee

Prove control of a wallet by signature, get a public verification page and an SVG badge.

Verify a payee

implemented

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.

API reference

implemented

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.

Measured accuracy

implemented

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.

View impact

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, and building when the work has not shipped. L1 figures by chain.

implemented

Base

USDC over x402. Settled and reconciled purchases are on record.

Settled purchases on record: 4,454

implemented

Solana

USDC over x402. Settled and reconciled purchases are on record.

Settled purchases on record: 144

implemented

Tempo

USDC.e over MPP, not x402. Settled and reconciled purchases are on record.

Settled purchases on record: 56

implemented

XRPL

RLUSD over x402, through the t54 facilitator. Settled and reconciled purchases are on record.

Settled purchases on record: 13

implemented

Arc

USDC over x402. Settled and reconciled purchases are on record.

Settled purchases on record: 2

building

Robinhood Chain (4663, mainnet)

vet402 /rwa, which reconstructs Stock Token holdings and trade history from public chain data, is being implemented. 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.

building

Writing to the empty registry

Verification records will be written to the ERC-8004 Validation Registry — the one registry that is still empty.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 @vet_402 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

Get a free API key

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 has returned HTTP 500 since at least 2026-09-02); 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.