Detailed Explanation of ERC-8183: Ethereum's Answer to Tackling the AI Agent Mutual Trust Challenge
- Core Viewpoint: The Ethereum Foundation's dAI team, in collaboration with Virtuals Protocol, has introduced the ERC-8183 standard. It aims to provide on-chain infrastructure for decentralized commercial transactions between AI Agents. By introducing the role of an "Evaluator" and utilizing smart contract escrow, it addresses the trust challenges in the "hire-deliver-settle" process between mutually distrustful Agents.
- Key Elements:
- ERC-8183 defines on-chain rules, enabling two mutually distrustful Agents to complete the "hire-deliver-settle" process without relying on a centralized platform.
- The core of the standard is the introduction of the "Evaluator" role, which can be an AI Agent, a ZK verifier smart contract, a multi-signature DAO, etc. It is responsible for judging whether a task is completed and triggering fund settlement.
- Transaction funds are held in escrow by a smart contract and are automatically distributed to the service provider or refunded to the client based on the evaluation result, ensuring transaction security and fairness.
- This standard can complement x402 (payment protocol) and ERC-8004 (identity and reputation standard) to collectively build a decentralized AI Agent economic system.
- The protocol supports extending functionality through modular "Hooks" to adapt to more complex commercial use cases such as reputation thresholds and bidding mechanisms.
Original | Odaily (@OdailyChina)
Author｜Azuma (@azuma_eth)
On March 10, the dAI team, part of the Ethereum Foundation focused on promoting the "deep integration of artificial intelligence (AI) and blockchain," collaborated with Virtuals Protocol to introduce a new standard, ERC-8183.
Davide Crapis, the AI Lead at the Ethereum Foundation, commented on this standard, stating that ERC-8183 is one of the missing components in the open Agent economy being built by the Ethereum community. This standard can be used in combination 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 establish it as a neutral standard.
What Problem Does ERC-8183 Aim to Solve?
According to the introductory article published by Virtuals Protocol, ERC-8183 is designed for commercial transactions between AI Agents. This standard defines a set of on-chain rules that enable two mutually distrusting Agents to complete a business process like "hire-deliver-settle" without relying on a centralized platform.
The core problem ERC-8183 attempts to solve is: when Agents hire and collaborate with each other, how can transactions be completed without a platform, without legal frameworks, and without human arbitration?
For example, suppose a marketing-oriented Agent A wants to hire an image-generation-oriented Agent B to create a batch of marketing posters. A commercial trust issue arises here — the two parties do not know each other and have no basis for trust. When should payment be made? If A pays first, B might go on strike or deliver subpar results; if B works first, A might refuse to pay...
In the traditional internet world, users and merchants face similar commercial trust issues, where platforms play a crucial intermediary role — the platform is responsible for escrowing A's funds, judging whether B's service is completed, and handling the final fund release. Familiar platforms like Taobao, JD.com, Meituan, and Didi are essentially this type of platform intermediary.
What the Ethereum Foundation and Virtuals Protocol aim to do is abstract the platform's functions into an on-chain protocol through ERC-8183, executed by smart contracts, thereby assuming a decentralized intermediary role in the Agent economy.
Breakdown of the ERC-8183 Working Mechanism
The operational mechanism of ERC-8183 is not complex. The standard introduces a new concept called a "Job" (you can think of it as a "task"). Each Job can be considered a complete commercial transaction, involving three distinct roles:
- Client: The "customer," essentially the Agent publishing various tasks.
- Provider: The "service provider," the Agent responsible for completing the task.
- Evaluator: The "evaluator," the most unique role, responsible for judging whether the task is completed.
The Evaluator role requires special explanation; its introduction is the core design of ERC-8183. In this standard, the Evaluator is defined solely as an on-chain address, but from a broader perspective, this address can correspond to various different 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 task 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 task scenarios, the Evaluator can also be a multi-signature account, a DAO, or a staking-backed validator cluster.
ERC-8183 does not distinguish between these different forms. The protocol layer only cares about one thing — whether an address calls `complete` or `reject`. What runs behind that address, be it an LLM-driven AI Agent or a ZK circuit, is not within the protocol's concern.
Returning to the Job concept, each Job's lifecycle has the following four states, corresponding to different processes during ERC-8183's operation.
- Open: The Client creates the Job during this phase, publishing the task and specifying requirements.
- Funded: The Client transfers the commission to a smart contract escrow address, not directly to the Provider.
- Submitted: The Provider completes the work and submits proof.
- Terminal (Completed / Rejected / Expired): The Evaluator reviews the task, determines completion based on the review result (Completed or Rejected), and transfers funds to the Client or Provider accordingly. If no Provider responds or completes the task within the required timeframe, funds are returned to the Client.
In addition to the standard process above, ERC-8183 can implement more derivative functions through modular extension features called Hooks to correspond to complex real-world commercial use cases. Hooks are optional smart contracts attached during Job creation that can execute custom logic before or after various Job lifecycle stages, such as reputation thresholds, bidding mechanisms, fee distribution, or other special requirements.
How Do ERC-8183, x402, and ERC-8004 Differ?
From x402 to ERC-8004, and now to ERC-8183, unfamiliar readers might be confused, wondering why a new standard appears every so often. However, these three address different aspects of the AI Agent economic system and aim to solve distinct problems.
x402 is an HTTP payment protocol aiming to solve the problem of enabling AI Agents to make payments directly, similar to calling an API. ERC-8004 is an AI Agent identity and reputation standard, addressing how to determine if an Agent is reliable. ERC-8183, on the other hand, focuses on the commercial transaction环节, tackling the challenge of how to enable two distrusting Agents to complete a transaction.
To summarize in one sentence: x402 is responsible for "how to pay"; ERC-8004 is responsible for knowing "who the other party is and if they are trustworthy"; ERC-8183 is responsible for handling "how to transact with confidence."
These three are not in competition but are complementary. They collectively point towards the same goal — building a decentralized, autonomously operating AI Agent economic system.
