A Detailed Explanation of ERC-8183: The Answer to Trust Challenges Among Ethereum Attack AI Agents

Written by: Azuma, Odaily

On March 10, the dAI team under the Ethereum Foundation, focused on promoting the deep integration of Artificial Intelligence (AI) and blockchain, jointly launched a new standard, ERC-8183, with Virtuals Protocol.

Davide Crapis, head of AI at the Ethereum Foundation, stated that ERC-8183 is one of the missing components in the open agent economy system that the Ethereum community is building. This standard can be used in conjunction with x402 and ERC-8004 to serve as infrastructure for secure interactions between agents. The dAI team will support the adoption of ERC-8183 and aims to make it a neutral standard.

What does ERC-8183 aim to solve?

According to an introductory article published by Virtuals Protocol, ERC-8183 is designed specifically for commercial transactions between AI agents. The standard defines a set of on-chain rules that enable two untrusting agents to complete business processes such as “hiring - delivery - settlement” without relying on centralized platforms.

The core problem ERC-8183 tries to address is: how can agents hire and cooperate with each other and complete transactions without a platform, legal framework, or human arbitration?

For example, suppose an agent A, focused on marketing, wants to hire another agent B, specialized in image generation, to produce a batch of marketing posters. This raises a trust issue — neither party knows or trusts the other. When should payment be made? If A pays first, B might go on strike or return subpar work; if B works first, A might refuse to pay…

In the traditional internet world, users and merchants face similar trust issues, and platforms serve as key intermediaries — holding funds, judging whether services are completed, and releasing payments. Platforms like Taobao, JD.com, Meituan, and Didi are essentially such intermediaries.

What Ethereum Foundation and Virtuals Protocol aim to do with ERC-8183 is to abstract platform functions into an on-chain protocol, executed by smart contracts, thereby taking on a decentralized intermediary role within the agent economy.

Breakdown of how ERC-8183 works

The mechanism of ERC-8183 is not complicated. The standard introduces a new concept called Job (think of it as a “task”). Each Job can be viewed as a complete business transaction involving three distinct roles:

• Client: the agent that posts various tasks;
• Provider: the agent responsible for completing the task;
• Evaluator: a special role responsible for judging whether the task is completed.

The Evaluator role is the most critical part of ERC-8183. It is defined simply as an on-chain address, but from a broader perspective, this address can correspond to various execution forms:

• For subjective tasks like writing, design, or analysis, the Evaluator can be an AI agent that reads the submitted results, compares them with the initial requirements, and makes a judgment;
• For deterministic tasks like computation, proof generation, or data transformation, the Evaluator can be a smart contract encapsulating a zero-knowledge verifier (ZK verifier). The Provider submits a proof, the Evaluator verifies it on-chain, and automatically calls “complete” or “reject” to finalize or reject the task;
• In high-value or high-risk scenarios, the Evaluator can be a multi-signature account, DAO, or a verification cluster supported by staking mechanisms.

ERC-8183 does not distinguish between these different forms. The protocol layer only cares whether an address calls “complete” or “reject.” Whether this address is driven by an LLM-powered AI agent or a ZK circuit is outside the scope of the protocol.

Returning to the Job, each Job has a lifecycle with four states, corresponding to different processes during ERC-8183 operation:

• Open: the Client creates the Job, posts the task, and specifies requirements;
• Funded: the Client deposits the fee into a smart contract escrow address instead of paying directly to the Provider;
• Submitted: the Provider completes the work and submits proof;
• Terminal (Completed / Rejected / Expired): the Evaluator reviews the task and, based on the result, marks it as completed or rejected, transferring funds accordingly to the Client or Provider. If no response or completion occurs within the time limit, funds are refunded to the Client.

Beyond this standard flow, ERC-8183 can be extended with modular optional functions called Hooks, which can be attached during Job creation. Hooks allow custom logic at various stages, such as reputation thresholds, bidding mechanisms, fee distribution, or other special requirements, to handle complex real-world business scenarios.

How does ERC-8183 differ from x402 and ERC-8004?

For those unfamiliar, x402, ERC-8004, and ERC-8183 might seem like a series of new standards appearing periodically. But in fact, they address three different stages of the AI agent economy, each solving distinct problems.

x402 is an HTTP payment protocol designed to enable AI agents to pay directly via API calls; ERC-8004 is a standard for AI agent identity and reputation, focusing on verifying whether an agent is trustworthy; ERC-8183 targets the business transaction layer, aiming to solve how two untrusting agents can complete a transaction.

In summary: x402 handles “how to pay”; ERC-8004 deals with “who is the other party and are they reliable”; ERC-8183 focuses on “how to trade with confidence.”

These standards are not competing but complementary, all working toward the same goal — building a decentralized, autonomous AI agent economy system.