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 data section below is our best answer, measured on the chains we actually index.

The data today — who would an evaluator trust?

Across Base and Ethereum mainnet, our live ERC-8004 index tracks — agents in total ( — on Base and — on Ethereum). Of those, — agents have at least one row in the ReputationRegistry across a pool of — 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 under our canonical smartcontractauditpro/commerce_backed.py predicate: — provider agents (across — commerce-backed feedback events).
• Active evaluator cohort. Distinct wallets that have ever written a commerce-backed feedback row: —. 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, — currently answer at their advertised endpoints (a —% 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 prior commerce-backed row” filter cuts the eligible-provider pool from the full indexed set down to a two-digit cohort today. Loosening the filter to “any feedback” opens the pool substantially but re-introduces the Sybil / self-feedback problem the commerce-backed cut was there to solve. A client building on ERC-8183 has to pick which end of that tradeoff they want.
• Evaluator identity is itself a credential. With a small active-evaluator cohort, the identity of the evaluator wallet that previously attested a provider is a stronger signal than any particular score. 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. BNB Chain and 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 cites commerce-backed cohort size and active-evaluator count. It does not publish an aggregate “trust score” derived from those — our AI Verdict and its weightings live behind the paid /v1/intel/agent endpoint, where the method is documented and the raw inputs are surfaceable so a buyer can second-guess the composite.