Methodology is the moat.

Publishing rules — every headline stat ships with six things

• 1 · Object definition — mint? funded wallet? paying x402 buyer? live endpoint? Say which.
• 2 · Chain set — “all chains” is a claim, not a default.
• 3 · Time window — 24h, 30d, cumulative. Windows change conclusions.
• 4 · Scrape timestamp — explorers drift; ours are stamped.
• 5 · Exclusions — what is left out (payments before the registration existed, routing hops inside a larger transaction, money that never left the agent's control) is written on the definition, so the excluded part can be read beside the total.
• 6 · Link to raw data — every figure's history as JSON at /api/series and as CSV at /api/series?format=csv; the definition behind it at /def.

Two standing bans: forecasts never appear in live tiles (they are quarantined and labeled), and raw reputation averages are never displayed as trust.

The L0–L9 liveness ladder

“Active agents” means nothing without a definition. Each rung below is one test, written as the code runs it, with what it measures today and what it costs to reach. We rank at L7+: the first rung that money, not a file, has to pass.

The probe rungs (L1–L6) are rates over a uniform random sample of 1,024 registrations, swept every six hours; the money rungs (L7–L9) are counts over every bound wallet, recomputed every three hours. One file holds the tests, pulse/lib/ladder.mjs: the prober, the rank job and the publish gate all read it, so a tile, an agent page and the API cannot disagree. A rank that loses its evidence falls to the agent's measured probe level, never to a level nobody measured. What each rank costs to reach, in dollars, is published as rank.costtofake.v1.

Ladder v2, in force from 13 October 2026, 12:54 UTC. L5 reads up to 8 endpoints in any order and counts a completed handshake; L6 is measured; L7 needs money that left the agent's control; L9 needs three independent counterparties. Counted on the switch, with no new payments in between: L7+ 7,866 → 7,525, L8+ 562 → 557, L9 118 → 74. The v1 definitions stay served, marked superseded, and history before the switch keeps their ids (cp-2026-10-13-ladder-v2). L9 operator-set aware from 13 October 2026, 21:22 UTC (rank.l9.v4): measured before the switch, 71 of 72 L9 agents kept the level; at the switch, 72 under both rules (cp-2026-10-13-l9-v4).

Reference points for calibration: the reproducible Base crawl (n=1,204 of 63,832 registrations through 2026-08-16) measured L5 = 6.8% (95% CI 5.5–8.4%); the July 2026 ecosystem cut put working services at 2.24% of 385,998 registrations. Both are dated reference points, not the current figure — our own sweep runs continuously and right now reports L5 at 64.16% across a sample of 1,024. Where they disagree, the live number is the one we stand behind; the crawl is kept because anyone can re-run it, and a calibration point you can reproduce is worth more than one you have to take on trust. Full context →

Parameters — documented now, changeable with a dated note

Coverage verification — every publish passes the data checks

checks  = 45 rules over payments, ranks, bindings, snapshots and series
block   = 24 of them: one failure stops the publish   # fail-closed since 9 Oct 2026
warn    = published with the failing keys on /data-health

• The rank is checked against its evidence on every run: no agent at L7+ without a counted payment, no L9 without three counterparties, no L6 that no probe measured. The checks read the same ladder file as the rank job.
• The Base registration count is read two ways, day by day: from our own table of the registry's mints and from The Graph's Agent0 subgraph. A gap is a published warning, not a silent pick.
• A payment counts only after its transaction receipt is read: a transfer that is a routing hop inside a larger transaction is left out.
• Probe results are stored as a time series — status, latency, body hash, error class — never overwritten, so “endpoint responds” is auditable after the fact.

Today's results, every check with its failing keys: /data-health and /api/dq.

Reputation & volume hygiene

• Reputation feedback has no weight in the rank (see below). It is published as its own signal, with the share of feedback backed by a payment between the reviewer and the agent.
• Review campaigns (bursts from single-use wallets, one wallet reviewing one agent a hundred times a day) are logged as findings for a person to read, never used to rank.
• Payment value is published three ways, each with its own definition: everything counted (pay.usd.total.v1), what left the agents' control (pay.usd.leftcontrol.v1), and that net of money bridged back to the payer (pay.usd.leftcontrol.netbridge.v1), with what the counted total consists of (pay.composition.v1).

How the roster is ordered

The rank is sorted by exactly two keys, in this order, and there is no third:

1. Liveness rung, descending. L9 above L8 above L7. The rung is the frozen ladder above — it is not a score and nothing is averaged into it.
2. Observed payment value, descending, as a tie-break inside a rung.

That is the whole rule. It is deliberately dull, and the dullness is the point: a reader can reproduce our ordering from the API without trusting a weighting we chose.

The weighted score we planned, and did not ship

An earlier design blended several signals into one number — payment volume, counterparties, liveness, float, vault position, reputation, minus penalties for an open god-key flag or a sanctions hit. We built the measurements and then declined to build the blend, for two reasons.

The reputation term would have been the largest hole. We now read the ERC-8004 Reputation registry directly, and the shape of that data settles the argument: one vouching programme accounts for 69.6% of every feedback event on the registry, written by a few dozen addresses, and ten addresses account for 44.14% of all feedback from a pool of more than eleven thousand raters. A rank with a reputation weight in it would not have measured agents. It would have measured whoever runs the busiest vouching script — and it would have been trivially purchasable, which is the one property a rank must never have. Reputation is published as its own signal and given no weight here.

The rest of the blend hid its own assumptions. Any set of weights encodes a view about whether a wallet holding money matters more than a wallet spending it. We would rather publish both numbers, name each one, and let a reader form that view — than bury it in coefficients and call the output objective. Every input the blend would have used is already public and separately defined: observed value, counterparties, float, reputation. Anyone who wants a composite can build one from those and say what they weighted.

If a weighted score does ship later it will arrive as its own versioned definition, sitting beside the ladder rather than replacing it, and the ladder will keep meaning what it means today.

The address sets

Several published figures are computed over a set of addresses — which recipients count as an x402 rail, which contracts agent wallets delegate to, which addresses minted the registry. A claim like that is only checkable if you can see the set, so every one of them is published with its provenance and its true size. The wallet-set register →

Crawler ethics

We identify ourselves (AFG-Pulse/1, with a link to this page, so an operator who sees us in their logs can find out who we are and why). Each sampled registration gets one request per listed web endpoint per sweep; where it declares a protocol, at most one MCP initialize or up to three agent-card reads (the declared card, then the two well-known paths); and the ERC-8004 domain-proof file on at most two endpoint hosts. Nothing is retried. We never send a payment, call a tool or follow a link a page asks us to follow. We are calling other people’s agents; we act like a good counterparty — or our own liveness numbers would collapse into noise.

Reproducibility

Methodologies we build on and credit: maxguryanov/agent-registry-research (Base liveness crawl), the indexer-honesty notes of yaojin0609/erc-8004-liveness, and arXiv 2606.26028 (Can Trustless Agents Be Trusted?). Disagree with a threshold? Argue with us — the parameters table above is versioned for exactly that.