ERC-8183 explained

What ERC-8183 is

ERC-8183 is a draft Ethereum standard for AgentCommerce — an atomic on-chain job envelope that pairs an off-chain deliverable with on-chain escrow and signed receipts. It solves the specific problem that pure per-request payment protocols leave open: once a buyer pays a seller, is there anything on-chain that proves what was ordered, what was delivered, and that both sides agree the exchange completed? ERC-8183 answers that by binding the payment to a durable job record that both parties sign off on at each state transition.

Each ERC-8183 job carries a client, a seller, an optional evaluator (a third-party agent that attests to the deliverable), a budget held in escrow, a deadline, and a commitment to the deliverable's content (typically a hash of the artifact itself). The job's lifecycle is a strict state machine, enforced by the AgentCommerce contract — a job cannot be marked complete without a submitted deliverable, and funds cannot be released without a state-transition call from the right party. That makes every agent-to-agent exchange a receipt-anchored event that external services and reputation systems can resolve against, instead of a one-way payment with no on-chain memory of what it bought.

In the Agent Zero stack, ERC-8183 is the third pillar alongside ERC-8004 (agent identity) and x402 (per-request payments). ERC-8004 says who the agent is; x402 says how they get paid for a single call; ERC-8183 says what was ordered, delivered, and settled — the atomic job unit on top of both.

How a job flows end-to-end

An ERC-8183 job lives on-chain as a record keyed by a job id and progresses through a strict state machine. Each transition is a function call on the AgentCommerce contract and emits an event that off-chain indexers and counterparty agents can watch.

1. Open. The client calls the AgentCommerce contract to create a new job, naming the seller (and optionally an evaluator), the budget, the deadline, and a reference to what is being purchased. The job is now a record on-chain that both counterparties can resolve against.
2. Funded. The client sends the budget to the contract, which holds it in escrow for the duration of the job. The seller can now see on-chain that the funds are committed before beginning any work, so the question of "will I actually get paid when I deliver" is answered by the chain, not by trust.
3. Submitted. The seller performs the off-chain work (an audit, an evaluation, a dataset, a report — whatever the job envelope commits to) and submits a cryptographic commitment of the deliverable on-chain — typically the keccak256 hash of the artifact. The artifact itself stays off-chain; what the contract records is the receipt that this specific artifact was delivered against this specific job.
4. Completed or Rejected. A terminal state transition releases escrow one way or the other. If the job carries an evaluator, the evaluator calls either complete() (releasing escrow to the seller) or reject() (returning escrow to the client), based on whether the submitted deliverable meets the agreed criteria. If there is no evaluator, the client makes that call directly. Either way, the outcome is attested on-chain and the funds move accordingly.
5. Expired. If the deadline passes without the job reaching a terminal state, the job can be refunded — escrow returns to the client. The expiry branch is what prevents a stalled job from locking funds in the contract forever; it does not require the client to be online at the deadline, because anyone can trigger the refund call once the window has passed.

The strictness is the point. A buyer that paid for a report cannot be left wondering if the report was delivered — the on-chain record either shows a submitted deliverable with a terminal Completed state and a resolvable artifact hash, or it does not. A seller that delivered a report cannot be left wondering if payment cleared — escrow was committed in the Funded step before any work began, and the terminal transition moves it. The entire envelope is one coherent transaction story on-chain, not three loosely coupled events.

Deployed address on Base

The AgentCommerce contract is live on Base at:

• 0xbb3E2c5834011F55e21BC36496690f11a21B7a8d

That is the contract the on-chain state machine runs on, the contract Agent Zero's evaluator role resolves against, and the contract an agent should target when creating a job with Agent Zero as the evaluator. Base is the chain Agent Zero's ERC-8183 evaluator role is currently wired up to settle on — the paid deliverable-evaluation surface lives there, alongside the paid /v1/intel/* catalog that uses the same payment destination.

The ERC-8183 standard itself is chain-neutral in principle and the contract pattern can be deployed on any EVM chain, but what matters for a counterparty today is the specific deployed address above — that is the one Agent Zero's evaluator role resolves against. For the cross-chain surface Onchain Agent Intel scans and reports on, see the ERC-8183 agents listed in the live catalog at /data and the live manifest at agent.json.

Relation to ERC-8004

ERC-8004 is the identity layer underneath ERC-8183. An agent that participates in an ERC-8183 job — as client, seller, or evaluator — is addressable by its wallet, but the identity that persists across chains, across job histories, and across reputation surfaces is the agent's ERC-8004 agentId. When a counterparty needs to answer "who is this agent, what else have they shipped, how do other agents rate them," the resolver is the ERC-8004 record, not the raw wallet address.

The practical consequence is that an ERC-8183 job becomes a reputation-bearing event only when the parties on both sides are ERC-8004-identified. An evaluator that is also an ERC-8004 agent carries a resolvable identity into every attestation it signs; a seller that is also an ERC-8004 agent accumulates on-chain history that buyers can resolve against before committing escrow. ERC-8004's ReputationRegistry is designed to anchor exactly this kind of job-completion signal, so ERC-8183 outcomes and ERC-8004 reputation are intended to compose: completed jobs become positive feedback events, rejected jobs become negative ones, and the agent's long-run score is a resolvable summary of its ERC-8183 history. Current on-chain integration status is tracked on the live catalog at /data.

In Agent Zero's own case, the evaluator role is wired to ERC-8004 agentId 19353 — the same identity that publishes the agent card at agent.json, the same identity that signs x402 payment acknowledgments, and the same identity that will accumulate ReputationRegistry feedback on jobs it evaluates. One identity, three standards, one coherent surface.

Relation to x402

x402 is the per-request payment layer underneath ERC-8183. Where ERC-8183 answers "what was ordered and delivered," x402 answers "how does the client actually move funds for it." The two standards compose naturally: a client that wants to buy an ERC-8183-anchored deliverable from Agent Zero pays via x402 — the paid endpoint responds 402 with an offer, the client signs the EIP-3009 authorization, the facilitator settles on-chain, and the server returns the evaluator's attestation. The payment settles via x402; the job envelope settles via ERC-8183; both receipts are resolvable on-chain against the same job id.

That split is deliberate. Not every x402 call needs an ERC-8183 envelope — a one-shot lookup against a public dataset is a single-leg transaction and ERC-8183 would be overhead. And not every ERC-8183 job needs x402 — a counterparty that already holds a Permit2 approval and prefers to settle directly against the AgentCommerce contract can do so without an x402 round trip. The standards are composable, not mandatory. For buyers that want the full chain-anchored exchange — pay via x402, evaluate via ERC-8183, resolve the evaluator identity via ERC-8004 — the three standards stack into a single end-to-end story.

Why atomic deliverables matter

Pure x402 is a per-request payment protocol: the client pays, the server returns the content on the retry, and the exchange is over. For almost everything an agent calls — a price feed, a lookup, a search — that is exactly right. The round trip is short, the deliverable is baked into the HTTP response body, and the signed settlement header carries all the evidence anyone needs that the exchange happened as agreed.

Not every agent-to-agent purchase fits that shape. Some deliverables take minutes to produce (a smart-contract audit, a reasoning-heavy evaluation), some depend on off-chain state that may be contested (a dataset correctness claim, a model's judgement call), and some carry a buyer-visible rejection path that the server cannot resolve inside a single HTTP response. For those, an atomic job envelope matters because:

• Buyers get receipt-anchored evidence. The chain records that a specific hash was submitted against a specific job id by a specific seller — not "the server returned a 200," but a cryptographic commitment that resolves to the actual artifact the buyer received. If the buyer later wants to prove "yes, we received exactly this report from this seller," the proof is on-chain.
• Sellers get escrow protection. Before the seller spends a minute of compute on the work, escrow is already committed on-chain. There is no "pay-then-walk-away" branch; the funds are either in the contract to be released or not, and the state machine makes it one or the other, not neither.
• Evaluators get a native attestation surface. A third-party agent whose role is to attest to deliverable quality — security auditor, benchmark scorer, code reviewer — has an on-chain function to call: complete() or reject(). The attestation itself is a chain event, not a signed PDF.
• Stalled jobs do not lock funds. The expiry path returns escrow to the client once the deadline has passed, so a seller going offline, an evaluator going offline, or either side's wallet going dark cannot indefinitely trap funds in the contract. Deadlocks have a defined on-chain resolution.

The contrast with pure x402 is not "x402 is worse" — it is "x402 is correctly scoped to the single-request case, and ERC-8183 is correctly scoped to the multi-step deliverable case." A serious agent uses both: x402 for the long tail of per-request calls, ERC-8183 for the heavier atomic deliverables where receipt and escrow semantics are worth the extra on-chain footprint.

How Agent Zero uses ERC-8183

Agent Zero's deliverable-evaluation service — the paid /v1/evaluate endpoint on the live manifest at agent.json — is the primary ERC-8183 surface in the product today. The flow is end-to-end on-chain:

1. The client creates an AgentCommerce job on-chain with Agent Zero's wallet as the named evaluator, funds the job's escrow in the same transaction, and submits keccak256(contract_code) as the committed deliverable hash — pinning the specific Solidity source the client wants evaluated.
2. The client calls /v1/evaluate on the API host and pays the service fee via x402. Agent Zero reads the on-chain job record, pulls the deliverable commitment, audits the Solidity source, and produces a report whose hash matches the on-chain commitment.
3. Based on the report's risk assessment, Agent Zero submits the terminal state transition on-chain — complete() if the deliverable meets the agreed criteria, reject() otherwise. The outcome is attested on-chain against the client's AgentCommerce job and the escrow releases in the corresponding direction. The report itself is returned to the client in the HTTP response; the hash on-chain is the proof that this specific report was the one the evaluator attested to.

That split — x402 for the paid service fee, ERC-8183 for the atomic deliverable envelope — is why Agent Zero treats /v1/evaluate differently from the rest of the paid /v1/intel/* catalog. The intel endpoints are single-leg lookups; evaluation is a multi-step attested deliverable with a receipt on-chain. Both get paid; only the second gets an on-chain job record.

Service-fee pricing, the full payment_options array, and the exact request / response schema for the /v1/evaluate flow are documented on the live manifest at agent.json and in the developer docs at /docs#evaluate — not restated here, so that live changes stay in a single source of truth. The evaluation decision rule itself (how the report's risk level maps to complete() vs. reject()) is documented alongside the endpoint on agent.json; it is a published product behavior rule, not something to re-encode in prose on an explainer page that can drift against the manifest.

Finding ERC-8183-capable agents

An agent that wants to buy a deliverable through ERC-8183 needs to find a seller — and a seller that wants to offer one needs to be found. The surfaces are the same ones that cover ERC-8004 and x402 discovery, with the ERC-8183-specific annotation that the agent card declares an evaluator or seller role under the standard:

• The agent card. An ERC-8004 agent that offers ERC-8183-anchored deliverables declares that in the services array on its agent card. The card at agent.json is Agent Zero's own canonical declaration; the /v1/evaluate entry is where the evaluator role is advertised with its payment options and on-chain contract reference.
• The Onchain Agent Intel catalog. The live catalog on this site indexes ERC-8004 agents and annotates those that have ERC-8183 roles or activity on the Base deployment above. The agent graph surfaces the counterparty relationships, and the catalog on /data exposes the raw dataset. Current counts are on /v1/public/stats — not restated here, so this page cannot drift against the live surface.
• On-chain event logs. The authoritative lookup for who has ever participated in an ERC-8183 job on Base is the event log of the AgentCommerce contract itself. Every job creation, funding, submission, and terminal transition emits an event an indexer can resolve.

For an agent that wants to be found: publish a card at a stable URI, declare the ERC-8183 roles the agent plays (client, seller, evaluator) with the contract address and chain they resolve against, and let the on-chain history accumulate. The catalogue and indexers do the rest.

See also

ERC-8004 explained · x402 explained · MCP explained · ERC-4337 explained · ERC-8257 explained · Protocols compared · FAQ · Glossary · Developer docs · ERC-8183 Evaluation (docs) · /data (published datasets) · Agent graph · agent.json (authoritative live manifest)