About · Methodology

Why should you believe our numbers?

You shouldn’t — you should be able to check them. That is the whole method. This page explains, in plain language, what our numbers mean and how anyone can re-derive them from public data.

Status, as of 2026-10-14: The verification engine is live and computing under method score-v1.0.0: see the verified-revenue rankings and market data. Every published row carries provenance naming its exclusion-list version and catalog snapshot, each a public URL (under /data/flags/ and /snapshots/) — the inputs you need to recompute it. This page updates in the same publish as any change to the engine’s method specification, with a visible changelog.

What bar do we hold ourselves to?

One rule: every number this site publishes must be recomputable from public or chain data. If a number cannot be recomputed by someone who is not us, we do not publish it. A sentence without a number beats a number without a receipt.

What will “verified revenue” mean?

The definition, quoted from the glossary, where it is fixed:

Verified revenue is revenue confirmed from public chain data, not self-reported — and attributed per seller address, not per listing.

Here is the walkthrough of what the engine will do. It reads public chain records — USDC transfers on the Base network, where x402 payments settle. It filters out dust and self-dealing (wash trading). It attributes what remains to each seller address. Then it sums, and stamps the sum with an as-of date. The site’s own wallets — its test-purchase and Bazaar keep-alive wallets — sit on the same versioned exclusion list, flagged self, and never count toward any seller’s verified revenue.

The precise rule — thresholds, time windows, exclusions — is being fixed in the engine’s method specification. Once that specification is frozen, its definition will be quoted here verbatim, with its version stamp. This page renders the specification in plain language; it never invents its own version of the rule.

Why per seller address, not per listing?

Because on a public ledger, the address is what actually gets paid. One address can stand behind several catalog listings. If a seller runs three listings that all pay into one address, the chain shows one earning address — not three earning businesses. So revenue is attributed to the address, and the sibling listings share that one attribution. Counting the same revenue three times would be exactly the kind of inflation this site exists to filter out.

What will the “verified” label mean — and not mean?

“Verified” is this site’s label word, and it will carry one meaning: confirmed from public chain data by the method on this page. A verified figure means the money moved on-chain, passed the filters below, and can be recomputed by you. It does not mean we endorse the seller, and it does not mean the service is good — chain data cannot prove that, and we say so below. A listing without the label is listed-only: not checked, not accused.

How is a listing’s capability category assigned?

A capability category is the published label for what a listing sells — one of 11 fixed values. The list is frozen in the registration specification (registration-schema-v1), the same list a seller answers from when registering. A category helps you find sellers by what they claim to do. It is a claim, never our endorsement: find by claim, trust by evidence.

Unregistered listings are categorized by a frozen, published rule: capability-v1. The rule reads the seller’s own title and description — nothing else — against a fixed list of keyword patterns in a fixed order, and the first match decides. Anyone running the same rule over the same text gets the same category we publish; that is why the rule is keywords, not an AI classifier. Categories assigned this way carry an “auto-assigned” label wherever they appear, and every such label links to this section.

A registered seller’s own category answer overrides the automatic one for all of that seller’s listings, labeled “seller-asserted” instead. The override changes the label and the bucket, never the ordering — registration adds data, never rank.

When no pattern matches, the category is “other” — the honest escape, not a judgment. At the rule’s freeze on 2026-09-03, 27.7% of the 15,427 listings live that day — just over one in four — landed there, mostly format converters and small utilities the 11 values have no home for. We publish that share rather than force listings into wrong buckets; it belongs to the catalog-snapshot class defined below, and recomputes by running the frozen rule over the catalog.

Think a category is wrong? Use the contact path on About. A confirmed miss is fixed by correcting the published rule — shipped as a new method version, announced before it takes effect — or by the seller registering. Never by an unlogged manual edit.

Which signals is the engine built to check?

Seven, each with a plain meaning here and a precise rule in the engine’s method specification. Method constants — the exact floors, bands, and thresholds — live in that specification only. They will be published here, with a version stamp, when the specification freezes. This page never states a constant the engine has not fixed.

Real-buyer filter

Separates production buyers from noise: test traffic, dust, and self-dealing. A payment only counts toward verified revenue if it comes from a buyer that looks like a real, independent customer. “Real buyer” names this filter only — the published label is always “verified.”

Dust floor

Filters out payment amounts too small to indicate real usage, before anything is summed. Dust inflates naive totals. The exact floor is a method constant, set in the engine’s specification and published here when frozen.

Buyer concentration

Measures how spread a seller’s revenue is across distinct buyers. Revenue that depends on a handful of addresses is a concentration risk — and can be a sign of one actor paying itself. Concentrated revenue is flagged in the open, not hidden.

Price sanity

Checks whether observed payment amounts fit the service’s own advertised pricing. Payments far outside that band are a signal that the volume is not ordinary usage. The band is a method constant, set in the engine’s specification.

Farm detection

Checks whether one actor stands behind a flood of near-identical listings — a listing farm. Sellers matching the pattern will carry a visible farm flag. A flag is a label you can see and question, never a silent deletion.

Longevity

Measures how long a seller has been earning from real buyers. A steady months-long history and a two-day spike are different facts, and the difference will be visible.

Trust score

The engine will also combine the signals above into one composite score per seller, published alongside them. The formula and weights will live in the method specification, versioned like everything else. The score is a summary, never a substitute — the underlying signals stay visible so you can see why a score is what it is.

What counts as recomputable?

Two classes, and every published number will declare which one it belongs to:

• Chain-derived — re-derivable by anyone replaying public chain records for a stated window. This meets the strict bar as-is: the ledger is the same for everyone.
• Catalog-snapshot — derived from the state of a living catalog at a moment. A living catalog cannot be replayed to a past date, so a number in this class is recomputable only if we also publish the archived snapshot it came from. A weaker class than chain-derived, and labeled as such.

Where are the market numbers?

Held, on purpose. During research we measured parts of this market — including how concentrated catalog listings are among a few sellers. We are not publishing those figures yet, because as they stand they fail our own bar: the engine does not yet refresh them, and the snapshots behind them are not yet published for you to check. A number we cannot hand you the receipt for does not go on the site — not even ours.

What we can say without numbers: usage in the agent economy is growing, and the section below states what we can and cannot measure. When the engine recomputes the market figures, they will appear with full provenance, and this anchor is where the listing-concentration method will be documented.

How will every number be shown?

Every figure will render with its provenance attached: the value, its source, its as-of date, its recomputability class, and a link to recompute it. No bare numbers, anywhere on the site. If a figure ever appears without those parts, that is an error — report it.

What do we refuse to publish?

• Self-reported revenue. A seller’s word about its own earnings is a claim, not data.
• Engagement counts — stars, comments, reactions. They can be produced in bulk by the same automated agents they claim to measure.
• Catalog listing counts presented as market size. Listing is free and unchecked; a listing count measures listings, not businesses.
• Token prices. Ever. This site is about payments, not trading.
• Anything that requires trusting us. If the only path to a number runs through “take our word for it,” the number does not publish.

How would you recompute it yourself?

The engine will read public sources, and this section will always name them. As of 2026-10-14, the planned sources are:

• The Base network’s public ledger — the USDC transfer records that x402 payments settle in. Anyone can read the same ledger. Caveat: the ledger proves payment, not delivery.
• The x402 Bazaar catalog — Coinbase’s public, machine-readable catalog of payment-gated x402 services, which maps listings to the seller addresses they pay into (catalog documentation). Caveat: it is a living catalog, so using it honestly requires published snapshots — see the classes above.
• x402scan — an independent public explorer for the x402 ecosystem, useful as a cross-check we do not control. Caveat: it is a third party; we cite it as corroboration, never as the source of a verified figure.

When the first numbers publish, this section will carry the pinned details: the USDC contract address on Base, the exact queries and windows, and the archived catalog snapshots — enough for you to reproduce every headline figure. That is a publishing condition, not a courtesy: a figure whose recompute path we cannot hand you does not publish.

How fresh is each data source?

Refresh status, as of 2026-10-14: the refresh is on. The warehouse reached Cloudflare D1’s hard 10 GB per-database limit in September 2026, was rebuilt on the rolling-retention schema described below, and the refresh was switched back on on 2026-10-01. The schedule, in UTC: the x402 Bazaar catalog is snapshotted every day at 03:10; tracked sellers’ payments are synced from the chain every night between 00:00 and 03:00; scores, rankings and market figures are recomputed and published every Monday from 03:40, and the weekly statistics are computed right after, for the Monday-to-Sunday week that has just closed.

Every data page shows the as-of date of the figures it displays and the method version that computed them. Pages without live data carry a “Last reviewed” date that is never newer than their actual last review.

On the raw payment log: we keep every individual on-chain payment for a rolling window (100 days), long enough to cover the 30- and 90-day windows the numbers use. Older payments are folded into a per-seller, per-buyer running total — same amount, same count, same first and last date — and the individual rows are dropped. Every published figure, including lifetime totals and first-payment dates, reads the recent payments and the folded totals together, so nothing changes; this is storage housekeeping, not a change to how anything is counted.

What can chain data not prove?

Two honest limits, stated before anyone states them for us.

First: delivery. A chain record proves money moved. It does not prove the work ran, or ran well. A receipt for the work itself is what current standards efforts are trying to build — how trust works covers that gap.

Second: rails that settle off the public ledger. Of the four rails this site covers — AP2 & UCP, Stripe machine payments, Verifiable Intent & Agent Pay, and x402 — x402 is the one whose payments settle on a public ledger today. The others authorize or settle inside card and processor networks, which have no public ledger for us to read. That is a statement about data availability, not about merit. If a backer publishes settlement data, we will say exactly what it lets us check; until then, those slots read “not yet published by” the backer — stated plainly, never padded.

Is agenteconomy.to this site?

No. agenteconomy.to is a different site. Its totals count raw settlement events across 12 chains (as of 2026-10-13); ours count verified payments to the sellers we track.

How do we check other people’s numbers?

The same rule, pointed outward. When a claim about an AI agent making money travels far enough, we quote it word for word, pull the venue’s public record — on Polymarket and other on-chain venues every account’s trades, deposits and daily profit-and-loss are public — recompute the claimed window ourselves, and print the claim’s numbers beside the record’s. Each check names one of six statuses, defined on the fact-check index, lists what the record cannot show, says what evidence would change the status, and ends with the exact API calls to recompute it. Brokerage claims cannot be checked this way, because account statements are private; those carry the status unverifiable by nature rather than a guess. The method in six steps is on the index page.

What happens when we get something wrong?

Substantive errors are fixed visibly: the fix ships with a note in the page’s changelog, so the record of being wrong stays on the record. Typo fixes are the only silent fixes. To report an error, write to corrections@agenteconomy.cloud — the contact path lives on About. Reader reports are a standing trigger for review.

Stable anchors on this page

These anchor ids are frozen. They will never change after first publish, so any link or citation that targets them stays valid:

#verified-revenue · #real-buyer-filter · #dust-threshold · #dust-floor · #buyer-concentration · #price-sanity · #farm-detection · #farm-flags · #longevity · #trust-score · #verified-tier · #capability-categories · #listing-concentration · #seller-attribution · #provenance · #recompute · #data-freshness · #fact-checks