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

Original | Odaily Planet Daily (@OdailyChina)

Author | Azuma (@azuma_eth)

On March 10th, the Ethereum Foundation’s dedicated team focused on promoting the deep integration of “Artificial Intelligence (AI) and Blockchain,” the dAI team, 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 being built by the Ethereum community. 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, aiming 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 specifically designed for business transactions between AI Agents. The standard defines a set of on-chain rules that enable two untrusting Agents to complete business processes such as “hire-deliver-settle” without relying on centralized platforms.

The core problem ERC-8183 attempts to address is: when Agents hire and cooperate with each other, how can they complete transactions without platforms, legal systems, or manual arbitration?

For example, suppose an Agent A, focused on marketing, wants to hire another Agent B, specialized in image generation, to create 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 also face similar trust issues, with platforms acting as key intermediaries — holding A’s funds, judging whether B’s service is completed, and handling final payments. Well-known platforms like Taobao, JD.com, Meituan, and Didi are essentially such intermediaries.

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

ERC-8183 Workflow Breakdown

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

• Client: The “customer,” simply the Agent that posts various tasks;
• Provider: The “service provider,” the Agent responsible for completing the task;
• Evaluator: The “assessor,” a special role responsible for judging whether the task is completed.

It’s important to explain the Evaluator role. The introduction of this role is the core design of ERC-8183. In this standard, the Evaluator is only defined 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 original requirements, and makes a judgment;
• For deterministic tasks such as 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 finish or reject the task;
• In high-value or high-risk scenarios, the Evaluator can also 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 about one thing — whether an address calls “complete” or “reject.” It does not matter whether this address is driven by an LLM-powered AI Agent or a ZK circuit.

Returning to the Job, each Job’s lifecycle will have the following 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 the Provider directly;
• Submitted: The Provider completes the work and submits proof;
• Terminal (Completed / Rejected / Expired): The Evaluator reviews the task and, based on the result, determines whether it is completed or rejected, then transfers funds accordingly to the Client or Provider. If the Provider does not respond or complete the task within the time limit, funds are refunded to the Client.

Beyond the standard process, ERC-8183 also supports modular extensions called Hooks, which can implement additional functionalities to address complex real-world business scenarios. Hooks are optional smart contracts attached during Job creation, allowing custom logic at various stages, such as reputation thresholds, bidding mechanisms, fee distribution, or other special requirements.

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

From x402 to ERC-8004, and now to ERC-8183, newcomers might be confused about why new standards keep emerging. In fact, these three are positioned at different stages of the AI Agent economic system, each solving different problems.

x402 is an HTTP payment protocol designed to enable AI Agents to pay as easily as calling an API; ERC-8004 is a standard for AI Agent identity and reputation, addressing how to determine if an Agent is trustworthy; ERC-8183 focuses on business transactions, tackling how to enable two untrusting Agents to complete a deal.

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

These standards are not competing but complementary, collectively aiming to build a decentralized, autonomous AI Agent economy system.