# vet402

> Independent verification of the x402 agent-payment economy. vet402 buys what x402 endpoints actually sell, verifies fulfillment against the seller's own declaration, and publishes the results with evidence. It also scores payee wallets on Base, so an x402 API provider or a spending agent can check a counterparty before a payment settles.

x402 settles payments finally and irreversibly, and proof of payment exists on-chain — but proof of delivery does not exist anywhere. Registries can be written for cents and directory metrics can be manufactured, so vet402 does not take either at face value: it measures, states which level of verification a result came from, and says "unverified" when it has not measured. Nothing on the site is presented as an estimate.

Formerly named "Vouch"; renamed to vet402 in August 2026. The production URL is `vet402.com`. The GitHub repository is still `kzmttkc/agent-trust`, and issued API keys and webhook headers keep the `vouch_` / `Vouch-` prefixes for backward compatibility — the old name appearing in those two places is deliberate, not stale documentation.

## Verification levels

This is the published methodology. A result is labelled by the level that produced it and never moves up a level: an L0 probe cannot report settlement, and an L3 opinion is never folded into an L0–L2 fact. L0, L1 and L2 verdicts ship live in the observatory (see "Implemented and live" below): L0 and L1 are full measurements; L2 is a deliberately minimal structural check — parses the response as JSON and confirms the seller's own declared required keys are present, nothing deeper — described exactly as such on https://vet402.com/observatory/methodology. L3 is not built and no opinion is published anywhere on the site.

- **L0 Liveness** — does the endpoint answer correctly? Probe, no purchase. Output: pass / fail / unverified.
- **L1 Settle-through** — does payment settle and a response arrive? Real purchase. Output: n of m settled, latency.
- **L2 Conformance** — does the response match the seller's own declaration? Purchase plus machine diff. Output: conform / mismatch / undeclared.
- **L3 Quality** — is the content any good? Published rubric. Output: opinion, and never mixed into an L0–L2 fact.

What the API returns today is a different, older thing: a 0–100 trust or payee score banded ALLOW / WARN / BLOCK. It predates the levels and stays available to API and SDK callers during the transition; observatory verdicts replace it as they ship, and a score is never reported as an L0–L2 result. The front page states this relationship in §2.1. Scoring is fail-closed: an input that could not be read is never reported as an input that was checked and found fine. Such a verdict is marked `degraded`, is not cached, and returns BLOCK to callers, while the public profile pages say "Not verifiable right now" instead of publishing a number.

## Primary

- https://vet402.com/ — the memo: problem, verification levels, what is live, what is still being built
- https://vet402.com/observatory — the L0 register: every catalog-listed x402 endpoint, probed daily against its own declared method, pass / fail / unverified with timestamped evidence
- https://vet402.com/observatory/state — aggregate rates for the whole observed catalog, broken out by chain
- https://vet402.com/observatory/methodology — full definitions for L0 Liveness, L1 Settle-through and L2 Conformance: what each level measures, what it cannot measure, and the publication gate that keeps one bad sample from branding an endpoint dead
- https://vet402.com/docs/api — API reference, including copy-paste curl commands that need no key
- https://vet402.com/accuracy — public accuracy ledger: past verdicts, outcomes, and misfire rate
- https://vet402.com/leaderboard — register of recently verified subjects, ranked
- https://vet402.com/payee — verify a payee, or look one up
- https://vet402.com/corrections — every correction issued to a published result, and what does not count as one
- https://vet402.com/operator-log — public, append-only record of every global operator override (network-wide blacklist), with the address, stated reason, and date; customer-private lists never appear here
- https://vet402.com/faq — x402, ERC-8004, and how scoring works
- https://vet402.com/signup — get an API key (free tier: 1,000 lookups / month)
- https://vet402.com/blog — notes on agent-to-agent payments, x402, and verification
- https://vet402.com/blog/rss.xml — the same posts as RSS
- https://vet402.com/llms-full.txt — full FAQ and blog text, generated from the same modules the HTML uses
- https://vet402.com/openapi.yaml — OpenAPI 3.1 of every public endpoint

Public per-subject pages: `https://vet402.com/payee/{address}`, `https://vet402.com/agent/{agentId}`, and `https://vet402.com/observatory/e/{id}` (one endpoint's full L0/L1/L2 history).

## API — no key required

These are open paths, rate-limited per IP. Nothing below needs an account. Every response carries `RateLimit-Limit`, the ceiling for that path. `RateLimit-Remaining` and `RateLimit-Reset` are per-caller, so they are sent only on responses a shared cache does not replay to someone else — chiefly the `429`, which also carries `Retry-After`. A cached `200` deliberately omits them rather than handing you a counter that belongs to whoever populated the cache. A path under `/api/` that matches no route answers `404` as JSON (`{"error":"not_found","path":...}`), never as an HTML page.

- `GET /api/v1/accuracy` — the accuracy ledger as JSON. Aggregate counts, and the same numbers /accuracy renders **with the same caveats attached**: the `interpretation` object carries the notes that qualify each rate — that a benchmark "detection" counts BLOCK *or* WARN and how many known-bad addresses stopped at WARN, that a 0% false-positive rate means "none were blocked" rather than "all were passed" and how many known-good addresses only reached WARN, and that a rate below the minimum sample is `null` rather than a number. Reading the JSON alone is enough; you are not being asked to parse the HTML to learn what a figure means
- `GET /api/v1/payees/verify?wallet={address}&name={name}` — returns the exact message a payee must sign. Read-only, writes nothing
- `POST /api/v1/payees/verify` — publish a verified-payee page and badge by posting that signed message. Free, signature required
- `GET /api/v1/agents/verify` / `POST /api/v1/agents/verify` — the same claim flow for an ERC-8004 agent identity
- `GET /api/v1/agents/{agentId}/passport` — machine-readable agent passport
- `GET /api/badge/{address}.svg` — SVG badge for a payee wallet (states only whether a signed claim exists; carries no score, because a cached score on a third-party page would outlive its freshness window)
- `GET /api/badge/agent/{agentId}.svg` — the same badge for an agent
- `GET /api/demo/score` — one fixed, publicly registered agent, scored live. Returns `live: false` rather than a stale or invented number when it cannot compute one, and `degraded: true` when the verdict was computed with an input it could not read. Freshness is explicit as `scoredAt` + `cacheExpiresAt`, the same pair the passport publishes — a cached value is up to five minutes old and says so
- `GET /api/health` — service status

Verification proves control of a wallet or an agent identity by signature. It is not an endorsement, and the score is computed independently of it.

## API — API key required

Send `Authorization: Bearer <key>`. Quotas and burst limits: https://vet402.com/docs/api#rate-limits

- `GET /api/v1/payees/{address}/score` — the buyer-side question: should this payee be paid?
- `GET /api/v1/wallets/{address}/score` — trust score by wallet address (the path x402 middleware uses)
- `GET /api/v1/agents/{agentId}/score` — trust score by ERC-8004 agent ID (optional `?wallet=` verifies the registered wallet; optional `?chain=` selects an enabled chain, default Base)
- `POST /api/v1/scores/batch` — score up to 25 agents in one request
- `GET /api/v1/agents/{agentId}/history` — score history snapshots (paid plans)
- `POST /api/v1/payments/x402` — attest an x402 payment settlement after verification (idempotent on txHash)
- `POST /api/v1/events/{trustEventId}/outcome` — report what actually happened after a verdict; this is what the public accuracy ledger is computed from
- `GET|POST /api/v1/watchlist`, `DELETE /api/v1/watchlist/{id}` — watch an agent or wallet; verdict changes arrive as a `watch.verdict_changed` webhook
- `GET|POST /api/v1/webhooks`, `DELETE /api/v1/webhooks/{id}` — webhook subscriptions

Every response that carries a score or a published rate carries a `disclaimer` string in the payload, so the caveat travels with the number rather than living only on the web page.

Full machine-readable schema (OpenAPI 3.1, covering every public endpoint listed above, key-less and keyed, with `https://vet402.com` as the only production server): https://github.com/kzmttkc/agent-trust/blob/main/docs/openapi.yaml

## Packages

On npm, all from the same repository: `@vouchscore/sdk` (spend guard), `@vouchscore/middleware` (x402 request gate), `@vouchscore/mcp-server` (MCP tool). The SDK and the middleware both default to fail-closed — only an ALLOW passes, and a WARN, a BLOCK, a degraded verdict, or a partially measured one is denied unless the caller explicitly opts out.

## Implemented and live

- Verified Payee: prove control of a wallet by signature, get a public page and an SVG badge
- Drop-in x402 middleware, REST API, and MCP tool
- Public accuracy ledger, published whether or not the numbers flatter us
- The x402 Observatory: L0 liveness probes across the full public discovery catalog, multi-chain (see /observatory/state for the breakdown), with delisting alerts for claimed sellers; L1 settle-through — real USDC purchases on Base, budget-capped, one purchase per endpoint per sweep window, recording every settlement and every refusal; L2 — a minimal structural check of the response against the seller's own declared schema

## Being built (not measurements yet)

- Writing verification records to the ERC-8004 Validation Registry — the registry itself is UNSTABLE upstream as of 2026-08-14 (per 8004scan's best-practices), so vet402 keeps its record format ready without writing to it yet

## Use cases

- x402 API providers deciding whether to accept a payment from an unfamiliar agent wallet
- Spending agents checking a counterparty before initiating a machine-to-machine payment
- Payees and agents publishing a signature-proven claim plus a badge, so counterparties can check them
- Marketplaces wanting a reputation signal without building their own scoring pipeline

## Chain

Base (ERC-8004 agent identity / reputation) is the default and the chain the scoring API measures on. The agent-score endpoint accepts `?chain=` to select another enabled chain; an unknown or disabled chain is a 400 with the live list, never a silent fallback to a different chain.

The observatory is a separate system and is not Base-only: L0 probing runs across every chain present in the public x402 discovery catalog, and https://vet402.com/observatory/state reports the current per-chain breakdown. L1 purchases are Base-only for now (the wallet only signs Base USDC); a purchase on another chain is recorded as skipped, not silently paid on a substitute chain.

## Note on domain

The production URL is `vet402.com`, and it is the only canonical one. `agent-trust-tawny.vercel.app` is our own former deployment URL: it now issues a permanent (308) redirect to `vet402.com` and should not be cited, indexed, or linked as a source. `agent-trust.vercel.app` is a different thing again — an unrelated third-party service, not affiliated with vet402.

## Corrections

If a published score or verification result about a wallet you control is wrong, there is a free, key-less correction route open to anyone, customer or not — see section 8 of https://vet402.com/legal/terms#corrections

Corrections that are issued are published at https://vet402.com/corrections — as of 2026-08-13 that log is empty, which is a count and not a claim about accuracy.

## Citation

- You may cite the content on this site (front page, API docs, FAQ, accuracy ledger, blog) as long as you credit the source with the corresponding vet402.com URL.
- The same statement is published for human readers in section 4 of https://vet402.com/accuracy — this file is not the only place it exists.
- Figures on the accuracy ledger are rolling 90-day aggregates; cite them with the retrieval date, or quote the `generatedAt` timestamp from `GET /api/v1/accuracy`.
- Content current as of 2026-08-15.

## Legal

- https://vet402.com/legal/terms
- https://vet402.com/legal/privacy
- https://vet402.com/legal/notice

## Contact

- Site: https://vet402.com
- X: https://x.com/vet_402
- GitHub: https://github.com/kzmttkc/agent-trust