Submit an x402 endpoint URL (or its payTo wallet). We probe the live 402 challenge, grade the receiving wallet's settlement activity against our independent ledger, and return the verdict with the queries that produced it. Scope is stated on every result: this is wallet-level receiver activity, never a single-endpoint badge.
Deterministic thresholds, versioned and published with the result. The same wallet and the same data window always produce the same grade.
x402 payments settle to a payTo wallet. One wallet can receive for many endpoints — even many unrelated hosts — and their traffic is indistinguishable in the settlement data. A wallet grade rendered as a per-endpoint badge would let one well-behaved wallet "verify" every endpoint that happens to share it.
So we never do that. When the submitted endpoint's payTo wallet backs more than one known endpoint — or when sharing cannot be established — the result carries a prominent wallet-level warning, and the verdict is presented as receiver activity of the wallet, never as a clean endpoint grade. The shared-endpoint and host counts are included in the result so you can see exactly what the grade covers.
No black box. Here is exactly what gets measured, the thresholds, and where the limits are. "Independently measured" means you can recompute it — not "trust my signature".
Every USDC payment settling on Base, collected by an independent tracker straight from public on-chain transfer data. The operator being measured is never contacted and cannot influence the number — which is exactly why it carries weight. All databases are read-only. A grade is deterministic: the same wallet over the same window always yields the same result.
Verified: at least 40 distinct clean paying wallets, and no single payer above 25% of clean volume. High concentration risk: one payer at 75% or more of clean volume, or quality-flagged rows dominate the activity. Caution: real activity with a narrow payer base, moderate concentration, or a data-quality cap. Not enough evidence: too few measurable rows to judge. The thresholds are ours and stated on purpose — a grade is only worth as much as a number you can check against it.
"Clean" means a row carries no quality flag. Flags come from precomputed heuristics over the payment graph — burst, dust, and reciprocal-flow patterns that inflate apparent demand. The flag is aggregated, never reinterpreted here, and it is deliberately conservative: it trails ingest by about an hour, so the newest rows are counted as clean until re-checked.
Timestamps are tracker ingest times (hourly batches, ~1h granularity), not block times — so recency and age are measured against our tracking window, not the chain. An endpoint first seen in a single backfill batch can therefore read as "Not enough evidence (too new)" even when it is older on-chain; that reflects when we started watching it, not a claim about the endpoint. Coverage has one known gap (25 Jun 2026, 16:02–19:00 UTC). Every grade is wallet-scoped, and a shared payTo is disclosed in the result.
Before we attach any label to a specific address, three checks run in order:
1. Route check. Count what the entity sends, not only what it receives. Inbound-only profiling mistakes routers for sinks.
2. Identity check. Resolve ENS and public labels for every counterparty the story depends on. Confirm each label against the entity's own public surface, not only a self-assigned record.
3. Simpler-story check. Write down the most boring legitimate pattern that could produce the same data. If we cannot exclude it with data we hold, the classification does not ship.
This gate was added after our own review overturned our own draft in July 2026, before publication.
Every verdict ships with the exact SQL that produced it. The core query, over a read-only snapshot:
SELECT COUNT(*) AS total_tx,
SUM(CASE WHEN wash_flag IS NULL THEN 1 END) AS clean_tx,
COUNT(DISTINCT CASE WHEN wash_flag IS NULL
THEN lower(from_wallet) END) AS clean_payers
FROM payments
WHERE lower(to_wallet) = '0x...'; -- the payTo wallet
Concentration is the top payer's share of clean volume; the grade applies the thresholds above. Paste any endpoint or wallet in the box up top to run the whole thing live.
Same ledger, same methods, applied to your numbers before someone less friendly applies them for you. Every deliverable ships with the reproducible query. Payment upfront in USDC on Base; if we miss the deadline or the data cannot support a verdict, 100% refund to the sending wallet within 24h.
You are about to publish numbers: a launch thread, a changelog, a pitch deck. We check up to 3 headline metrics against the raw ledger, run wash and concentration sensitivity, and hand you a private list of claims to fix before you publish. 48h turnaround. Single metric: 299 USDC. If you want something citable afterwards, an Ed25519-signed public note is 499 USDC.
A signed PDF + JSON record of what actually settled to your payTo in a window you choose: settled count, USDC volume, distinct payers with the top-1 concentration stated rather than smoothed, first-seen to last-seen continuity, and a catalog-visibility check of on-chain settlement against your Bazaar listing. Fixed schema, fixed query set, and every number ships with the exact SQL it came from, run against our independent settlement ledger, with the settlement tx hashes to spot-check on-chain. See a full sample, run on our own address. We are not a party to any indexer or platform the attestation reconciles against, so it stays neutral to the dispute it touches. 48h turnaround. When the dispute also needs a diagnosis of why an indexer undercounts, that is the signed settlement report below.
When an indexer is missing your settled payments, we produce an Ed25519-signed, machine-verifiable evidence pack: every USDC transfer to your payTo that our independent ledger observed on Base, full tx hashes, per-day counts, and an explicit statement of what the report does and does not prove. Delivered within 24h.
Full 402 shape check plus settlement cross-check against the ledger, written report, delivered by email. Order it machine-to-machine: POST /audit/order on this host returns an x402 payment challenge with a unique exact amount. No account, no API key.
We run a block-zero census and a policy-risk scan of every B20 token on Base. Single-token verdicts are free at /b20/ (browser page; agents: /b20/check API). A Founding Watch Pass (10 USDC, one-time, refundable preorder) reserves watchlist alerts on control-surface changes. Platforms and aggregators: 30-day design partnership, 500 USDC, credited against a longer term.
To order anything that is not self-serve: reply in any thread where you found us, or email info@smartflowproai.com. Text only, async, worldwide.
The observatory ships as an MCP server: smartflow-verify-mcp on npm. Three tools: the live network decomposition with its sha256 seal verified locally, self-serve endpoint audit ordering (an x402 challenge with a unique exact amount), and order status. Free reads stay free; the paid tool costs exactly what the 402 says.
claude mcp add smartflow-verify -- npx -y smartflow-verify-mcp
Package: npmjs.com/package/smartflow-verify-mcp (MIT, 4 files, no API key required).
We correct ourselves in public. Every published number that later proved wrong is listed here — what was wrong, what caused it, and what changed. An auditor’s numbers are only worth the record of the ones it retracted.
Our “facilitator-mediated” count keyed off a hand-maintained list of 61 addresses. It missed ~277 real relays and admitted a few that don’t qualify. Corrected to a deterministic definition (initiator ≠ token sender AND ≥1,000 distinct payers): 4.06M → 8.29M mediated transactions (a floor), and the trend flipped from −30% to +17%. Root cause: a static list where a rule was needed. Full write-up: Weekly Intel #9.
Our tracker was down 16:02–19:00 UTC on 25 Jun (≈ 2,748 Base blocks). The gap is not backfillable without archival RPC, so aggregates covering that day are lower bounds. Publication windows are chosen to exclude it, and it is disclosed wherever the day is included.
We estimated 25–35% of x402 transactions would flag as wash-shaped; the live V1 filter measured 49.4%. The estimate had assumed a rule that wasn’t yet running. We retired the estimation approach — published wash figures since then come only from the live filter. Write-up: Weekly Intel #2.
Scope: public, citable numbers. Methodology limits are stated per-metric in methodology; this page is for the ones we got wrong.