Impact
Abstract
vet402 measures the x402 agent-payment economy by actually using it, and gives the results away: the data is public, the code is MIT, and the purchase ledger gets a daily prev-hash chain root, kept by vet402 itself (on-chain anchoring is not yet enabled — see §4). A reader who saves a root can later tell whether the published one changed; the chain does not stop vet402 from editing rows. This page states the contribution as numbers — and every number below links to the endpoint that produces it, so you can check it rather than trust it.
1.Coverage of the ecosystem
75,050 endpoints on record; 51,732 currently listed. 26,516 of them (51.3%) carry an independent L0 measurement from the last 7 days — the machine definition of "under regular verification". /api/v1/observatory/state
2.Real purchases, published with evidence
15,521 real purchase attempts across 8,157 endpoints; 9,646 settled on-chain. Of those settled attempts, 8,805 carry a transaction the seller named in its own settlement receipt and 841 a transaction the seller did not name, which vet402's own settlements index found afterwards (settlement_source vet402_index in the export). By endpoint: 5,380 endpoints have at least one seller-named receipt and 465 have index-found transfers and no seller-named receipt. Settled attempts and attempts that did not settle are published with the same weight — a receipt series per endpoint, transaction hashes included. export.csv
Attempts and settled as reported by /api/v1/observatory/state (l1.attempts: paid requests whose payment was signed and sent; l1.settled: transfer re-read on-chain; l1.settledLateLinked: the index-found part of it). The CSV export applies its own row definition and can count differently.
Latest settled transactions
Transfers vet402 re-read on-chain, not a list of seller receipts. Named by says who pointed at the transaction: the seller's own settlement receipt, or vet402's settlements index when the seller returned no receipt (settlement_source in the export).
| Attempted (UTC) | Endpoint | Transaction | Named by | Amount |
|---|---|---|---|---|
| 2026-10-17 18:02 | uuid-forge.saastemly.com/x402/uuid | 0x95c1e950…a95b | seller's receipt | $0.0017 |
| 2026-10-17 18:02 | x402.tbs-digital.com/company/resolve | 0xc1bf5d3d…4921 | seller's receipt | $0.0020 |
| 2026-10-17 18:02 | http--forest-gas-station-mainnet--lcjl27p8lmjs.code.run/repo/commit-state | 0x23ea3d9c…4bbd | seller's receipt | $0.0020 |
| 2026-10-17 18:02 | api.loopholetape.com/v1/base/launches/recent | 0x713799a3…d3de | seller's receipt | $0.01 |
| 2026-10-17 18:02 | data.finery.cc/v1/companies/search | 0xe0b3aa69…3567 | seller's receipt | $0.0050 |
3.What an agent skips by reading the signals
In the last 30 days vet402 refused 732 of 8,563 decisions before signing (overcharging or unpayable walls) and published every one of them. Across the whole ledger, 1426 of 14,457 signed attempts with a final status carried a prior public failure signal and did not settle ($57.67 signed and put at stake with no confirmed transfer on-chain — exposure an agent honoring the signals would not have taken, not money lost), while 1412 signalled attempts settled anyway and would have been skipped too (definition: signed attempts preceded by a public failure signal, a subset of the attempts in §2 that leaves out rows still awaiting on-chain verification (settle_claimed) and rows from the window when vet402's own payer wallet was out of USDC (payer_unfunded), from /api/v1/observatory/backtest; “attempts with a final status” here is not the denominator of the delivery rate on /observatory/state, which also leaves out the attempts held by vet402). /decisions
4.Integrity: an operator-kept hash chain
The purchase ledger is a daily hash chain. Latest root (2026-10-16): 33125543c951758d… over that day's 112 entries. A root covers that day's rows as they stood when it was computed (the latest day is recomputed while late rows arrive). Rows are still updated after that by design — a claimed settlement verified on-chain, a correction — so an older root describes the ledger as it was then, and today's rows are not expected to reproduce it; published status changes are listed in /corrections. From the public API alone a third party can check that each day's root links to the previous day's and that no day is missing (cli/verify-anchors.ts). Recomputing a root itself needs the raw purchase rows, and those are not published in full: the open-source projection (src/lib/observatory/anchors.ts) hashes fields export.csv leaves out — the row id, the payer, the asset, sub-second times, and the statuses the export omits. The entry count is the rows that anchor hashed, which is not the attempt count in §2. The chain is kept by the operator and is not yet fixed anywhere outside vet402 (the anchoredTx field is empty), so the operator could still recompute the whole chain. A reader who saves a root today can detect that later. /anchors
5.What is free, and reproducible
All measurement surfaces above are key-less and public. The verification stack is MIT and self-hostable (docker compose up), and anyone can reproduce a probe or see exactly what a buyer would sign without signing anything — source (cli/). The TypeScript SDK (@vet402/sdk) and the MCP server (@vet402/mcp-server) are published on npm. A Python SDK exists in the repository but is not yet published to PyPI, and the LangChain, ElizaOS and solana-agent-kit integrations are example code in the repository's examples/, not packages — API reference. The operating model is stated openly at /operations.