Report 01 introduced the registered-vs-live gap. Report 02 named the readiness distribution — the small share of the index buyers could actually integrate with today. Report 03 goes one layer deeper into the trust signal, into the one signal that has been the hardest for the ecosystem to fake: has an agent actually been paid on-chain, and does that payment leave an auditable trail?
What "commerce-backed reputation" means, precisely.
ERC-8004's ReputationRegistry is the
on-chain feedback ledger — any wallet can post a review row about any
registered agent. That property is a feature (permissionless
attestation), but it is also the failure mode: the recent academic
study of the registries (arXiv:2606.26028) found that after Sybil
adjustment, the majority of feedback across all three chains
evaporates. Anyone with a handful of wallets can manufacture
endorsements at zero cost. Reputation-as-currently-deployed, on its
own, is not a trust signal.
What is a trust signal is a feedback row whose author and
subject demonstrably transacted on-chain — an ERC-8183
AgentCommerce job outcome, or the
equivalent hosted Virtuals ACP job pattern. Both flows settle a real
USDC (or ETH) payment between two agents, and both then write a
feedback row into ReputationRegistry
keyed to the completed job. A farm of wallets that never paid the
agent cannot mint one of these rows without paying the agent first —
the cost floor is real and the trail is public. We call this
commerce-backed reputation.
There is exactly one canonical definition of this predicate in our
code — smartcontractauditpro/commerce_backed.py
— and every surface that quotes a commerce-backed number derives from
it: the SQL aggregation that powers
/v1/public/stats.commerce_backed_agents,
the per-agent classifier that builds the
objective_signals.commerce_backed
block on every paid /v1/intel/agent
response, and the cohort membership on the
/commerce-backed-agents hub.
A divergence-regression test walks the live database and fails if the
two predicates ever stop returning the same set of rows. There is no
second definition to disagree with.
The detection layers, briefly:
- T1 — job-URI pattern. The feedback row's
feedback_urior the agent's endpoint matches a known hosted ACP job pattern (acp.virtuals.io/jobs/<n>,api.acp.virtuals.io/jobs/<n>, bare/jobs/<n>/feedback). - T3 — allowlisted hook contract. The row's
client_addressis a hook / escrow contract we've curated as belonging to an atomic-job flow (our ownAgentCommerce.soldeployments live here). - T2 — author-is-contract. Booster only, never a classifier by itself. The 2026-07 sweep showed batch-bot scorecard writers publishing from smart-accounts; treating "author is a contract" as sufficient would over-classify hundreds of thousands of bot rows as commerce. Real ERC-8183 hook writes always carry T1 or T3 evidence in addition.
The cohort, measured live.
Here are the current commerce-backed counts across the whole index,
set alongside the totals so the shape of the gap is legible. Every
number is baked in from
/v1/public/stats on every deploy
and refreshed by js/intel.js on every
visit.
| Measure | Value |
|---|---|
| ERC-8004 agents indexed (Base + Ethereum + BNB) | 113,188 |
| ReputationRegistry feedback events indexed | 277,710 |
| Agents that have received any feedback at all | 29,128 |
| Commerce-backed agents (got-paid cohort) | 44 |
| Job-outcome feedback rows (T1 / T3 evidence) | 979 |
| Distinct wallets writing commerce-backed feedback | 109 |
Per-chain context.
The commerce-backed cohort is concentrated where the ACP tooling was deployed first — feedback event volume and cohort size mirror the indexer roll-out, not the underlying capability of the chains. The table below reads honestly: a zero means we have not yet indexed any job-outcome-shaped feedback row for that chain, not that no agent on that chain has ever been paid.
| Chain | Feedback events | Agents w/ feedback | Commerce-backed |
|---|---|---|---|
| Base | 277,710 | 29,128 | 44 |
| Ethereum mainnet | 0 | 0 | 0 |
| BNB Chain | 0 | 0 | 0 |
Feedback rows and cohort membership are recorded from the day our indexer switched on for a given chain. Base was first and has the deepest history; the other two chains will populate as their indexer coverage catches up. Liveness itself is tracked starting 2026-07-17 across all three chains.
Why the got-paid signal beats self-reported endorsements.
Three concrete reasons the commerce-backed subset is the honest read.
The evidence is atomic with the payment. An ERC-8183 job settles the USDC transfer and writes the feedback row in the same atomic flow (or, in the hosted Virtuals ACP case, in an equivalent server-side atomic write keyed to the settled job id). The trail is a single on-chain sequence — payment first, feedback second, both indexed. You cannot mint one without the other. A Sybil endorsement farm has to first spend real USDC on the agent before it can write a review row that counts, and at that point the "farm" is just paying customers with an axe to grind — which is a very different signal.
The cost floor is what makes it hard to fake. A registration mint is free-plus-gas; a self-attested review is free-plus-gas; a paid job is a real payment. The set of agents willing to pay themselves in a loop to manufacture commerce-backed rows is small, self-defeating (the payment is real USDC moving between related wallets, not a marketing spend), and readable to anyone who cares to look — we surface hook-type classification and by-service breakdown on the paid response for exactly that inspection.
It composes with the other signals cleanly.
Commerce-backed rows do not replace liveness or capability signals —
they layer on top. An agent can be Transact-ready today but not
commerce-backed (nobody has hired it yet), or commerce-backed but
currently unreachable (was live, isn't now — the reputation trail
remains). We fold commerce-backed into the AI Verdict block on every
paid /v1/intel/agent response as a
separate axis alongside the Sybil-adjusted reputation score, precisely
so a buyer can weight them independently.
Methodology, stated inline.
The counts above come straight from the SQL aggregation in
audit_tracker._compute_public_stats,
which walks reputation_feedback with
the WHERE clause derived from the pattern constants in
commerce_backed.py. Revoked rows are
excluded (is_revoked = 0). The
per-agent classifier uses the same pattern constants — layered
evidence, T1 or T3 required, T2 booster only — so the aggregate and
per-agent readouts cannot drift. If you want the raw numbers, fetch
GET /v1/public/stats (free, no key).
If you want the cohort, walk
/commerce-backed-agents —
ranked by on-chain job-outcome count, one row per commerce-backed
agent, each row linking to a free per-agent page with the job count
and readiness bucket.
Three commerce-backed agents you can inspect right now:
- Lunara — Base, one of the deepest job-outcome rows in the current cohort.
- Ethy AI — Base, hosted ACP integration with an actively growing job trail.
- Capminal — Base, another top-of-cohort commerce-backed profile.
What this tells us three reports in.
Report 01 said the registration count is not the interesting number; Report 02 said the readiness distribution is a much smaller, more useful set. Report 03 says the same thing about reputation — the raw feedback-event count is not the interesting number; the commerce-backed subset is. Every one of those steps narrows the pile by an order of magnitude, and every one of them lands on a small, coherent set that is what a buyer would actually pay to receive. That progression is not a coincidence. It is the shape of every maturing software ecosystem — the honest total is always smaller than the marketing total, and the value is in a data source willing to show you both.