Frequently asked questions

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.

ERC-8004 is an Ethereum standard for on-chain agent identity and reputation. It gives an autonomous agent a registered identity (an agent ID) that can accumulate reputation signals over time, separate from any single wallet address. vet402 reads ERC-8004 identity and reputation data — alongside raw wallet activity — as one of the signal groups behind a trust score.

Given an ERC-8004 agent ID or a wallet address, vet402 returns a trust score (0-100), a recommendation (ALLOW / WARN / BLOCK), and the underlying signal breakdown: identity, reputation, wallet history, x402 payment history, and sybil-risk indicators. It's meant to be checked in the request path — before you accept a payment or complete a transaction — not reviewed after the fact.

No. Scores are informational signals derived from public on-chain data and ERC-8004 records. They do not constitute a guarantee, a credit assessment, KYC, or legal certification of any counterparty. Every API response that carries a score or a published rate includes this disclaimer directly in the payload, so it travels with the data.

Primarily the agent developer who is about to pay an x402 endpoint and wants to know, before the money moves, whether that endpoint actually settles and delivers — the observatory's L0/L1/L2 facts and the decision API exist for that call. The other direction is served too: an x402 API provider that accepts payment from agents it has never seen can check the payer's score first. The API doesn't assume which side of the transaction is calling it.

Not as a dedicated category yet. x402 and ERC-8004 only shipped in 2025, so "score a payee before an agent pays them, specifically for x402 machine payments" isn't a shelf with incumbents on it the way wallet AML screening or credit scoring is. General crypto wallet-risk tools score addresses for sanctions and fraud exposure, not for x402 payment trust; general agent-identity and reputation projects don't yet gate a payment decision in the request path. Independent measurement of x402 is not empty, and it would be wrong to imply it is: probe402 is a dedicated x402 observatory that probes a catalog of its own (16,118 endpoints as of 2026-09-04), and on 2026-09-03 it published a finding about vet402's own probe cadence that was correct. What vet402 does that we have not found elsewhere is buy from the endpoint with its own funds and publish the receipt, so the record is settle-through evidence rather than liveness alone. There's no incumbent to unseat on the paid-decision side, but that also means the need is still being proven out as x402 transaction volume grows, not a solved problem we're improving on.

No. vet402 never holds, moves, or has signing authority over customer funds: there is no wallet you deposit into, no balance we hold for you, and no key of yours we can sign with. vet402 does spend its own funds — the observatory's L1 layer buys from x402 endpoints with an operator wallet, which is the whole point of a settle-through record — so "we touch no money at all" would be false. The SDK's SpendGuard module (non-custodial) helps an agent apply spend policy locally before it pays; the scoring API itself only returns scores and records settlement attestations after a payment has already happened on-chain.

Scoring (the 0–100 ALLOW / WARN / BLOCK API) reads wallet and ERC-8004 signals from Base mainnet; an unknown or disabled chain on that API is a 400, never a silent fallback. The observatory is a separate system: L0 probes run across every chain in the public x402 discovery catalog, and /observatory/state reports the per-chain breakdown. L1 purchases run on the chains whose payer lane is switched on; the chains they have actually bought on, with their counts, are the l1.byChain rows of /api/v1/observatory/state and the by-chain table in section 3 of /observatory/state. Settlement is re-read on-chain with a binding back to the signature vet402 itself generated, and what does the binding differs by chain: on Base and Arc the EIP-3009 authorization nonce, on Solana a memo vet402 wrote itself, on Tempo the indexed memo of a TIP-20 TransferWithMemo, on XRPL the hash of the blob vet402 signed. A purchase on a chain vet402 has built no re-reader for stays at settle_claimed rather than being promoted on evidence it does not hold.

The observatory publishes catalog measurements: L0 liveness (pass / fail / unverified) and, on each endpoint page, L1 settle-through when a purchase has been made. Those are not 0–100 scores. A score is the older ALLOW / WARN / BLOCK API for a wallet or agent, sold by lookup quota. A score is never reported as an L0–L2 result.

settled means vet402 re-read the transaction on-chain and found a transfer from our payer, to the catalog-declared payee, for the declared amount, in that chain's canonical settlement asset (USDC on Base, Arc and Solana; USDC.e on Tempo; RLUSD from its fixed issuer on XRPL). How tightly that transfer is tied to the one purchase is published at two strengths, and each settled row is in exactly one: nonce-bound, where the transaction also carries the one-time value vet402 generated for that purchase (the EIP-3009 authorization nonce on Base and Arc, our own memo on Solana, the indexed memo of a TIP-20 TransferWithMemo on Tempo, the hash of the signed blob on XRPL), so it is that purchase's transfer; and amount-and-payee only, where payer, payee, amount and asset matched but no such value was checked — the rows that settled before that binding shipped at 2026-09-04T12:00:00Z — so a transfer of the same amount between the same two wallets would also have matched. The counts are l1.settledNonceBound and l1.settledAmountPayeeOnly in /api/v1/observatory/state. It is never inferred from the seller's own claim: a receipt the seller returns is recorded as settle_claimed until we have re-read it. delivered is the separate count — the attempt is settled and the paid request also answered 2xx. A paid attempt that answered 4xx — settled, or refused with no settlement receipt — is published as inconclusive instead of counted against the seller: vet402 buys with no API key of the seller's and sends {} as the POST body when the seller declares none, so a 4xx cannot be separated from a request vet402 formed wrongly. So is a 402 or 5xx from 2026-09-13 00:00 to 2026-09-15 23:49 UTC, when vet402's own payer wallet had run out of USDC. Those rows stay published with their HTTP code and are out of the denominator for delivered.

L1 is a real, budget-capped USDC purchase from the endpoint that asks whether the payment settles on-chain and a response comes back. We request unpaid first to read the 402 challenge, then refuse to proceed unless the scheme, the network, the asset and the price all match what the catalog declared; a per-purchase ceiling and a daily budget are checked against a database ledger, not memory, before every signature. Purchases are made under vet402's own User-Agent (vet402-observatory-l1/1.0, which links back to the methodology page) and rate-limited to one per endpoint per sweep window (a named priority list of high-volume hosts is bought from more often, and that list is published). Every refusal is recorded alongside every purchase, and the result publishes the same way whether it passes or fails.

No. The observatory (catalog measurements) and the payee lookup are public. An API key is only for programmatic score lookups — 1,000 a month on Free, then upgrade from Billing after you have a key.

Public pages are free. The score API is free for 1,000 lookups a month. Paid plans raise that quota; you upgrade from the dashboard once a key exists. See Access tiers on the homepage.

The key is shown once at signup and is not stored in recoverable form. If you still have a dashboard session, open API keys and create a spare. If the session expired, email support@vet402.com from the address you used at signup — we issue a replacement after verifying control. Signing up again with the same email is refused.

The canonical integration since 2026-09-02 is GET /api/v1/resources/:resourceId/decision, which returns the L0/L1/L2 facts and an ALLOW / WARN / BLOCK recommendation in one document. The older per-subject score routes still work and are still documented: a payee (GET /api/v1/payees/:address/score), a payer wallet (GET /api/v1/wallets/:address/score), or an agent ID (GET /api/v1/agents/:agentId/score), batched up to 25 at once, plus attesting an x402 settlement after verification. Full request/response shapes, error codes, and an OpenAPI schema are on the API reference page.