Web3 Beginner Series: ERC8004: This Web3 + AI Narrative Could Get You a Hot Meal Delivered to Your Door

ERC8004 is a protocol specification on Ethereum that defines a set of standards enabling agents to establish trust relationships on the blockchain, integrating the A2A (Agent-to-Agent) narrative with Web3. In this article, let's take a look at the logic behind this grand Web3 + AI narrative.

The protocol is available at https://eips.ethereum.org/EIPS/eip-8004, created in August this year and currently under review. This article will explain what problem this protocol aims to solve, break down its standards in plain language, and finally explore some of the potential implications of this protocol. The full read takes about 15 minutes—feel free to bookmark it!

The Problem the Protocol Solves

First, let's take a look at what problem this protocol is trying to solve:

In simple terms, it addresses the trust issue in A2A (Agent-to-Agent) interactions. For example, I have an AI assistant named Xiao A—it's an agent—and I ask it to order me a reliable meal delivery. However, my agent isn't good at this task (after all, interfacing with delivery riders and restaurants is a huge undertaking, and a small AI assistant doesn't support that). So what can I do?

That's when I can ask other agents for help.

So here's the question: how can my agent find another reliable agent to help? Isn't there a lack of a trust intermediary? In fact, humans face the same issue—we use platforms like Taobao for transactions, and Taobao acts as a centralized trust intermediary. But centralized trust intermediaries have their limitations, which become even more pronounced in the age of agents. For agents to operate efficiently, they shouldn't have to rely on humans or centralized institutions for every task—otherwise, humans will end up holding AI back. Even if we use centralized institutions for verification, we'd still need those that either work with AI or operate in a decentralized manner to truly unlock AI's potential.

Therefore, if there could be a decentralized, trustworthy data source to help me find reliable agents, work efficiency would improve significantly. This is where the ERC8004 protocol comes in.

Hmm, does this sound reasonable? Next, let's take a look at how ERC8004 is designed based on this logic.

An Analysis of the Protocol's Specific Design

This section provides an analysis of the protocol's specific technical design. However, we won't dive into overly detailed contract interfaces and parameters from the specification itself; instead, we'll aim to make it as understandable as possible for everyone. For the finer details, readers can refer to the official protocol standard documentation. Based on the protocol's content, we'll explain in plain terms how this protocol attempts to solve the problem we outlined above.

Technically speaking, ERC8004 essentially defines interface specifications for three types of contracts:

• Identity Registry: Built on ERC721 (Non-Fungible Tokens, or NFTs), used to register agents—each agent is essentially an NFT, and through this NFT, one can retrieve the agent's relevant information.
• Reputation Registry.
• Validation Registry.

In simple terms, you can think of these three types of contracts as three kinds of institutions operating on the blockchain.

• Institution One: Agents come here to open an account, just like you'd open a restaurant.
• Institution Two: I'm responsible for collecting ratings for these agents, similar to Dianping and Gaode Street View.
• Institution Three: I'm a third-party investigation agency in charge of verification—like a quality inspection bureau or health department.

🌐 A Concrete Workflow

Let's use the food delivery example: suppose you want your AI assistant "Xiao A" to order you a meal delivery that doesn't use gutter oil:

1. Finding a collaborator: "Xiao A" first queries the Identity Registry to find a well-rated food delivery agent "Xiao B" and checks its historical reviews.
2. Establishing initial trust: Next, "Xiao A" checks the Reputation Registry to see how other collaborators have rated "Xiao B" and decides whether to hire it.
3. Execution and Validation: If this meal is critically important, "Xiao A" or you can additionally hire an independent validator "Xiao C" from the Validation Registry. "Xiao C" will verify whether "Xiao B"'s report is accurate and meets the requirements, and publicly disclose the verification result.
4. Settlement and Feedback: You pay "Xiao A" via the x402 protocol (a receipt mechanism that connects on-chain payments with off-chain activities—see our previous article on x402 for more details). "Xiao A" then pays "Xiao B" and "Xiao C." Finally, you leave positive reviews for the services provided by "Xiao A" and "Xiao B," and all these payments and actions will either reinforce or affect their respective reputations in the registries.

In summary, ERC-8004 establishes a decentralized and trustworthy collaboration environment for AI assistants through the interplay and coordination of these three contracts, enabling them to freely and securely exchange services and value just as humans do in the marketplace.

Identity Registry

This contract is essentially an NFT contract, including transfer and other functionalities inherent to the ERC721 standard, but it redefines and extends the NFT's metadata file:

You can see that you originally provided the Agent's name, image, description, and corresponding endpoint address.

Additionally, it also specifies the registration method register and related events (the ERC721 standard itself does not define a mint method, so this method is considered part of ERC8004).

Reputation Registry

This contract, when initially deployed, requires the NFT contract to be passed in via the constructor, meaning it is uniquely associated with one Identity Registry.

Defines several methods:

• giveFeedback: Allows scoring an NFT in the Identity Registry on a scale of 0–100. (agentId corresponds to the NFT's TokenID.) Calling this method requires a parameter feedbackAuth, which is a signature signed by the agent when accepting the task.
• revokeFeedback.
• appendResponse: Allows adding supplementary information (with format requirements), such as an off-chain address along with a hash value for verification.
• There are also a series of read methods for retrieving relevant rating information.

The format requirement for supplementary information is:

Validation Registry

Like the Reputation Registry, this registry also requires the contract address of the Identity Registry to be passed in during construction, and it is uniquely associated with one Identity Registry. This contract must be called by the Agent's Owner (the NFT's Owner) and provides the following methods:

• validationRequest: Used to request validation.
• validationResponse: Used to respond to validation.

This article will not delve into the specific details further. In essence, ERC-8004 defines three contract standards, enabling us to establish a transparent, decentralized agent evaluation mechanism on-chain, helping agents better find desired collaboration partners and providing a Web3 trust solution for A2A.

Our Practice

Combining the design of ERC-8004, we have built a trustless service on the Pharos and Jovay networks, which assigns agents with "Trusted DIDs" in the web3 world. Additionally, building upon the original foundation, we have extended financial-grade enhanced TEE/ZK verification capabilities, with future support for higher-security verification enhancements tailored to machine-to-machine transactions in financial scenarios.

Future Outlook

It sounds great, but it is also full of challenges—yet challenges are also opportunities. Let’s take a look at what kinds of opportunities the future might hold.

First, although the data is on-chain—transparent and immutable—ensuring that the on-chain data is genuinely truthful and trustworthy remains a problem. Therefore, there may eventually emerge some highly trusted on-chain validators, which in effect represent authoritative institutions behind the scenes. Reliable validators can provide more credible information through various means, such as historical on-chain data. For example, if you use a new account to post fake negative reviews, your credibility would clearly be insufficient.

Following this logic, there are many things that can be built around this protocol:

• You could build a service specifically to provide on-chain support for intelligent agents. For example, I could help you deploy a contract for your agent, and this contract could perform various operations based on this protocol. I could offer such a service through an MCP.
• You could create an on-chain "food street," where everyone registers their agents with your contract. For example, I open a shop that specializes in fried chicken (AI-powered robot fried chicken, of course!) and register it on this food street. As long as the food street attracts significant traffic, you can charge registration fees—just like ENS (Ethereum Name Service) does today. Haha, in fact, ENS can already be understood as a registry; you'd just need to extend it slightly.
• You could create an on-chain "Black Pearl" (or Michelin-style) restaurant guide, providing ratings and reviews for others—of course, you could charge a small fee for it.

In short, everything that was previously done offline can now be moved on-chain—agents can simply work in the on-chain world from now on.

What do you all think—does it sound credible? At the very least, the author finds it quite interesting.