Onchain identity for AI agents refers to the use of queryable blockchain records to establish digital identifiers that allow artificial intelligence agents to be recognized, linked, and managed across applications. As AI agents evolve from simple conversational assistants into autonomous systems capable of calling tools, accessing data, executing tasks, and participating in economic activities, agent identity is becoming essential infrastructure for open collaboration networks. ERC-8004 is an Ethereum standard proposed to address this need, seeking to establish common interfaces for agent identity, reputation, and validation information through onchain registries.
In traditional software systems, service identities typically rely on platform accounts, API keys, and internal enterprise permission management. These approaches can meet most needs for agents operating within the same organization or platform. However, when multiple AI agents come from different developers, run on different infrastructure, and need to delegate tasks to one another, discovering services, confirming control relationships, assessing historical performance, and validating execution results become new technical challenges.
ERC-8004, MCP (Model Context Protocol), and A2A (Agent2Agent) address these issues from different perspectives. MCP enables agents to connect to tools and data, A2A enables communication and collaboration between agents, and ERC-8004 provides identity discovery and trust signals across platforms. Understanding their technical boundaries and how they work together helps explain how open AI agent networks can evolve from individual tool calls into composable multi-agent systems.
Key Takeaways
-
The core value of onchain identity for AI agents lies in discoverability, verifiability, and cross-platform collaboration. It helps agents created by different developers and platforms establish queryable identity links without relying entirely on a single centralized service directory.
-
ERC-8004 provides identity and trust infrastructure through the Identity Registry, Reputation Registry, and Validation Registry, supporting agent registration, reputation feedback, and task validation.
-
MCP primarily addresses how agents use tools, connecting databases, search services, file systems, and external APIs through standardized interfaces.
-
A2A primarily addresses how agents collaborate with other agents, supporting capability discovery, task delegation, message exchange, and task status management.
-
ERC-8004, MCP, and A2A are not competing solutions. They can handle identity and trust, tool access, and agent communication, respectively. However, onchain registration alone does not constitute real-world identity verification or guarantee reliable task execution results.
The identity challenge for AI agents is not simply about assigning a name to a program. It requires establishing identity links that other systems can recognize and verify.
On centralized platforms, agents are typically identified through platform accounts, API keys, or service addresses provided by developers. Platforms can manage user permissions, maintain service directories, and restrict violations. This model works well for operations within a single platform. However, when agents need to collaborate across organizations, identity information may not be shareable, historical reviews may be difficult to transfer, and service trustworthiness may depend on a particular platform.
For example, a market analysis agent developed by a company may have accumulated extensive service records on one platform. When it joins another agent network, the new platform may be unable to verify those records directly, requiring the developer to reestablish the agent's identity and reputation.
Onchain identity seeks to reduce this fragmentation. By recording identifiers, control rights, and certain trust signals on a public blockchain, different applications can query the same registration information and build their own service discovery and risk assessment systems on top of it.
However, onchain identity does not require the AI model itself to run on a blockchain. Actual inference, database access, and tool calls can still take place offchain. The blockchain primarily handles shared registration, verifiable records, and trust coordination.
This also means that onchain identity cannot replace traditional identity verification. An address can prove that a particular key has permission to perform certain operations, but it does not necessarily prove that the developer behind the address has legitimate qualifications. High-risk use cases, such as finance and healthcare, still require additional legal identity verification and authorization for business activities.
What Is ERC-8004? How Does It Establish Portable Identity for AI Agents?
ERC-8004, formally named Trustless Agents, is a standard proposed within the Ethereum ecosystem for open agent networks. Its goal is to provide cross-organizational discovery and trust infrastructure for agents without requiring preexisting trust relationships.
ERC-8004's identity registration mechanism builds on ERC-721. After registering an agent, a developer can obtain an agentId and use the corresponding registration information to associate the agent's name, functional description, service endpoints, and supported communication protocols.
This design separates an agent's identity from its specific service address. For example, an agent can change servers or update its A2A interface while retaining its registered identity. Other applications only need to query the relevant registration information to obtain the updated service endpoint.
ERC-8004 also allows registration information to link different types of endpoints, including MCP, A2A, ENS, DID, and wallet addresses, connecting onchain identity to existing Web3 and AI infrastructure.
Its core consists of three registries:
| Registry |
Primary Function |
Application Value |
| Identity Registry |
Registers agent identities and links metadata |
Supports cross-platform identity discovery |
| Reputation Registry |
Provides a standardized interface for feedback records |
Helps assess historical service performance |
| Validation Registry |
Records independent task validation requests and results |
Provides additional trust signals for high-value tasks |
The Reputation Registry does not automatically determine which reviews are authentic or trustworthy. Instead, it provides queryable feedback records. Different applications can design their own scoring, filtering, and risk assessment algorithms.
The Validation Registry allows third-party validators to check specific task results. Validation methods can include re-execution, trusted execution environments (TEE), or zero-knowledge machine learning (zkML).
Notably, ERC-8004 remains in Draft status on Ethereum's EIP page. This does not prevent developers from deploying and experimenting with it, but its specification status should be distinguished from its actual adoption.
MCP (Model Context Protocol) is an open protocol for connecting AI applications to external tools, data, and context resources.
Without a unified interface, developers may need to write separate integration logic for each database, file system, or API. As agents use more tools, this approach can lead to duplicated development work and higher maintenance costs.
MCP reduces the complexity of connecting different AI applications to external capabilities through standardized communication between clients and servers.
In the MCP architecture, servers can provide clients with three main types of capabilities:
-
Tools: Executable functions, such as querying databases, searching for information, or calling business APIs.
-
Resources: Readable context data, such as documents, database records, and file contents.
-
Prompts: Reusable prompt templates for structuring interactions for specific tasks.
For example, a crypto research agent can use MCP to connect to a market data database, onchain data interfaces, and a research repository. When a user requests an analysis, the agent can call the relevant tools, retrieve data, and then generate research results.
MCP focuses on standardizing tool access, not establishing public onchain identity.
MCP can also work with traditional authorization mechanisms to protect restricted services. For HTTP transport, the relevant specifications support OAuth-based authorization flows. MCP should therefore not be understood as lacking identity or access control capabilities entirely.
The distinction from ERC-8004 is that MCP's authorization primarily supports specific tool connections and resource access, while ERC-8004 focuses on shareable agent identities and trust records across platforms.
What Is A2A? How Does It Support Task Collaboration Between AI Agents?
A2A (Agent2Agent) is an open communication protocol for different agent systems. Google initially led its development, and it later became part of the Linux Foundation ecosystem.
Unlike MCP, which primarily connects tools, A2A aims to enable AI agents built by different developers using different frameworks to discover one another's capabilities and exchange messages, delegate tasks, and manage execution status in a standardized way.
One important A2A mechanism is the Agent Card. This is a machine-readable metadata document that describes an agent's name, capabilities, skills, service address, and authentication requirements.
When an agent needs to delegate a task, it can first read the other agent's Agent Card, determine whether it has the required capabilities, and then initiate a request according to the protocol.
A2A also supports task lifecycle management. For example, a complex research task may take considerable time to complete. The initiating agent can query its status, receive progress updates, and retrieve the results after execution finishes.
This differs from ordinary API requests. Traditional APIs are often designed for individual operations, while A2A places greater emphasis on ongoing task interactions between agents.
However, A2A itself also includes mechanisms for capability discovery and authentication. ERC-8004 therefore does not fill a complete absence of identity functionality in A2A. Instead, it adds onchain identity, reputation, and validation information that can be shared across platforms.
A2A handles communication and task collaboration, while ERC-8004 can help callers assess a service provider's historical performance and relevant trust signals before establishing a working relationship.
How Do ERC-8004, MCP, and A2A Differ?
ERC-8004, MCP, and A2A address different issues in agent systems. All three may appear in the same workflow, but not every AI agent needs to use all of them.
| Comparison Dimension |
ERC-8004 |
MCP |
A2A |
| Core Focus |
Onchain identity and trust |
Tool and data connectivity |
Agent communication and collaboration |
| Primary Problem Addressed |
How to discover and assess agents |
How to invoke external capabilities |
How to complete tasks with other agents |
| Core Mechanisms |
Identity, reputation, and validation registries |
Tools, Resources, Prompts |
Agent Card, Messages, Tasks |
| Blockchain Dependency |
Yes |
No |
No |
| Identity-Related Support |
Onchain identity registration and linking |
Identity and authorization mechanisms for specific connections |
Agent Card and communication authentication |
| Reputation Mechanism |
Provides a standardized feedback interface |
Does not provide a general-purpose onchain reputation system |
Does not provide a general-purpose onchain reputation system |
| Typical Applications |
Service discovery, reputation queries, result validation |
Data queries, tool calls, resource access |
Division of work among agents, task delegation, status management |
The three can be understood as three layers of an open agent network.
ERC-8004 provides identities and trust signals that can be queried across platforms, MCP connects agents to the tools needed to execute tasks, and A2A helps multiple agents exchange tasks and results.
This division also means that ERC-8004 does not replace MCP's tool-calling capabilities, MCP does not replace A2A's task collaboration mechanisms, and A2A does not require a blockchain to communicate.
Their value lies in being composable according to business needs, rather than requiring a fixed set of technical dependencies.
How Do ERC-8004, MCP, and A2A Complete a Multi-Agent Workflow?
Suppose an institution wants to use AI agents to automatically generate a research report on a crypto asset. The overall task may involve market data, onchain data, news, and risk analysis, requiring collaboration among multiple agents.
First, the lead research agent needs to find a specialized agent that provides onchain analysis services. It can query the relevant registration information through ERC-8004's Identity Registry to obtain service descriptions and A2A endpoints.
Next, the lead research agent can read historical feedback in the Reputation Registry to assess whether candidate service providers have relevant service experience. For more demanding analysis tasks, it can also consult independent validation records.
After screening candidates, the lead research agent initiates a task with the selected agent through A2A, requesting an analysis of recent onchain fund flows for a particular asset.
After receiving the task, the delegated agent uses MCP to call blockchain data tools, databases, or external APIs, retrieve the necessary information, and perform the analysis.
Once the task is complete, the delegated agent returns the research results through A2A. The lead research agent can then integrate other information and generate the final report.
If the application has integrated ERC-8004's feedback mechanism, it can also record a service quality review after the task ends for future collaborators to reference.
Example of Cross-Protocol AI Agent Collaboration
The key to this scenario is not writing all data to the blockchain, but assigning different functions to the appropriate infrastructure.
Identity and trust signals can be shared through onchain registries, A2A handles communication for complex tasks, and MCP handles data access and tool execution.
This layered design preserves the execution efficiency of traditional internet systems while allowing collaboration across organizations to use public trust infrastructure.
An important challenge in open agent networks is enabling agents to reuse service performance records accumulated across different platforms.
If reputation is managed entirely by a centralized platform, an agent may be unable to retain access to existing review records after leaving that platform. A new platform may also find it difficult to independently check the source of historical data.
ERC-8004's Reputation Registry provides a standardized interface for this issue, allowing client feedback to be linked to the corresponding onchain identity.
However, public records do not automatically make reviews trustworthy. Malicious developers may create large numbers of linked accounts to provide false feedback for agents they control. Competitors may also attempt to manipulate ratings.
Applications therefore still need to filter and weight reputation signals based on review sources, historical behavior, and anomalous patterns.
For more important tasks, reputation alone may not be enough to establish trust. For example, when an agent provides smart contract risk analysis, clients may want not only to know its past reviews, but also to confirm whether its detection methods and analysis results have been independently checked.
The Validation Registry allows relevant systems to record validation requests and results and link them to specific agent identities.
However, validation quality depends on the methods used and the validators themselves. A TEE proves properties of a specific execution environment, while zkML proves that a particular computational process satisfies specified conditions. Neither means that the final business judgment is necessarily correct.
ERC-8004's strength therefore lies in supporting combinations of trust mechanisms, rather than providing a single score that automatically determines the safety of every agent.
Why Does ERC-8004 Use Blockchain Instead of a Centralized Agent Directory?
Centralized agent directories do have value. For internal enterprise systems, a unified management platform usually makes access control, service review, and security maintenance easier.
However, across organizations, different platforms may use different registration standards and review systems. Identity information and reputation data held by one platform may not be directly queryable or reusable by another.
Blockchain provides a shared recordkeeping approach that allows different applications to build services around the same public registration information.
ERC-8004 uses ERC-721 as the foundation for identity registration, linking agent identities to onchain ownership and control relationships. Registration information can also point to offchain metadata, avoiding the need to store all descriptions and service data directly on the blockchain.
This approach offers a degree of composability. For example, third-party developers can build agent search engines, reputation analysis platforms, or task validation services without relying entirely on the original registration platform.
However, blockchain also introduces new costs and complexity, including transaction fees, identity coordination across networks, and privacy issues arising from public records.
In addition, although onchain identities can be queried, associated service endpoints may still fail, and metadata may contain errors or misleading content. A public registry cannot replace ongoing service monitoring.
Blockchain is therefore better suited to cross-organizational sharing and trust coordination, but not necessarily to handling every aspect of agent operation and management.
How Does ERC-8004 Differ From ENS and DID?
ENS (Ethereum Name Service) and DID (Decentralized Identifier) also involve digital identity, making them easy to confuse with ERC-8004.
ENS primarily provides human-readable names and resolution of associated records. For example, an Ethereum address can be linked to an easily recognizable ENS name, reducing the difficulty of using complex addresses.
DID is a category of decentralized identifier specifications that can be combined with different DID methods and verification mechanisms to establish digital identity systems.
ERC-8004 focuses more specifically on the application needs of AI agents. Beyond identifiers, it needs to link service capabilities, communication endpoints, historical feedback, and task validation information.
| Standard |
Core Focus |
Primary Use |
| ENS |
Name and record resolution |
Links readable names to addresses or other information |
| DID |
Decentralized identity identifier framework |
Establishes verifiable digital identity links |
| ERC-8004 |
Agent identity and trust registration |
Discovers agents, queries reputation, and validates tasks |
These mechanisms are not mutually exclusive.
An agent can have an ERC-8004 identity, an ENS name, and a DID identifier simultaneously, with the relevant data linked in its registration information.
The distinction is that ENS and DID do not specifically provide the agent reputation and task validation registries defined by ERC-8004.
What Security and Privacy Challenges Does Onchain Identity Pose for AI Agents?
Onchain identity can make records easier to query, but it does not inherently solve security issues in open networks.
The first risk is identity abuse. Creating an onchain identity does not necessarily require rigorous real-world identity checks, so malicious participants may register large numbers of agents to fabricate service networks or reputation records.
The second risk concerns control over identity. If an agent's control key is stolen, an attacker may modify its registration information or perform unauthorized operations. Developers of high-value agents need stricter key management and separation of permissions.
The third risk is metadata security. ERC-8004 registration information can link external service endpoints, but those endpoints may be attacked, replaced, or shut down. Clients should not trust returned content solely because an address appears in a registry.
The fourth issue is privacy. Onchain feedback and validation records may remain public over the long term. If developers write client identities, sensitive task details, or business data directly onchain, they may create irreversible information exposure.
A more appropriate design is therefore to record necessary identifiers, digests, and trust signals onchain while keeping sensitive business data in offchain systems with suitable access controls.
Finally, the trust model itself has limitations. An agent that performs well on simple data queries may not be able to execute complex financial operations safely. Applications need to choose different levels of validation based on task value, the consequences of errors, and data sensitivity.
Agents involved in asset transfers or trade execution should also have separate wallet permissions, fund limits, and human approval conditions. Onchain identity should not be treated as authorization to move funds.
How Will ERC-8004, MCP, and A2A Affect Web3 and the AI Agent Economy?
The development of ERC-8004, MCP, and A2A reflects the gradual expansion of AI agent infrastructure from tool calls within individual applications to collaboration networks spanning platforms and organizations.
MCP reduces the complexity of connecting agents to external data and tools, A2A provides a common approach to task interactions between agents, and ERC-8004 seeks to reduce complete dependence on a single platform for identity and trust information.
For the Web3 ecosystem, this architecture may enable new applications, including decentralized agent directories, onchain reputation analysis, agent task validation, and payment and settlement systems for machine services.
When combined with payment protocols such as x402, agents can also pay for data, computing, and other digital services after receiving authorization, creating a more complete workflow from service discovery through task execution, payment, and feedback.
However, adopting these standards does not mean that every AI agent needs to issue a token or that every agent activity must run on a blockchain.
Applications that deliver genuine value still need to demonstrate advantages over existing solutions in cost, efficiency, security, and cross-platform interoperability.
Over the long term, the development of open agent networks may extend blockchain's role beyond asset recordkeeping and settlement infrastructure to machine identity and trust coordination.
Summary
AI agents need onchain identity primarily because open agent networks face challenges involving cross-platform identity discovery, reputation portability, and task validation.
Traditional platform accounts and API keys can meet identity and authorization needs within specific systems, but the associated information is often difficult to share across organizations. Through onchain identity, reputation, and validation registries, ERC-8004 establishes composable trust infrastructure for different platforms.
MCP and A2A address agent tool connectivity and cross-system collaboration, respectively. MCP enables agents to access data and execute tool operations, while A2A enables different agents to discover capabilities, delegate tasks, and exchange results.
The three are not substitutes for one another. They can be combined according to practical needs.
As AI agents increasingly participate in data procurement, financial research, enterprise operations, and automated services, identity, trust, communication, and payments may form a more complete technical system. However, onchain identity does not establish real-world trustworthiness, and public reputation does not guarantee service quality. Practical applications still require robust security validation, permission management, and risk controls.
ERC-8004 addresses identity and trust coordination in open networks, MCP connects tools and data, and A2A connects different agents. Together, they provide a foundation for cross-platform AI agent collaboration.
FAQ
Why do AI agents need onchain identity?
Onchain identity provides agents with identifiers that can be queried across platforms and linked to service information, historical feedback, and validation records, reducing reliance on a single centralized directory.
What is ERC-8004?
ERC-8004 is an Ethereum standard proposal for AI agents that supports agent discovery and trust assessment through identity, reputation, and validation registries.
What is the main difference between ERC-8004 and MCP?
ERC-8004 primarily handles cross-platform identity and trust information, while MCP primarily addresses how AI applications connect to external tools, data, and context resources.
What is the difference between MCP and A2A?
MCP focuses on interactions between agents and tools, while A2A focuses on communication, task delegation, and collaboration between different agents.
Why is ERC-8004 needed if A2A already supports Agent Card?
Agent Card can describe agent capabilities and service endpoints, while ERC-8004 additionally provides interfaces for cross-platform sharing of onchain identity, reputation feedback, and task validation.
Does ERC-8004 require AI agents to run on a blockchain?
No. AI model inference and tool execution can continue offchain. The blockchain is primarily used for identity registration and related trust records.
Does having an ERC-8004 identity mean an AI agent is safe and trustworthy?
No. Onchain registration only proves the link between a particular identity and its registration records. Risk assessment still requires service validation, reputation analysis, and security controls.
Can ERC-8004, MCP, and A2A be used with x402?
Yes. ERC-8004 provides identity and trust signals, MCP and A2A handle tool access and task collaboration, and x402 can provide payment capabilities for paid services.
