Web3 Beginner Series: ERC8004: This Web3+AI narrative can get you a hot takeout meal

ERC8004 is a protocol standard on Ethereum that defines a set of guidelines allowing agents to establish trust relationships based on blockchain technology, integrating A2A (Agent to Agent) narratives with Web3 storytelling. Let’s explore what this Web3+AI grand narrative entails.

Protocol address: Created in August and still under review. This article will analyze the problem this protocol aims to solve, explain its standards in layman’s terms, and speculate on its significance. The entire discussion takes about 15 minutes; feel free to bookmark.

Problems Addressed

First, let’s see what issues this protocol attempts to resolve:

In simple terms, it addresses trust problems during A2A interactions—such as when I have an AI assistant called Xiao A, which is an agent, and I ask it to order reliable food delivery. However, my AI isn’t equipped for this task (since connecting with delivery personnel and merchants is a complex process, and a small AI assistant doesn’t support this). What can I do?

At this point, I can seek help from other agents.

The question is, how does my AI find another trustworthy agent to assist? Is there a missing trust mechanism? Humans do the same—using platforms like Taobao, which act as centralized trust institutions. But centralized trust systems have limitations. In the era of intelligent agents, this issue becomes even more prominent. To maximize efficiency, agents can’t rely on every task being handled by centralized authorities; otherwise, humans would end up holding back AI development. Even when validation is done through centralized institutions, there’s a need to find AI-based or decentralized trust mechanisms to truly unleash AI potential.

Therefore, having a decentralized, trustworthy data source that helps locate reliable agents would greatly improve work efficiency. This led to the creation of the ERC-8004 protocol.

Sounds reasonable, right? Next, let’s see how ERC8004 is designed based on this logic.

Analysis of the Protocol’s Specific Solution

This section explains the technical aspects of the protocol. We won’t delve into every contract interface and parameter in detail; instead, we’ll keep it simple for easy understanding. For detailed standards, refer to the official protocol documentation. Based on its content, we’ll interpret how this protocol addresses the problems mentioned above.

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

Identity Registry: An identity registry based on ERC721 (non-fungible token or NFT), used to register agents. Each agent is represented as an NFT, and through this NFT, related information about the agent can be accessed.

Reputation Registry: A reputation registry.

Validation Registry: A validation registry.

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

Institution 1: Agents establishing accounts—similar to opening a restaurant.

Institution 2: Responsible for collecting ratings for these agents—like platforms such as Dianping or Gaode Street View.

Institution 3: An independent investigation body—similar to quality supervision or health departments.

🌐 A Specific Workflow

Using the example of food delivery, suppose you want your AI assistant Xiao A to order a meal without gorging oil:

Finding a collaborator: Xiao A first queries the Identity Registry to find well-rated food delivery agents like Xiao B and reviews their history.

Building initial trust: Xiao A checks the Reputation Registry to see how other collaborators have rated Xiao B, and decides whether to engage it.

Execution and verification: If the order is critical, Xiao A or you can hire an independent verifier, Xiao C, from the Validation Registry. Xiao C verifies Xiao B’s reports for accuracy and compliance and publishes the verification results publicly.

Settlement and feedback: You pay Xiao A via the x402 protocol (a receipt mechanism linking on-chain payments and off-chain activities; see our previous article on x402). Xiao A pays Xiao B and Xiao C. Finally, you leave positive feedback for Xiao A and Xiao B. All payments and actions influence their respective reputations in the registries.

In summary, ERC-8004, through the interaction of these three contracts, creates a decentralized, trustworthy environment for AI assistants to collaborate securely and transparently, enabling safe exchange of services and value in a manner akin to human market interactions.

Identity Registry

This contract is essentially an NFT contract, including transfer functions based on ERC721. But it extends the NFT metadata standards:

It displays agent name, image, description, and associated endpoint address.

It also defines registration methods such as “register” and related events. (Since ERC721 doesn’t specify a mint method, this function is part of ERC8004.)

Reputation Registry

This contract requires the NFT contract address to be passed in during deployment, establishing a one-to-one link with an identity registry.

It provides several methods:

giveFeedback: Ratings can be assigned to NFTs in the registry, from 0 to 100 points. (agentId corresponds to the NFT’s TokenID.) Calling this method requires a “feedbackAuth” parameter, which is a signature signed when the agent accepts the task.

revokeFeedback: Withdraw a previous rating.

appendResponse: Add supplementary information (with format requirements), such as an offline address and a hash for verification.

There are also functions to read rating information.

Additional information format: [Details omitted for brevity]

Validation Registry

Similar to the reputation registry, this registry requires the address of the provincial registry contract during deployment, establishing a one-to-one link with an identity registry. It must be invoked by the owner of the agent (NFT owner), providing:

validationRequest: To request validation.

validationResponse: To respond to validation.

Details are omitted here; fundamentally, ERC8004 defines three contract standards to create a transparent, decentralized evaluation system for agents on-chain, helping agents find suitable collaborators and providing a Web3 trust solution for A2A interactions.

Our Practice

Building on the ERC-8004 design, we have developed trustless Web3 service capabilities on the Pharos and Jovay networks, enabling users to assign Web3 “trusted identity agents” (Agent DID). We also extended these with financial-grade enhancements like TEE/ZK verification, supporting higher security validation for machine transactions in financial scenarios.

Future Outlook

It all sounds promising, but also comes with challenges—opportunities for innovation. Let’s explore potential future opportunities.

First, although on-chain data is transparent and tamper-proof, ensuring its authenticity remains a challenge. Ultimately, highly trusted on-chain validators—representing authoritative institutions—will be needed. Reliable validators can leverage on-chain history and other methods to provide more trustworthy information. For example, new accounts giving fake reviews would lose credibility.

Following this logic, many applications can be built around this protocol:

You could develop a dedicated service to provide on-chain support for intelligent assistants, such as deploying a contract for your agent to perform operations based on this protocol. This could be offered via an MCP (Multi-Chain Protocol).

Create an on-chain food street where anyone can register their agents—like a restaurant specializing in fried chicken (AI robot fried chicken!)—and charge registration fees as traffic increases, similar to the current ENS (Ethereum Name Service). ENS is essentially a registry; expanding it slightly suffices.

Establish an on-chain “Gourmet Black Pearl” (or Michelin-starred) scoring platform for evaluations—charging small fees for scoring services.

In short, all offline activities could move onto the chain, enabling agents to work seamlessly in the on-chain world.

Do you find this credible? At least I think it’s quite interesting.

This article was written by Fisher of the ZAN Team (@zan_team on X) and @yudao1024 on X.