Detailed Explanation of ERC-8183: Ethereum's Solution to the Challenge of Trust Between AI Agents

Written by: Azuma, Odaily

On March 10, the dAI team, a division of the Ethereum Foundation that focuses on promoting the deep integration of artificial intelligence (AI) and blockchain, and Virtuals Protocol jointly launched a new standard, ERC-8183.

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 play an infrastructure role in secure interactions between agents. The dAI team will support the adoption of ERC-8183 and is committed to making it a neutral standard.

What is ERC-8183 trying to solve?

According to the introductory article published by Virtuals Protocol, ERC-8183 is designed specifically for commercial transactions between AI Agents. This standard defines a set of on-chain rules that enable two untrusted Agents to complete a business process such as "hiring-delivery-settlement" without relying on a centralized platform.

The core problem that ERC-8183 attempts to solve is how to complete a transaction without a platform, without laws, and without human arbitration when agents hire and cooperate with each other.

For example, suppose Agent A, who focuses on marketing, wants to hire Agent B, who focuses on image generation, to create a batch of marketing posters for them. Herein lies a business trust issue—the two parties don't know each other and have no basis for trust. When should payment be made? If A pays first, B might go on strike or return unsatisfactory work; if B starts work first, A might refuse to pay…

In the traditional internet world, users and merchants also face similar business trust issues, with platforms playing a crucial intermediary role. Platforms are responsible for holding A's funds, assessing the completion of B's ​​services, and ultimately disbursing the loan. Familiar platforms like Taobao, JD.com, Meituan, and Didi are essentially these platform-based intermediaries.

What the Ethereum Foundation and Virtuals Protocol want to do is to abstract the platform's functions into on-chain protocols through ERC-8183, so that they can be executed by smart contracts, thereby assuming a decentralized intermediary role in the Agent economy.

ERC-8183 Working Solution Disassembly

The ERC-8183 standard is not complex in its operation. It introduces a new concept called a Job (which you can think of as a "task"). Each Job can be viewed as a complete business transaction, which includes three different roles:

• Client: "Client" simply means the agent that publishes various tasks;
• Provider: A "service provider" is the agent responsible for completing the task.
• Evaluator: The most special role, responsible for judging whether a task has been completed.

Here, it's important to explain the Evaluator, as its introduction is the core design of ERC-8183. In this standard, the Evaluator is simply defined as an on-chain address, but from a broader perspective, this address can correspond to various different execution models.

• For subjective tasks such as writing, designing, or analyzing, the Evaluator can be an AI Agent that reads the submitted results, compares them with the original task requirements, and then makes a judgment.
• For deterministic tasks such as computation, proof generation, or data transformation, the Evaluator can be a smart contract that encapsulates a zero-knowledge verifier (ZK verifier). The Provider submits a proof, the Evaluator verifies it on-chain, and automatically calls "complete" or "reject" to complete 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 verification cluster supported by a staking mechanism.

ERC-8183 does not distinguish between these different forms. The protocol layer only cares about one thing—whether a certain address calls "complete" or "reject". Whether the address is running an LLM-driven AI agent or a ZK circuit is not within the scope of the protocol's concern.

Returning to the topic of Job, each Job has four lifecycle states, which correspond to the different processes during the operation of ERC-8183.

• Open: During this cycle, the Client will create the Job, publish the task, and specify the requirements;
• Funded: The client will transfer the commission to a smart contract escrow address instead of giving it directly to the provider;
• Submitted: The Provider completes the work and submits proof.
• Terminal (Completed / Rejected / Expired): The Evaluator is responsible for reviewing the task and determining whether the task is completed (Completed or Rejected) based on the review results, and transferring the funds to the Client or Provider respectively; if the Provider does not respond or complete the task within the time requirement, the funds will be refunded to the Client.

In addition to the standard procedures mentioned above, ERC-8183 can also implement more derivative functions through modular extension functions (Hooks) to address complex real-world business use cases. Hooks are optional smart contracts attached when a Job is created, which can execute custom logic before and after various stages of the Job's lifecycle, such as reputation thresholds, bidding mechanisms, fee allocation, or other special requirements.

What are the differences between ERC-8183, x402, and ERC-8004?

From x402 to ERC-8004, and now to ERC-8183, less familiar readers might be confused, wondering why a new one is developed every now and then. However, these three technologies occupy three different stages of the AI ​​Agent economic system, and each aims to solve different problems.

x402 is an HTTP payment protocol that aims to enable AI agents to make payments directly, just like calling an API; ERC-8004 is an AI agent identity and reputation standard that addresses how to determine whether an agent is reliable; ERC-8183 is geared towards commercial transactions and aims to solve the problem of how to enable two untrusted agents to complete a transaction.

In short, x402 is responsible for solving "how to pay"; ERC-8004 is responsible for knowing "who the other party is and whether they are reliable"; and ERC-8183 is responsible for handling "how to conduct the transaction with peace of mind".

The three are not in competition, but rather complementary, and they all point to the same goal—to build a decentralized, autonomous AI Agent economic system.