Measured, not asserted
Abstract
Most trust products tell you how many dimensions their score has. The only number that matters is what happened after the verdict. Agent and wallet scores requested with an API key are recorded as watched events (payee scores and key-less reads are not): an on-chain detector and partner reports label what the wallet actually did next, and the aggregate is published here — including the number that flatters us least. In the current 90-day window 0 verdicts have a recorded outcome (observedVerdicts in the JSON). This ledger is for score verdicts (ALLOW / WARN / BLOCK), not observatory L0–L2 facts — those live on the observatory.
Observatory L0 measurement quality, last 7 days
| Measurement | Rate | Target | Status |
|---|---|---|---|
| Probes in the last 7 days that made a fail publishable (an endpoint's second consecutive fail) and were reversed by a pass within 7 days (false fail; 120 of 12,618 probes) | 1% | under 3% | within target |
| Pass probes in the last 7 days whose next probe of the same endpoint returned no 402 (false pass; 213 of 24,651 pass probes — a count of probes, not of endpoints, so it is not the published-pass endpoint count on the home page) | 0.9% | under 2% | within target |
Same figures as l0 in GET /api/v1/accuracy, computed by the same function. These measure the observatory's probes, not the score verdicts below.
Observatory operating targets
| Measurement | Value | Target | Status |
|---|---|---|---|
| C1 — active endpoints seen in the catalog in the last 30 days that have an L0 probe from the last 36 hours | 14.8% | 100% | below target |
| C2 — endpoints with an attributed settlement in the last 30 days that vet402 tried to buy from in the last 48 hours | 1.7% | 100% | below target |
| L1 attempts in the last 7 days whose purchase run did not complete inside vet402 (status request_error, or in_flight left unfinished), out of every L1 attempt in those 7 days (0 of 1,487) | 0% | under 5% | meets target |
| vet402's own verified settlements in the last 7 days that reached the settlements index within 60 seconds | 100% | 100% | meets target |
| L0 fail probes in the last 7 days whose evidence record is complete (resource id, canonical URL, client) | 100% | 100% | meets target |
2 of these miss their target right now. We print them here rather than leave them in the JSON. Same figures as slo in GET /api/v1/accuracy, computed by the same function, as of 2026-11-11 14:30 UTC. Not measured here: decision_p95_ms_cache_hit, decision_availability_monthly_pct (listed as slo.unmeasured).
Three L1 figures that sound alike count different things. (1) The row above: 0 of 1,487 L1 attempts in the past 168 hours to 2026-11-11 14:30 UTC, any status, ended with vet402's own purchase run not completing (request_error or an unfinished in_flight); those rows are not in the ledger export. (2) Held rows: of the 1,336 attempts in the same 168 hours where vet402 signed a payment, 91 (6.8%) carry a held_reason in /api/v1/observatory/export.csv — a 4xx that the request vet402 formed could explain, or a window when its payer wallet was short — and are not counted against the seller. (3) The “vet402's side” column on /sellers counts listings, not attempts: active Base records whose latest attempt, of any date, is sorted as vet402's doing (a paid request sent without the declared body or query, the payer wallet short or empty, one of vet402's own spending limits, or a vet402 run that did not finish).
1.External usage
Verdicts requested by API users, judged by what the wallet did afterwards. Operator-run benchmark scans are excluded from every number in this section and reported separately in §2.
| Measurement | Rate |
|---|---|
| ALLOW verdicts that later showed adverse activity | insufficient data |
| BLOCK verdicts later confirmed legitimate (our false positives) | insufficient data |
| Verdict | Resolved | Went bad | Stayed good | Adverse rate |
|---|---|---|---|---|
| ALLOW | 0 | 0 | 0 | insufficient data |
| WARN | 0 | 0 | 0 | insufficient data |
| BLOCK | 0 | 0 | 0 | insufficient data |
No resolved outcomes in the current window yet. The collection pipeline is live — this page fills in as verdicts age and outcomes land. We publish the methodology first and the numbers when the sample is real, because an accuracy page that appears only once the numbers look good would defeat its own point. Raw JSON: GET /api/v1/accuracy.
These figures are historical: they describe verdicts vet402 has already issued and outcomes we have already observed, over a rolling 90-day window. They are not a forecast, a service-level commitment, or a warranty of the accuracy of any future score. Past rates can and will move as the sample grows and as the behavior we score changes. See the Terms of Service for what that means in practice.
2.Operator benchmark (labeled addresses)
These scans are run by us, not by customers — a controlled test, published separately so it can never be mistaken for (or padded into) external usage. On a weekly schedule — Wednesdays at 09:30 UTC, and the operator can also run the same pass by hand, so a scan date need not fall on a Wednesday — the engine scores a fixed, versioned set of addresses whose real-world outcome is already public knowledge: “known bad” addresses from the US OFAC sanctions (SDN) list, and “known good” addresses of long-operating, publicly identified organizations and individuals. The engine should refuse the former and pass the latter; each address counts once, using its most recent scan. The date of the most recent completed run is printed below the table.
| Measurement | Rate | Counts |
|---|---|---|
| Known-bad addresses flagged (BLOCK or WARN) | 100% | 8 of 25 blocked, 17 warned, 0 allowed |
| Known-good addresses wrongly blocked (our false positives) | 0% | 0 of 17 allowed, 17 warned, 0 blocked |
On that 100%: a detection here counts BLOCK or WARN. 17 of the 25 known-bad addresses score WARN rather than BLOCK, so an integration that lets WARN through would pay them. The SDK and the middleware default to allow-only, which is why that default exists.
On that 0%: a false positive here counts only a BLOCK on a known-good address. None of the 17 known-good addresses currently scores ALLOW — 17 of them score WARN — so 0% means “none were blocked”, not “all were passed”. The engine is cautious on this set, not accurate on it.
376 benchmark scans in the last 90 days, most recent 2026-11-11 (34 of 42 addresses). The latest pass that covered at least half of the set ran on 2026-11-11 (34 of 42 addresses). Scans recorded nothing from 2026-10-08 to 2026-10-30, while the index behind the agent resolver had stopped updating. Address set and per-address sources are versioned in the codebase (§3).
3.Score methodology (v1)
Outcome sources. Auto-detected on-chain activity (drain patterns, sustained healthy activity, dormancy, ownership changes, negative on-chain feedback) and partner reports (POST /api/v1/events/:trustEventId/outcome: confirmed fraud, confirmed legitimate, chargeback/dispute).
Classification. Rug-pull outflow, negative feedback, confirmed fraud and chargebacks count as bad. Sustained healthy activity and confirmed-legitimate count as good. Dormancy and ownership changes are neutral — silence is not vindication, so neutral outcomes never move a rate in either direction.
Conflicts. When one verdict accumulates conflicting outcomes, a partner confirmation beats auto detection; within the same tier, bad beats good — ties count against us, not for us.
Minimum sample. A rate is published only at 10+ resolved verdicts for that bucket; below that the page says “insufficient data” rather than printing noise.
Window. Rolling 90 days, aggregate counts only — no wallet addresses, no agent ids, no per-customer data on this page or in the API response.
Operator benchmark. Run by the operator against a fixed, versioned address set and stored with a dedicated source tag (operator_benchmark) so it is excluded from all external figures at the query level. Known-bad = current ETH entries of the US Treasury OFAC SDN list (public domain; retrieved via the nightly extraction at github.com/0xB10C/ofac-sanctioned-digital-currency-addresses). Known-good = long-operating addresses publicly attributed via official publications, on-chain ENS names, or public label consensus, with no adverse reports at assembly and verified activity on Base — the chain the engine scores — so the test measures discrimination, not chain coverage. Scoring uses the same engine and fail-closed rules as a live lookup, with no customer list attached. Judgment: flagging (BLOCK/WARN) a known-bad address is a detection and allowing it is a miss; allowing a known-good address is correct and blocking it is a false positive, with warnings on good addresses reported separately. The full address set with per-address sources lives in the codebase at src/lib/benchmark/dataset.ts, and rates follow the same 10+ minimum-sample rule.
4.Data reuse and citation
You may cite this. The content on this site — front page, API docs, FAQ, this accuracy ledger, the blog — may be quoted and cited, by people and by machines, as long as the source is credited with the corresponding vet402.com URL. No permission request is needed and nothing has to be asked of us first.
Cite the numbers with their window. Every figure on this page is a rolling 90-day aggregate that moves as the sample grows. A citation that carries the retrieval date and the window is reproducible; one that prints a bare percentage is not. The same numbers are available as JSON at GET /api/v1/accuracy, with a generatedAt timestamp to quote.
If a figure about you is wrong. There is a free, key-less correction route open to anyone, customer or not — see section 8 of the Terms of Service. Corrections we issue are published in the corrections log.
The machine-readable copy. The same statement, plus the site map and the open API paths, is served for automated readers at /llms.txt.
Report an outcome
Run a payment provider and want your outcomes counted? Get an API key and report them — partner-confirmed outcomes take precedence over our auto-detection.