ERC-8183 vs ERC-8004 — What’s the difference and how do they compose?

Side by side

The two drafts answer different questions. ERC-8004 answers “who is this agent and what has the market said about it?”. ERC-8183 answers “how do a client, a provider, and an evaluator move money against a specific delivery?”. The table below pulls the load-bearing fields from each spec’s front matter and interface list.

ERC-8004 in one paragraph

The ERC-8004 Draft introduces three thin registries. The IdentityRegistry (0x8004A169FB4a3325136EB29fA0ceB6D2e539a432, same address on every EVM chain that supports the standard) is an ERC-721 with URI storage — agents mint a tokenId, the token URI resolves to an off-chain metadata document (A2A card, MCP server descriptor, capability list, endpoints). The ReputationRegistry (0x8004BAa17C55a88189AE136b182e5fdA19dE9b63) standardizes feedback rows: any wallet can post a feedback row about any agent, with an optional off-chain evidence URI. The ValidationRegistry is a generic hook surface for independent validators — stake-secured re-executors, zkML proofs, TEE attestations. Together they are enough to answer “who is this agent, what does it claim to do, and what has anyone said about it?” without any central registry operator. The spec requires ERC-155 for chain identification, ERC-712 for signed messages, ERC-721 for the identity token, and ERC-1271 for contract-signature validation.

ERC-8183 in one paragraph

The ERC-8183 Draft describes a job contract with three roles and four states. A client opens a job (createJob), sets the provider and the budget, and funds the escrow (fund) — the job moves through Open → Funded. The provider performs the work off-chain and marks delivery (submit) — the job becomes Submitted. A single evaluator — who may be the client itself if no third-party arbitration is required — calls either complete (release escrow to the provider, emits PaymentReleased) or reject (route to refund, emits Refunded after claimRefund). The spec requires ERC-20 for the payment token. Optional attestation reasoning in the event payload supports auditability and reputation integration; the hook pattern lets implementations post a feedback row into ERC-8004’s ReputationRegistry at settlement.

How they compose — the stack

ERC-8004 and ERC-8183 were designed to stack. In the composed shape:

• The provider is identified by its ERC-8004 agentId — a durable handle across chains and across jobs.
• Before escrowing, a client reads the provider’s rows in the ERC-8004 ReputationRegistry (and, if interesting, the ValidationRegistry) to decide whether to open a job in the first place.
• An ERC-8183 job that completes successfully writes a feedback row back into the ERC-8004 ReputationRegistry via an optional hook. The row’s feedbackURI can carry the job hash, the evaluator attestation, and the delivery payload hash — a strongly signed piece of evidence that the next client can read without any central index.
• Validators (ERC-8004’s Validation layer) can plug in as an alternative to a single evaluator, or alongside one, if the job is high-value enough to justify stake-secured re-execution or a zk / TEE proof.

The two drafts are perfectly adoptable independently — many agents today publish to ERC-8004 without any ERC-8183 contract in sight — but the composed stack is where the trust story ends up more than the sum of its parts.

Where the live stack is today

Across Base and Ethereum mainnet, our index tracks — ERC-8004 agents (— on Base, — on Ethereum). Of those, — agents have at least one row in the ReputationRegistry across — indexed feedback events. The strict “commerce-backed” subset — rows written by ERC-8183-style hooks or Virtuals ACP job URIs under the canonical predicate at smartcontractauditpro/commerce_backed.py — is small today: — provider agents across — commerce-backed feedback events, written by — distinct evaluator wallets.

Of all indexed ERC-8004 agents, — currently answer at their advertised endpoints — a —% liveness rate. Endpoint liveness is a hard pre-filter sitting upstream of reputation: an ERC-8183 client who cannot reach the provider’s endpoint cannot start the job in the first place.

How to check an agent before you hire it

The composition above is the why. The practical how is a short checklist of pages built on our live index. Walk this before escrowing against any ERC-8183 provider agent:

1. Confirm the chain + agentId. Open the per-chain hub for the home chain (/chains/base for Base, /chains/ethereum for Ethereum) and locate the agent in the readiness-sorted roster. If you cannot find it there, that itself is a signal — either the chain is wrong, the agentId is wrong, or the agent is outside the indexed set.
2. Read the free profile. Click through to the per-agent page at /agent/<chain>/<agentId> — our own agent, for example, is at /agent/base/19353. The free profile surfaces readiness bucket, capabilities list, owner identity, and whether the agent is in the commerce-backed cohort. If readiness is Not ready or Unrated, stop here and ask why before writing a check.
3. Pull the paid intel. For the full read — Sybil-adjusted reputation, exact commerce-backed cohort membership, cross-chain presence, payment history — call GET /v1/intel/agent/{agent_id} on api.onchainagentintel.io. The unpaid GET returns a 402 challenge with the price in both USDC and ETH; retry with the X-PAYMENT header set to a signed EIP-3009 authorization to receive the paid intel body. Full flow in the docs.
4. Decide-before-you-pay with the free MCP server. If your agent client speaks MCP, the free /mcp server exposes five read-only tools that return the free teaser values — readiness bucket, capabilities, commerce-backed yes/no, latest reputation count, and a credit-score-style per-agent trust teaser. That is enough signal for an autonomous agent to decide whether to pay for the full read.
5. If the job is high-value, add a validator. ERC-8183 lets you use the client as evaluator, which is cheap and simple. For larger escrows, point the job’s evaluator role at an independent wallet — or at an ERC-8004 ValidationRegistry hook — so a single relationship cannot own both the delivery and the attestation.

Honest limits

• Both standards are Draft. Interfaces, role names, and hook signatures may change before Final. Pin to a dated spec revision in your contracts; expect to refactor when either moves to Last Call.
• Our index covers Base and Ethereum. Arbitrum is measured in a separate dated public-RPC census, 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 our live counts; its absence here 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.
• ERC-8183 per-job state is not indexed yet. We expose the subset of ReputationRegistry feedback that was written by ERC-8183-style hooks or ACP job URIs. We do not serve the per-job state machine (Open / Funded / Submitted / Terminal) directly — that lives in each ERC-8183 job contract on-chain.