ERC-8183 Agentic Commerce — Can an Evaluator Trust the Provider? Joining Draft ERC-8183 to Live ERC-8004 Reputation

What ERC-8183 is — the job lifecycle, in one picture

The draft describes a three-role on-chain job:

• Client. Opens a job with a scope and a budget, deposits funds into escrow at job creation.
• Provider. Executes the work off-chain (an AI agent, a tool-using agent, a human-plus-agent team) and marks the job delivered when done.
• Evaluator. Reviews the delivered work against the agreed criteria and attests PASS / FAIL. On a PASS, escrow releases to the provider; on a FAIL, the draft describes refund paths and dispute hooks.

A fourth, optional role is the reputation hook: a contract that fires at a specific point in the lifecycle (for example, after an evaluator PASS) and writes a feedback row into the ERC-8004 ReputationRegistry on behalf of the client. That hook is the clean, composable path by which real paid jobs under ERC-8183 would populate the reputation layer the whole ecosystem already shares.

How ERC-8183 composes with ERC-8004

ERC-8183 is a commerce layer. ERC-8004 is an identity + reputation layer. The two were designed to stack:

• Provider is identified by an agentId in the ERC-8004 IdentityRegistry (0x8004A169FB4a3325136EB29fA0ceB6D2e539a432 on every EVM chain that supports the standard).
• Reputation feedback is written to the ERC-8004 ReputationRegistry (0x8004BAa17C55a88189AE136b182e5fdA19dE9b63). The registry does not care who writes the row — a human-authored EOA review and a hook-contract write look the same at the eth_getLogs layer. The distinction lives in the row’s feedbackURI, the client address, and whether that author is on an allowlist of known hook/escrow contracts.
• An ERC-8183 evaluator PASS can therefore drop a strongly signed row into the same registry everyone else is already reading, with its own job URI as evidence. That is the mechanism by which commerce produces reputation rather than reputation sitting as a separate narrative layer.

We treat that composition as the central operational question: of the agents already registered under ERC-8004, how many would pass an ERC-8183 evaluator’s pre-escrow reputation check today? The section below is our answer, measured on the chains we index.

The data today — who would an evaluator trust?

Across Base and Ethereum mainnet, our live ERC-8004 index tracks 26,978 agents in total ( 23,705 on Base and 3,273 on Ethereum). On the full registry (including registrations outside our index), 155,767 ERC-8004 agent IDs have at least one row in the ReputationRegistry across a pool of 710,900 indexed feedback events. The pre-escrow filter an ERC-8183 evaluator would want to apply is tighter than “has any feedback”:

• Commerce-backed providers (strict). The subset whose feedback rows match a Virtuals ACP job URI pattern or come from an allowlisted ERC-8183-style hook/escrow address: 51 provider agents (across 1,003 commerce-backed feedback events).
• Active evaluator cohort. Distinct wallets that have ever written a commerce-backed feedback row: 117. This is the ceiling on “how many addresses have ever attested a paid ERC-8183-style job outcome at all” — not an active-this-month cohort.
• Live reachability. Of all indexed agents, 2,537 currently answer at their advertised endpoints (a 9% liveness rate). An ERC-8183 client who cannot reach the provider’s endpoint cannot start the job in the first place, so endpoint liveness is a hard pre-filter sitting upstream of reputation.

Two numbers in that list carry most of the trust-filter weight: the commerce-backed provider count and the active-evaluator wallet count. Both are much smaller than the raw registered or raw reputation populations. An evaluator that requires “at least one prior commerce-backed row from a wallet that is not the provider’s own account” is running a tighter filter than the raw numbers suggest, and the gap between the three cohorts (registered → any-feedback → commerce-backed) is exactly what an ERC-8183 escrow decision has to navigate.

Chain coverage — what we measure vs what we index

The commerce-backed and reputation numbers above are measured on the chains the paid /v1/intel/* API covers (Base and Ethereum). We also publish a dated public-RPC Arbitrum ERC-8004 census at 2026-10-07 as a measured, not indexed datapoint: 108 of 1,604 registered agents on Arbitrum One (6.73%) carry at least one ReputationRegistry feedback row, from 36 distinct feedback clients across 973 events — a full-cohort, full-history count, not an extrapolation. ERC-8183-style evaluators on Arbitrum would be reading that same registry today; the paid API does not yet serve those rows. For the full narrative read, see the companion Arbitrum census post.

What this means for someone building on ERC-8183 today

Three operational implications fall out of the shape above:

• Pre-escrow filtering is small-cohort work. A strict “has a prior commerce-backed row” filter cuts the eligible-provider pool from the full indexed set to the commerce-backed count shown above. Loosening the filter to “any feedback” opens the pool substantially but brings back the Sybil and self-feedback problem the commerce-backed cut was designed to avoid. A client building on ERC-8183 has to pick which end of that tradeoff they want.
• Evaluator identity may matter as much as any score. When only a handful of wallets have ever attested a paid job, knowing which wallet vouched for a provider can tell you more than a composite number. An ERC-8183 UI that surfaces “this provider was attested by N known evaluators” is doing a different (and more useful) thing than one that shows a composite number.
• Reputation hooks make commerce accumulate reputation. The ERC-8183 reputation hook is the mechanism by which paid-job history becomes legible to the next client. The size of the commerce-backed cohort as of this reading is the installed base of that mechanism to date.

Honest limits

• ERC-8183 is a draft. Wording, roles, and hook signatures may change between the version this post was written against and the version that is eventually Final. Every claim about ERC-8183 shape above traces back to the Magicians thread cited at the top; we do not reprint wording we have not verified there.
• Our index covers Base and Ethereum. Arbitrum is measured in a separate dated census (above), not served by the paid API. Other EVM deployments are not currently indexed. An ERC-8183 provider outside Base + Ethereum will not appear in these counts; its absence is not a trust signal.
• Reputation is permissionless. Any wallet can write any row; the commerce-backed cut uses two layered predicates (job-URI pattern + allowlisted hook/escrow address) to filter noise, but it cannot promise that every row it includes represents a well-formed job outcome. See the commerce-backed dataset page for the method in full.
• No evaluator score is published here. This page reports the size of the commerce-backed cohort and the number of evaluator wallets. Our combined AI Verdict is part of the paid /v1/intel/agent response, which also returns the underlying inputs so you can check the result.