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. Every score vet402 issues becomes a watched event: 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.
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. Weekly, 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.
| Measurement | Rate | Counts |
|---|---|---|
| Known-bad addresses flagged (BLOCK or WARN) | 100% | 25 of 25 flagged, 0 allowed |
| Known-good addresses wrongly blocked (our false positives) | 0% | 0 of 17 allowed, 17 warned, 0 blocked |
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.
333 benchmark scans in the last 90 days, most recent 2026-08-12. Address set and per-address sources are versioned in the codebase (§3).
3.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.
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.