Questions about x402 payments

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.

vet402 publishes three measurements. L0 asks whether the payment wall answers a valid 402. L1 asks whether a real purchase settled and the paid request answered 2xx other than 202 with a non-empty body. L2 asks whether that response matches the seller's own declaration, when the seller publishes one. None of them checks that the content is right. The decision API returns ALLOW, WARN, or BLOCK from those records. A separate 0 to 100 score with its own recommendation is an older signal for API callers. A score is never printed as an L0 to L2 result.

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. Providers look up their own purchase results at /sellers.

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, Arc, Celo, Arbitrum One, Avalanche C-Chain and BNB Chain 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. The settlement asset is USDC on Base, Arc, Celo, Solana, Stellar, Arbitrum One and Avalanche C-Chain, USDC.e on Tempo, RLUSD from its fixed issuer on XRPL, and USD1 on BNB Chain. Stellar is re-read for payer, payee, amount and asset, and is published as amount and payee. 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 0–100 API for a wallet or agent, with its own ALLOW / WARN / BLOCK recommendation, sold by lookup quota. The ALLOW, WARN, or BLOCK of the decision API comes from the L0 to L2 records and has no score behind it. A score is never reported as an L0–L2 result.

settled means vet402 re-read the transaction on-chain and found a transfer from the vet402 payer, to the payee the catalog declares, for the declared amount, in that chain's pinned settlement asset. The asset is USDC on Base, Arc, Celo, Solana, Stellar, Arbitrum One and Avalanche C-Chain, USDC.e on Tempo, RLUSD from its fixed issuer on XRPL, and USD1 on BNB Chain. On Tempo the directory lists no recipient, so the payee is the one L0 learned from the challenge. Through Circle Gateway on Arc one batch transaction can settle many payments and there is no separate transfer to the payee: Circle's Gateway API names the batch for the purchase's nonce, and vet402 checks the buyer's debit in that batch. 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 means the re-read matched the one-time value stored for that purchase, so the transaction is the one for this purchase. That value is the EIP-3009 authorization nonce on Base, Arc, Celo, Arbitrum One, Avalanche C-Chain and BNB Chain, a memo vet402 wrote on Solana, the indexed memo of a TIP-20 TransferWithMemo on Tempo, or the hash of the signed blob on XRPL. Stellar is not in this count. The Stellar re-read checks payer, payee, amount and asset. Amount and payee means the re-read matched payer, payee, amount and asset and did not bind a one-time value. That tier holds the rows that settled before the binding shipped at 2026-09-04T12:00:00Z, and it holds Stellar rows. 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 vet402 has re-read it. delivered is the separate count. The attempt is settled and the paid request also answered HTTP 2xx other than 202 Accepted, with a non-empty body. It does not show that the content is right. 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 purchase of that chain's pinned asset (USDC on Base, Arc, Celo, Solana, Stellar, Arbitrum One and Avalanche C-Chain, USDC.e on Tempo, RLUSD on XRPL, USD1 on BNB Chain). vet402 requests unpaid first to read the 402 challenge, then will 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 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.

vet402 lists an x402 endpoint when the endpoint is in the CDP Bazaar discovery catalog (https://api.cdp.coinbase.com/platform/v2/x402/discovery/resources). The syncs of that catalog are scheduled roughly two hours apart, at 00:05, 02:05, 04:05, 06:05, 08:05, 10:05, 12:05, 14:05, 16:05, 18:05, 20:05 and 22:05 UTC. A sync can start later within its scheduled hour. A sync reads the catalog page by page and continues from the page where the previous sync stopped. A sync that stops early adds the pages it read and not the rest. So your route appears on vet402 after a sync that reads the page with your route. vet402 also reads the Circle x402 discovery (https://api.circle.com/v2/x402/discovery/resources). The sync of that catalog starts at 01:30 UTC. For Tempo, vet402 also reads the MPP directory (https://mpp.dev/api/services), with a sync that starts at 01:30 UTC. There is no application to vet402 and no fee. The CDP Bazaar belongs to CDP. Whether a route enters the CDP Bazaar is decided by CDP's index, not by vet402. CDP's docs say a route is indexed after it declares the Bazaar extension, answers 402, and a payment for it settles through the CDP facilitator. A route that does those things can still be left out by CDP. Circle x402 discovery is Circle's own list. vet402 does not decide which routes it includes. Circle's docs say a route enters that list after the service is payable (it answers 402 when unpaid and serves the resource when paid), an OpenAPI spec is published, and Circle approves the intake form. Circle screens the payout wallet and health-checks the route, and a route stays listed while Circle's health check can reach it. Circle can still leave a route out. Circle's guide to getting listed: https://developers.circle.com/agent-stack/agent-marketplace/get-listed vet402 does not read the PayAI discovery list as listings. How vet402 checks a listed route: the unpaid L0 check of a POST route sends {} as the body. If that unpaid POST gets 400 or 422 with neither a WWW-Authenticate nor a PAYMENT-REQUIRED header, L0 records it as unverified, not as a failure. On a GET route, a 400 or 422 is an L0 fail. Tempo routes, which are measured as MPP, are the exception. L1 buys from a route whose latest L0 check passed. When the unpaid request of L1 does not get a 402, L1 records no_402. For the paid POST, L1 reads extensions.bazaar.info.input.body from the same document as the payment terms: the PAYMENT-REQUIRED header when it parses as a payment challenge, and otherwise the response body. When that value is a JSON object or array of 16 KB or less as encoded JSON, L1 sends it as the body. Otherwise L1 sends {}. CDP's guide to getting listed: https://docs.cdp.coinbase.com/x402/seller/get-discovered