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-09-02: 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 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.

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-09-01, 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?

Every data source will carry its own visible as-of date and last successful refresh, listed in this section. Until the engine is live there are no data feeds to stamp — the section exists now so that its address never moves. Page-level freshness works today: every page on this site carries a “Last reviewed” date that is never newer than its actual last review.

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.

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 · #listing-concentration · #seller-attribution · #provenance · #recompute · #data-freshness