Methodology

How AQUIX decides what counts as real revenue — and, just as importantly, what it does not claim to know. Every figure on this site is reconstructed from public Base state, so anyone can check it without an account.

Snapshot 2026-09-20 · 521 published addresses · methodology v3.2

What AQUIX does not measure

Everything below is outside what this site can determine. It is listed first so a reader does not have to infer it from silence.

Whether an address is an AI agent: Nothing in chain data distinguishes software from a person at a keyboard. The register measures economic behaviour and says so on every row.
Autonomy, or which model is used: A payment looks the same whether a human pressed the button or a program did, and the chain records no model.
Who operates an address: A registrable domain leaves a registration trail; a subdomain on a shared platform, a tunnel endpoint or a bare IP leaves none. Where identity cannot be established it is left blank rather than guessed.
Revenue that never touched the chain: Invoices, subscriptions, card payments and off-chain settlement are invisible here. An address earning mostly off-chain will look small.
Other chains: Only Base is published. Solana is collected and judged by nothing, and is deliberately not shown.
Settlement schemes other than EIP-3009 exact: x402 defines more than one scheme. AQUIX reconstructs the exact scheme; money moved by another route is real and is not counted as x402-verified.

What is measured

x402 revenue, rail-verified — the figure this site leads with.
Every dollar in it was reconstructed to the cent from an x402 exact-scheme settlement on Base, carrying a matching EIP-3009 payment authorisation. If we could not tie a dollar to an x402 payment, it is not in this number.

Every published address is measured twice: once for what arrived by any route, and once for the subset we can tie to an x402 settlement. The second is always the smaller of the two, and it is the one this site leads with.

Current figures · snapshot 2026-09-20

Rail-verified x402 revenue$16,687,289.06 verify

Received in USDC, any route$374,754,349.42 verify

Rail-verified share4.5%

Published addresses521 verify

★ Why we lead with the smaller number. These addresses receive money for many reasons, and only some of it is x402. One agent in this registry received over $2.5 million in USDC of which less than a hundred dollars came through an x402 payment we can reconstruct. Both figures are true; only one of them is x402 revenue. Publishing the larger one as "agent revenue" would be a claim we cannot support, so it appears here as what it is — all-route USDC received.

retained = received − outflow, clamped at zero.
Retained and processed are never summed. They measure different things.

Received is every USDC dollar that arrived at an address. Outflow is every dollar it sent back out. Retained is what it kept. A payment processor can move enormous volume and keep almost none of it — so ranking by volume would put the busiest plumbing at the top of a list of earners. The registry is a single list ranked by the x402 revenue we can verify, not by everything that flowed through an address. Each row carries its own role — service, circular flow, conduit or wallet — so a payment processor is visible as one rather than counted as an earner. Kept is published beside it and is the figure AQUIX exists to report.

★ Outflow and pass-through are different measurements and must not be read as the same thing. Outflow is lifetime: every dollar an address ever sent out, in any transaction, at any time. Pass-through is structural: the address forwards the money onward inside the very transaction that paid it, which is what makes it plumbing rather than an earner. An address can be 100% outflow and 0% pass-through — it earned the money and spent it later. The composition table on the home page uses pass-through; every dollar figure on this site uses outflow.

★ Outflow is measured in USDC only, so retained is an upper bound — an agent paid in USDC that spends in ETH shows no outflow at all. Measured 2026-08-10 across the published set: 47 of 121 agents sent native ETH, 677.99 ETH in total, none of it counted. Where we have measured it, the agent's own page says so. No dollar value is assigned to any token — pricing dozens of assets at an instant would invent a figure we could not defend tomorrow.

★ The same measurement found that about half of all apparent non-USDC outflow is not outflow: 513 token contracts, 14,119 transfers, moving tokens the addresses never received — anyone can emit a transfer event naming someone else as the sender. We exclude them, and an agent's page reports how many were excluded. Counts are always “at least”: 170 of those contracts imitate the USDC ticker using Cyrillic, Armenian, Lisu, Myanmar and Vietnamese lookalikes, and our detector for that is incomplete by construction. Tokens are identified by contract address, never by symbol.

Retained and processed are never summed: one is what an address kept, the other is what passed through it. The ratio between them — what we call the reality ratio — is how much of the money that moved actually stayed.

Current figures · snapshot 2026-09-20

Retained$564,467.78 verify

Processed$374,754,349.42 verify

Reality ratio0.15% verify

★ Retained is an upper bound, never an understatement. It is clamped at zero, so an address that spent more than it received reads as $0 rather than as a negative. Published retained can therefore overstate what was kept, and can never understate it.

What we mean by "agent"

The register is called the AI Agent Registry, and that is the name it keeps. But the honest description of what pays and gets paid on this rail is wider: sellers paid by machines — APIs, data feeds, compute, crawlers and payment plumbing. AI agents are a subset of that population, not the whole of it, and we would rather publish the subset as a measurement than assume it as a premise.

Every address we saw on the rail between 2026-09-13 to 2026-09-19, by what its behaviour looks like. Counted, not estimated:

What it looks like	Addresses	Share
PASSENGER	20,351	86.7%
UNDECIDABLE	2,387	10.2%
EARNER	493	2.1%
BOT-SHAPED	198	0.8%
CONDUIT	27	0.1%
INFRASTRUCTURE	10	0.0%

Of 23,466 addresses, 493 — 2.1% — behave like something earning a living. The rest are paying, passing through, or carrying other people’s money.

★ This is why the number of published addresses is small and will stay small. It is not a gap in coverage. Most addresses on a payment rail are not businesses, and a register that claimed otherwise would be measuring traffic and calling it commerce.

How a payment is recognised

AQUIX reads the x402 payment rail on Base. Real USDC paid for services, settled on-chain via EIP-3009 transferWithAuthorization, and reconstructed to the cent.

★ What this number does not include. x402 defines more than one settlement scheme. AQUIX reconstructs the exact scheme, which settles on-chain via EIP-3009 and can therefore be checked transfer by transfer. Payments settled through other schemes are not counted here — including usage-based billing that settles through a different contract, and batched or credit-backed settlement, which may not touch the chain at all. As those schemes are adopted, this figure covers a smaller share of x402 activity. A fall in it is not evidence that agents earn less.

A USDC transfer is counted as an x402 payment only when its transaction also carries an AuthorizationUsed event whose authorizer is the same party that sent the transfer. That is the buyer's own signature on the payment, on-chain, and it is what separates a paid API call from an ordinary token movement.

★ AQUIX reads the chain, not a facilitator. Every x402 settlement emits that event regardless of which facilitator relayed it, so coverage does not depend on any company's cooperation or on being listed in any directory. A directory can decline to list you. The chain cannot.

What the verdicts mean

Figures are measurements. A verdict is a classification: our judgement, reached by the published rules on this page from those figures. It describes how money behaves at an address — not whether the address is good, and not who operates it.

The full definitions, and the evidence, identity and status shown beside every verdict, live on the definitions page.

Service: Paid through x402, and not identified as a router, a rail or wallet software. Full definition.
Conduit: A payment router, rail or facilitator, identified by its role in the protocol. Full definition.
Circular flow: No named rule was decisive, and at least 30% of what it received returned to its own payers. Full definition.
Wallet software: A wallet product rather than a business, identified from its code or a published deployment. Full definition.

Current figures · snapshot 2026-09-20

Service456

Conduit21

Wallet software13

Circular flow31

Published addresses521 verify

194 of the services keep less than 0.05% of what they receive. The verdict describes how an address was admitted, not how much it kept.

Why "circular flow" exists, and what it does not say

Our rules that promote an address to a service refuse to do so when too much of its income returns to its own payers — a service that hands the money back is not earning it. But that test only runs when one of those rules fires. Where no named rule was decisive, the address used to be described as a service anyway, and the test was never applied.

circulation = money returned to its own payers ÷ money received.
At or above 30%, with no named rule behind the verdict, we publish it as circular flow rather than as a service — and we print the percentage.

★ This is a statement about the money, not about the operator. Value returning to the same counterparties is exactly what a trading agent, a settlement loop or a refund flow looks like. AQUIX publishes the measurement and the fact that no rule decided it. It does not infer intent, and it is not an accusation of wrongdoing.

Nothing is removed from the registry by this. These addresses keep their place, their figures and every dollar; what changes is the claim the page makes about them.

The internal classification, and why you will still see it

Behind the public verdict sits the classifier's own vocabulary — real-service (real dollars from many different payers in varied amounts: the pattern organic demand makes), bot-loop (high volume that does not translate into captured value), ambiguous (real signs, not enough to call), suspected-sybil (payers trace back to one funder) and dead/empty (captured almost nothing).

Those words still appear in each agent's verdict history, because history is never rewritten. A verdict recorded under an older vocabulary stays as it was recorded.

The signals, and why count alone is not one

Real dollars captured, payer diversity, and amount variety — read directly from the chain. Transaction count alone can mislead, so it is weighed against them.

Payer diversity: How many distinct addresses paid. Many independent payers is strong evidence of demand from outside. ONE PAYER IS NOT EVIDENCE OF A LOOP — it simply means this signal cannot tell us much here, so the verdict rests on the others. Whether money returned to the people who sent it is a separate measurement, and it is the one that decides. A single-payer address is therefore the weakest case this signal can describe, and the count is published rather than buried.
Amount variety: How many distinct payment amounts appear. Varied amounts suggest varied work. ONE AMOUNT IS NOT A FINDING ON ITS OWN — on a rail built for machine payments, a fixed per-call price is what correct pricing looks like, and a flat fee is a business model rather than a red flag. It is read together with payer diversity, timing and where the money went, never alone.
Sybil check — the funding graph: ★ Payer counts are forgeable. Two hundred “different” payers all funded by one wallet is one actor. So AQUIX traces where the payers themselves were first funded, and says when they lead back to a single source.
Volume backing: Whether headline volume is backed by payer diversity and amount variety, or by repetition. Elevated means the volume is not matched by the diversity behind it.
Confidence: How much data stands behind the verdict — not how good the agent is. High, Medium or Low, with the payer and amount counts that produced it shown beside it.

Current figures · snapshot 2026-09-20

Published addresses with a single payer173 verify

Published addresses521 verify

One payer is not a disqualification. It is the least evidence a verdict can rest on, which is why it is counted.

Names, and how much a name is worth

A name is only shown when a public source carries it, and the source and its kind are published beside it. AQUIX never invents a label.

Name verified: A second, independent signal agreed — a Basename resolved on-chain, or a service name the operator declares in a public x402 directory and serves from its own registered domain.
Domain: The domain actually serving the address’s endpoints. Observed, not attested.
Self-declared: The operator states this name in a public directory and AQUIX has found no second source for it.
Unnamed: The operator has registered no name in any public directory, on-chain registry or manifest we check.

Current figures · snapshot 2026-09-20

Name verified27

Named in some form84

Unnamed437

Published addresses521 verify

★ A brand in a subdomain is not an identity. A reseller can serve somebrand.example.com without any relationship to that brand, so a declared name only counts as corroborated when it matches the operator's own registrable domain. Publishing a third party's name as an address's identity would misattribute the revenue.

What we remove, and why

Not every address paid on this rail is a business being paid. Some are the rail: payment-protocol contracts, merchant disbursement plumbing, wallet software. They receive real USDC and would otherwise sit at the very top of this registry as the largest earners on Base. AQUIX removes 28 addresses by hand, and every one is listed here with how we know.

★ This is a hand-maintained backstop, so it can only ever contain what we have already gone and found. It is not a filter that catches this shape automatically — anything of this kind we have not found is in the registry right now, uncounted. That is the honest limit of the method, and it is why the list is published rather than described.

Removed from the register (28)

ERC3009PaymentCollector 0x35e6cb35…cd1f0e: payment rail / protocol contract — Commerce Payments (AuthCaptureEscrow ecosystem) · identity established by published · source
ERC3009PaymentCollector 0xa8a80741…91d988: payment rail / protocol contract — Commerce Payments (AuthCaptureEscrow ecosystem) · identity established by published · source
RelayRouterV3 0xb92fe925…4fff4f: payment rail / protocol contract — Relay (relay.link) cross-chain routing · identity established by published · source
AuthCaptureEscrow 0xbdea0d1b…420cff: payment rail / protocol contract — Commerce Payments Protocol · identity established by published · source
ERC3009PaymentCollector 0x0e3df951…7a7757: payment rail / protocol contract — Commerce Payments Protocol · identity established by published · source
Permit2PaymentCollector 0x992476b9…f0ab26: payment rail / protocol contract — Commerce Payments Protocol · identity established by published · source
PreApprovalPaymentCollector 0x1b77abd7…b94bc6: payment rail / protocol contract — Commerce Payments Protocol · identity established by published · source
SpendPermissionPaymentCollector 0x8d9f3493…4e7eaa: payment rail / protocol contract — Commerce Payments Protocol · identity established by published · source
OperatorRefundCollector 0x934907bf…02fa5d: payment rail / protocol contract — Commerce Payments Protocol · identity established by published · source
Transfers 0xeade6be0…a14971: payment rail / protocol contract — Coinbase Commerce Onchain Payment Protocol (predecessor of Commerce Payments) · identity established by published · source
x402ExactPermit2Proxy 0x402085c2…e20001: payment rail / protocol contract — x402 · identity established by published · source
Permit2 0x00000000…c78ba3: payment rail / protocol contract — Uniswap Permit2 · identity established by published · source
Relay Protocol: Approval Proxy 0xbbbfd134…b93d98: payment rail / protocol contract — Relay Protocol · identity established by published · source
Relay Solver 0xf70da978…a3dbef: payment rail / protocol contract — Relay Protocol · identity established by published · source
SplitsWarehouse 0x8fb66f38…661fb8: payment rail / protocol contract — 0xSplits v2 · identity established by published · source
Splits Swapper Implementation 0x7fcdd451…95fda7: payment rail / protocol contract — 0xSplits · identity established by published · source
RelayApprovalProxyV3 0xccc88a9d…c315be: payment rail / protocol contract — Relay Protocol · identity established by bytecode · identified from contract bytecode
splitsSmartVault 0x325bdf6f…e1d430: payment rail / protocol contract — 0xSplits · identity established by bytecode · identified from contract bytecode
Coinflow Credits Contract 0x853f2c11…2058f8: payment rail / protocol contract — Coinflow · identity established by bytecode · identified from contract bytecode
Coinflow payment router 0x31d058b5…962cd7: payment rail / protocol contract — Coinflow · identity established by bytecode · identified from contract bytecode
0xf6ee347d…043bd2 0xf6ee347d…043bd2: payment rail / protocol contract — Coinflow · identity not established — excluded on payment topology alone; no verified name · identified from contract bytecode
X402ProxyFacilitatorV6 (via ERC1967Proxy) 0x8e7769d4…36e2d6: payment rail / protocol contract — x402 · identity established by published · source
LiquidityGatewayUSDC 0xc4f00346…d00bb9: payment rail / protocol contract — unattributed USDC gateway/relayer · identity established by published · source
TokenStore 0x47c5d3fc…104fc3: merchant disbursement contract — Commerce Payments (AuthCaptureEscrow ecosystem) · identity established by published · source
SettlementRouter 0x73fc659c…14b29b: merchant disbursement contract — unattributed settlement router · identity established by published · source
TokenStore (SECOND, DIFFERENT implementation) 0x5bc9f446…98be88: merchant disbursement contract — Commerce Payments (AuthCaptureEscrow ecosystem) · identity established by published · source
UNNAMED — bytecode string 'LBSGasless' 0xcf3d89ae…f0b9fc: merchant disbursement contract — unknown · identity established by structural · source
TokenStore clone (impl 0xed411c46) 0xdf629f54…7c30ee: merchant disbursement contract — Commerce Payments (AuthCaptureEscrow ecosystem) · identity established by bytecode · source

Identified as wallet software, and published (13)

These are not removed. They are wallet or smart-account software rather than a business being paid, so they appear in the registry badged Wallet software, and are excluded from any count of earners. The manifest below assigns that role; it does not exclude the address.

★ How we know. Every address here was identified from the account’s own on-chain code — an EIP-7702 delegate or a smart-account implementation whose bytecode names the wallet software. That is the source for this class, and it is stated here because the wallet manifest records the software rather than a per-address citation.

0x08ae9867…912bb0 0x08ae9867…912bb0: wallet software — ZeroDev kernel
0x13bfc43f…0eb9a7 0x13bfc43f…0eb9a7: wallet software — MetaMask EIP-7702
0x309ecd45…f6d53f 0x309ecd45…f6d53f: wallet software — Trust Wallet
0x37b2a541…8533f1 0x37b2a541…8533f1: wallet software — MetaMask EIP-7702
0x3803a192…41101b 0x3803a192…41101b: wallet software — MetaMask EIP-7702
0x6302d9e6…35ad57 0x6302d9e6…35ad57: wallet software — ZeroDev kernel
0x6351c235…250d62 0x6351c235…250d62: wallet software — Uniswap Calibur
0x636678e4…d3f1e2 0x636678e4…d3f1e2: wallet software — MetaMask EIP-7702
0x6462f8f3…acc1d0 0x6462f8f3…acc1d0: wallet software — Uniswap Calibur
0x7d2ceb7a…b7bcfe 0x7d2ceb7a…b7bcfe: wallet software — MetaMask EIP-7702
0x888e5b82…7a7468 0x888e5b82…7a7468: wallet software — Trust Wallet
0xcf9223ec…e342fb 0xcf9223ec…e342fb: wallet software — MetaMask EIP-7702
0xf1eb97dd…8c3fa3 0xf1eb97dd…8c3fa3: wallet software — Uniswap Calibur

Claimed as infrastructure elsewhere, and NOT removed (9)

Addresses that other lists name as rails, which we checked and did not accept.

X402ExactPermit2Proxy: Not deployed on Base — a call for its code returned nothing on 2026-07-27, although the address is widely repeated in secondary write-ups. The canonical address in the x402 specification is deployed and is the one used. Recorded here so it is never re-added on the strength of a search result.
Relay ApprovalProxy v3: Not deployed on Base — a call for its code returned nothing. The published version table it appears in is not Base-specific, and those docs warn that addresses differ from chain to chain.
Relay ApprovalProxy v2.1: Not deployed on Base — a call for its code returned nothing.
Relay ApprovalProxy v2: Not deployed on Base — a call for its code returned nothing.
Relay Router v3: Not deployed on Base — a call for its code returned nothing.
Relay Router v2.1: Not deployed on Base — a call for its code returned nothing.
Relay Router v2: Not deployed on Base — a call for its code returned nothing.
0x86f8c5821f6c61b2296bba9cd2526415a385bc13: Not a disburser — a smart wallet. Its source is verified as a proxy to a Biconomy smart-account implementation, created by a bundler. A merchant using a smart account is still a merchant.
0x9c955c40dc98fce89a133f402ffbf94070e6e299: Rejected as a candidate. It is a verified proxy, but the implementation it points to is unnamed, so there is no identification at any tier. It credits one merchant, worth $607 — too little evidence for too little money.

Deliberately not included (1)

Addresses that look like infrastructure and are not, or are somebody else’s plumbing rather than a shared rail.

0xbb1b19f138db3925883a96ff7a304277460e0c99: A verified Gnosis Safe multisig holding $613M. A wallet, not a payment rail. The Safe factory would be protocol infrastructure; a single Safe created with it is not.

What this list cannot cover

Most x402 facilitators are ordinary wallet addresses rather than contracts, and no public roster of them exists for Base. This list therefore cannot be complete for facilitators.
0xSplits creates a new vault for every split, so they cannot be listed by address. They are recognised by the shape of their bytecode instead.
A protocol deployed after this list was last updated is invisible to it until someone refreshes it. That is a limit of any hand-maintained list, and it is stated here rather than hidden.
One address holds $1,998,877 from 1,223 payers, is unverified on BaseScan, and carries the bytecode string “LBSGasless”, which has no presence on the public web. It is shaped like a gasless relayer but is unnamed. It is excluded on structural identification — unconfirmed (decided 2026-09-17). A bytecode string can show what is present; it can never show what is absent, so it may still be infrastructure.
An address receiving $820,460 is a Coinbase deposit address. Decided 2026-09-17: it is not removed. An exchange deposit address is one user’s endpoint rather than shared infrastructure, and a merchant routing revenue straight to their own deposit address would otherwise be wrongly excluded.
Six Safe v1.4.1 multisig wallets appear in the register, $32,438 in total. Decided 2026-09-17: they are not removed. A Safe is a custody wrapper, and a merchant receiving into one is still a merchant. The Safe factory would be infrastructure; an individual Safe is not.
Registry #120 is a contract, not a person or a business, and it cannot be called by the people paying it: its only state-changing function requires the caller to be one specific other contract. It holds $1,399 from 147 payers. It is NOT removed from the register, because our infrastructure list identifies NAMED protocol deployments and we have not been able to name this one. What we measured is published here rather than acted on: an unnamed contract is not the same as an identified rail.
Twenty-four addresses in the register are EIP-7702-delegated wallets and three are ERC-1967 smart accounts, $649,361 in total. A merchant using a smart wallet is still a merchant, so these are not removed.
Two distinct TokenStore implementations exist, measured 2026-07-27, and they are not byte-identical. Any rule that matches clones against a single implementation address or a single code hash therefore catches only one family. The matcher needs a set of known implementations, and that set grows whenever an operator redeploys.
TokenStore is a clone template rather than one address: both entries are minimal proxies from the same template, and there are almost certainly more clones than the two observed — likely one per merchant. Listing them by address can never be complete; the durable fix is to match the clone template itself.
Discovery is bounded by who is already tracked. Disbursers were found by inverting the creditor relation over the tracked recipients, so a disburser whose merchants are all untracked is invisible to this method. Roughly ten thousand addresses receive x402 money behind two rails against eight tracked, so this list is a floor rather than a census.
A disburser entry admits addresses, and its failure mode is the mirror of a rail’s: a wrong rail entry excludes a real merchant, while a wrong disburser entry admits something that is not one. The structural tier is where that risk concentrates.
A rail that also disburses is the norm rather than the exception — four of the twelve candidates found are already listed as rails. The two lists overlap by design, and the scope rule uses their union.

What AQUIX does not claim to know

Stated limits are part of the output, not a failure of it.

★ The biggest limit, stated as a number. 4.45% of the dollars these addresses received are proven x402 by the settlement record — every one of them is a USDC transfer whose transaction carried a matching EIP-3009 authorisation, checked per payment, not sampled. The other 95.55% ($358,067,060.37) is money that genuinely arrived and that we cannot show was x402. It is not excluded, hidden or estimated — it is published beside the proven figure and counted separately, and this is why the site leads with the smaller number.

★ Two instruments, and they answer different questions. The figure above is computed from every settlement on the record. The provenance grade on an agent page is computed from a sample of at most six payments and describes the route a payment took, not whether a dollar was x402. A reader who takes the sampler for the proof will under-read us; a reader who takes it for a lifetime judgement will over-read us. They are labelled separately for that reason.

Settlements we did not capture: Measured, not estimated: across two independent windows on 2026-09-17 we captured 99.63% and 99.64% of x402 settlement value on the rail. The remainder — about 0.36%, roughly $425 in a window carrying $118,000 — is settlements routed through low-volume facilitators our learned set had not yet recognised. They are captured on a later pass once the facilitator recurs. This figure prices what we miss within the EIP-3009 record; it does not bound schemes that leave no such record at all — see the next two entries.
Base only: AQUIX measures the x402 rail on Base. Other chains are a different category and are measured separately, if at all — see below.
One hop: When a tracked address forwards money onward, AQUIX measures what it kept, not who ultimately received it.
Settlement methods: The x402 exact scheme has two asset-transfer methods on EVM. AQUIX reads EIP-3009, the one the specification recommends. A second method, Permit2, exists for tokens without EIP-3009; we do not read it, and measured it on 2026-08-11 at about $7 per week in USDC on Base. The upto scheme — metered billing, priced after the work is done — uses Permit2 only, so it is invisible to our method by construction rather than by choice.
What nobody can read: The batch-settlement scheme leaves no on-chain record at all. It returns a commitment identifier rather than a transaction hash, and settlement is deferred to a network binding. No observer can reconstruct it from a chain, including us. ERC-7710 delegation is likewise outside our reach, and its reference Delegation Manager has no code deployed on Base.
Retained is an upper bound: Clamped at zero — see “What is measured”.
Unregistered operators: Most operators publish nothing about themselves, so most published addresses carry no public identity beyond the address itself. The register says so rather than filling the gap with a guess.
Forward-only layers: Some measurements begin on a declared date and are never backfilled. A day that was never measured is left empty rather than estimated.
Snapshots, not a live feed: One snapshot per day at 07:00 UTC, timestamped and archived. The figures here are from 2026-09-20.

Data coverage

AQUIX reads the Base x402 rail continuously from 28 June 2026. A day is published only once its blocks have been read contiguously — the coverage watermark decides, not the calendar. That is why the first published day is 2026-07-07 rather than the day reading began: everything before it failed the contiguity test and is shown as unmeasured.

A server storage failure interrupted collection. 3 mornings between 2026-08-30 and 2026-09-02 produced no snapshot, and the gap is not continuous — collection resumed for part of it. These mornings are published as unmeasured, never as zero. Payment data for that period has been re-read from the chain and is complete. Three corrections touch this period, and each is recorded in full in the correction log. The settled half of the daily figures was missing for eleven days and has been recomputed from the settlement store (correction #6). That recomputation was itself wrong for the three largest of those days and was repaired on 2026-09-14 (correction #8). Separately, 67 published addresses carried a provenance grade weaker than the evidence we held, and the pages now lead with the settlement record (correction #7). No money figure was ever in question in any of the three — received, retained and the lifetime totals are computed from the settlement store directly. On the charts, days recovered this way are drawn paler and outlined, because the money was reconstructed from chain while no verdict was taken that morning and none can be. Where a day shows the settled figure in place of an all-route one that was never measured, the bar is lower than a normal day and is marked and labelled as such rather than compared to one.

Two counts, and they are not the same thing. Mornings with no collection at all — the run did not happen and no snapshot exists. That is the set named above, derived from the day pages this build contains, not typed. Days with no verdict — 20–31 August and 2 September, a wider window. For these the money was later re-read from the chain and is complete, but no judgement was taken on the morning and none can be added afterwards, because a verdict records what could be verified on the day it was written. Those dates therefore carry money and no verdict. A day can be in the second set without being in the first.

Other chains — measured separately, and labelled

These are not counted in the figures above. They are a different category of number and are labelled as such rather than blended into a headline.

Bittensor — subnet emissions: Emissions are verifiable per subnet, but the primitive is emitted TAO. That is not customer revenue, and it is not added to it.
Virtuals — Agent Commerce Protocol: Token, market cap and holders are checkable on-chain; reported revenue lives in a private ledger. AQUIX would show what is verifiable and label the rest as reported.
Olas, Fetch: Not measured. Listed so the boundary of this audit is explicit.

How often we are wrong

Every figure below is measured, not asserted, and is regenerated from the record. Most registries publish an accuracy claim. This one publishes its errors.

Self-contradiction rate (lower bound)

A published address counts here when the evidence stored beside its verdict contradicts that verdict — a loop verdict on an address that sent nothing out, a judgement passed on an empty sample, an address in scope for a register of paid agents with no payment recorded.

Published addresses whose stored evidence contradicts their verdict. Does not measure wrongly excluded addresses or internally consistent mistakes. Verify this figure.

★ Nought per cent is not a claim of accuracy, and we will not let it be read as one. It means only that no published verdict is refuted by evidence already sitting in our own store. That is the weakest possible test to pass: it cannot see an agent we wrongly excluded, and it cannot see a verdict that is wrong in a way our record is internally consistent about. The number below is the one that should worry a reader.

Thin-evidence verdicts

A published address counts here when its verdict rests on a single sampled payer. Payer diversity is the signal our own method names as the un-gameable one, so a verdict resting on one payer is the weakest we publish. It is not a claim that the verdict is wrong.

Published addresses whose verdict rests on a single sampled payer. Payer diversity is our own named signal, so these are the weakest verdicts we publish. They are not known to be wrong. Verify this figure.

Called bot-shaped on an address with no outflow at all (contradiction): 58 address(es) profiled, of which 0 are published.
Called a service on a single sampled payer (thin evidence): 175 address(es) profiled, of which 173 are published.

Current figures · snapshot 2026-09-20

Self-contradiction rate (lower bound)0 of 521 · 0% verify

Thin-evidence verdicts173 of 521 · 33.2% verify

Measured against ourselves and regenerated with each snapshot. The first figure being nought is not a claim of accuracy — see the note above it.

★ The same rate, priced. Those 173 addresses hold $128,696.72 between them — 0.03% of everything received, a median of $44.50 each. Both numbers are published because either alone misleads. The count is the honest headline and stays first: a third of the register does rest on one customer. The money says where that doubt actually sits — in very small addresses, not in the figures this site leads with. We would rather you could see both than take our word for which matters.

★ Until 2026-09-17 these two were published as one figure — an “error rate” of 33.2%, being 173 of 521. Every one of those 173 came from the single-payer test. Nothing has been removed and no address has been re-graded: 0 + 173 is the same 173. See correction #9.

What happens when we test against known infrastructure

We hold 45 addresses hand-verified as infrastructure — rails, routers, escrows and gateways, identified by bytecode or published deployment, never by heuristic. Of the 17 our pipeline had profiled, it called 14 of them a real service.

★ Why these three numbers differ. The 45 above is the hand-verified test set — every address we can label with certainty, used to measure how often the classifier is wrong. It is larger than the register's exclusions because it also holds addresses the register never saw. Of those, 28 are removed from the register (23 rails and 5 disbursers), and a further 13 are wallet software, which is a reclassification rather than a removal — those addresses stay in the register carrying the wallet verdict. Test set, removals and reclassifications are three different things.

1 reached the registry. The classifier did not stop them — a hand-maintained exclusion list did, and that list only ever contains what a human already went and found. Infrastructure of this shape that nobody has found yet is not excluded by anything.

What this number is not

—: This is a LOWER BOUND, not an accuracy figure.
—: It cannot see an agent wrongly EXCLUDED — only wrong verdicts among those published.
—: It cannot see a wrong verdict that is internally consistent.
—: The label set is adversarially biased: those addresses were hand-excluded BECAUSE they look like services.

Measured today · download the raw measurement.

Methodology versions

Past snapshots are not recomputed under later rules. A snapshot is a record of what the method in force that day produced. When the method changes, the change applies from that day forward; earlier snapshots stand as published, and the version they were made under is stamped on them. History is completed when recovered evidence proves a figure incomplete — and that is always published as a correction — but it is never quietly re-graded under a newer rule.

Version	Effective	What changed
v3.2	not recorded	The version in force for every snapshot this site has published. Its own adoption date was never recorded, and is not guessed here.
v3.2	2026-09-17	Display labels renamed and definitions rewritten. No rule, threshold or count changed.

★ This history begins where the record begins, and no earlier. The version number in force today is v3.2. Searching every commit of this codebase back to 2026-07-04, it is the only methodology version that has ever appeared in the published pages: there is no v1.0, v2.0, v3.0 or v3.1 in the record, in our internal documents, or in version control. The number was carried forward as a bare literal with no changelog kept behind it. We could write four earlier rows that would look entirely reasonable. We have not, because we cannot show them to be true, and a version history that is partly invented is worth less than one that admits where it starts.

Corrections

Corrections are public and permanent. When a published figure turns out to be wrong, the correction is published beside it and the original is not deleted.

The pipeline behind these figures has been checked by a second implementation — a separate codebase that shares no code with the pipeline and reads the chain itself. It is independent of the code, not of us: the same operator wrote and ran it.

Two audits exist and they count different things, which is why their totals differ:

The money primitives (2026-07-23) — 948 checks over the published figures, zero pipeline findings.
The provenance grades (2026-08-13) — 643 grades recomputed from raw chain data, 0 discrepancies. That is 643 addresses, not 643 checks.

★ And the limit, which is ours and is stated rather than buried: an audit can show that the code does what we said. It cannot show that what we said was right. A second implementation agreeing with the first proves the mechanism, not the premise — both inherit the same sampling and the same manifest, so a rail missing from that manifest is a blind spot they share. Only a check from outside our own definitions tests the premise, and that is owed.

★ The full correction log is at /corrections and the reconciliation report at /audit. Both are published and linked from every page.