ERC-8004 is an AI agent identity and trust standard proposed within the Ethereum ecosystem. Officially named Trustless Agents, it aims to use blockchain to establish mechanisms for cross-platform agent discovery, reputation records, and task validation. x402 is an open payment protocol based on the HTTP 402 status code that enables applications and AI agents to authorize and settle payments when requesting internet resources. The two address trust and payment issues, respectively, in agent collaboration and serve as important infrastructure for an open agent economy.
As AI agents evolve from content generation tools into automated systems that can autonomously call APIs, access databases, conduct research, and manage on-chain transactions, economic relationships between agents are becoming more complex. One agent may need to buy data from another, delegate an analysis task, or pay for computing resources. In this process, communication interfaces alone are not enough. Systems also need to identify service providers, assess their past performance, and ensure that payments remain subject to authorization and risk controls.
Combining ERC-8004 and x402 offers approaches to these needs at different layers. Understanding the two protocols requires distinguishing identity registration from real-world identity verification, reputation records from result validation, and payment authorization from actual settlement. It also requires examining how they work with MCP, A2A, smart contract wallets, and stablecoins to build automated collaboration workflows for AI agents.
Key Takeaways
-
ERC-8004 addresses agent identity discovery and trust. Through identity, reputation, and validation registries, it enables AI agents from different platforms to be identified, evaluated, and validated.
-
x402 addresses internet-native payments. Based on the HTTP 402 Payment Required mechanism, it enables AI agents to automatically pay for APIs, data, computing resources, and other digital services under preset authorizations.
-
The two are not competing protocols. ERC-8004 helps agents decide whom to work with, while x402 provides payment and settlement capabilities.
-
ERC-8004 does not directly handle payments, and x402 does not provide a complete agent identity and reputation system. Together, they can support a business workflow spanning service discovery, trust assessment, automated payments, and feedback on results.
-
The agent economy still faces challenges such as identity spoofing, fabricated reputation, payment authorization, task delivery, and fund security. On-chain records do not mean that all behavior is trustworthy.
What Is ERC-8004, and Why Do AI Agents Need On-Chain Identities?
ERC-8004 is an on-chain identity and trust standard for autonomous agents. Its primary goal is to enable AI agents developed by different organizations and platforms to discover one another without a preexisting trust relationship and obtain trust information they can assess.
Traditional internet services typically establish identity relationships through platform accounts, API keys, or centralized service directories. For example, when a business uses a third-party data API, it can confirm the service's source through the provider's website, contracts, and platform verification. In an open AI agent network, however, agents may be created by different developers and provide services across multiple platforms or blockchain networks.
Without a unified discovery mechanism, agents have difficulty determining which agent a service address belongs to or easily looking up its service history.
ERC-8004 proposes three independent on-chain registries:
| Core Component |
Primary Function |
Problem Addressed |
| Identity Registry |
Establishes a searchable on-chain identifier for an agent and links it to registration information |
How can an agent be discovered and identified? |
| Reputation Registry |
Records service feedback and related reputation signals |
How can an agent's past performance be assessed? |
| Validation Registry |
Records independent validation requests and results |
How can an agent's work be validated? |
The Identity Registry is based on ERC-721. Each registered identity corresponds to an agentId and uses metadata to link the agent's description, service endpoints, and other necessary information.
This allows agents to have identity identifiers that are relatively independent of any single application platform.
However, an on-chain identity is not the same as real-world identity verification. Registering an agent does not automatically prove that its developer is genuine and reliable, nor does it guarantee that its services are secure. ERC-8004 provides composable identity and trust infrastructure. Specific trust decisions still depend on application rules, historical feedback, and independent validation.
As of October 22, 2026, ERC-8004's EIP page still lists its status as Draft. However, related registries and ecosystem implementations have already begun to be deployed and used, so the specification's status should be distinguished from actual adoption.
How Does ERC-8004 Build Trust Through Identity, Reputation, and Validation?
ERC-8004's core design does not use a single score to determine whether an agent is trustworthy. Instead, it allows different trust signals to be publicly recorded and independently combined.
First, the Identity Registry gives agents a searchable on-chain identity. Developers can publish an agent's service capabilities, communication endpoints, and related metadata through its registration information, allowing other applications to discover what services it offers and how to access them.
Second, the Reputation Registry allows clients to submit feedback about an agent's services. Other systems can read this feedback and analyze it according to different business needs. For example, a data analysis agent can accumulate records of task completion rates, response quality, or customer satisfaction.
However, reputation data is not necessarily genuine. Developers may use related accounts to fabricate positive reviews, and malicious participants may post misleading feedback. The Reputation Registry therefore provides a standardized recording interface rather than automatically eliminating reputation manipulation risks.
Finally, the Validation Registry records third-party validation of task results. Different tasks can use different validation methods, such as having other nodes reexecute a task, providing attestation through a trusted execution environment (TEE), or using technologies such as zero-knowledge machine learning (zkML) to validate specific computations.
These methods differ in their applicability. Tasks with reproducible computations are easier to validate technically, while investment advice, creative content, or complex business judgments often still require human assessment or specialized evaluation mechanisms.
ERC-8004 therefore establishes a layered trust model: identity supports discovery, reputation helps with selection, and validation checks specific results. The three complement one another but cannot replace practical risk management.
What Is x402, and Why Do AI Agents Need an HTTP-Native Payment Protocol?
x402 is an open payment protocol built on the HTTP 402 Payment Required status code. Its goal is to add a standardized payment mechanism to internet request workflows.
Traditional internet services typically charge through account registration, credit card subscriptions, or prepaid balances. Users must first establish a payment relationship before they can call APIs, download data, or access paid content.
This model works for human-operated workflows but may not suit AI agents that operate frequently and on demand.
For example, a market research agent may need to call a specialized data API only once. Requiring it to first create an account, purchase a monthly subscription, and complete a complex manual payment process would reduce automation efficiency.
x402 allows service providers to specify payment requirements directly within an HTTP request workflow. After receiving a payment requirement, the client can generate the appropriate payment authorization based on the supported networks, assets, and payment terms, then resubmit the request.
The server provides the protected resource only after the payment requirements have been met and the necessary verification or settlement has been completed.
x402 can therefore support business models such as per-call API access, data purchases, and access to computing services, allowing paid machine-to-machine interactions without relying entirely on traditional subscription systems.
Importantly, x402 is not a new cryptocurrency or a separate blockchain. It is a payment interaction protocol that can operate with different blockchain networks, stablecoins, and settlement infrastructure.
What Is the Difference Between ERC-8004 and x402?
ERC-8004 and x402 often appear together in discussions about AI agents, but they operate at different technical layers.
ERC-8004 focuses on how agents establish searchable identities and trust relationships. x402 focuses on how service requests trigger payments and how payment authorization and settlement fit into internet interactions.
| Comparison Dimension |
ERC-8004 |
x402 |
| Core Purpose |
Agent identity and trust standard |
HTTP-native payment protocol |
| Main Problem Addressed |
Who an agent is, whether it is trustworthy, and whether its results can be validated |
How to automatically pay for digital services |
| Main Technical Foundation |
ERC-721 and on-chain registries |
HTTP 402, payment authorization, and settlement mechanisms |
| Core Participants |
Agents, clients, feedback providers, and validators |
Clients, resource servers, and payment processing components |
| Provides On-Chain Identity |
Yes |
Does not provide a complete agent identity registration system |
| Records Reputation |
Supports standardized feedback records |
Does not handle general reputation management |
| Handles Payments |
Not directly |
Yes |
| Typical Applications |
Agent discovery, reputation queries, and task validation |
API payments, data purchases, and payments for computing resources |
| Main Risks |
Identity impersonation, fabricated feedback, and validation quality |
Unauthorized payments, incorrect settlement, and service delivery failures |
In practical use, ERC-8004 is closer to identity and trust infrastructure for the agent economy, while x402 is closer to payment infrastructure.
Suppose an AI agent wants to purchase market analysis data. It can use ERC-8004 to look up the service provider's registration information, historical feedback, and validation records to assess whether to work with it.
When the agent decides to access the service, x402 can help it complete the payment. After service delivery, the client can also record feedback through ERC-8004's relevant mechanisms.
However, application developers must integrate this collaboration workflow. It does not happen automatically simply because ERC-8004 is deployed or x402 is supported.
How Does x402 Enable AI Agents to Make Automated Payments?
The core mechanism of x402 embeds payment requirements into the standard HTTP request and response workflow.
In x402 V2, a typical payment process can be divided into six stages.
AI Agent Automated Payment Workflow
Illustrative workflow; the specific order of verification, settlement, and delivery depends on the payment scheme used.
For example, an AI agent requests access to a market data API priced at 0.05 USDC. The server can use an 402 Payment Required response to notify the client that the resource requires payment and provide acceptable payment terms.
After checking the price, supported blockchain, and recipient information, the client uses an authorized wallet to generate a payment signature and sends the request again.
In x402 V2, the server can provide payment requirements through PAYMENT-REQUIRED, the client submits signed payment information using PAYMENT-SIGNATURE, and the server can return the payment processing result through PAYMENT-RESPONSE.
The resource server can handle payment verification and settlement itself or use components such as a Facilitator. A Facilitator helps verify payment authorizations and execute settlement, but it is not a centralized third party that every implementation must rely on.
Notably, different payment schemes may have different requirements for the order of settlement and resource delivery. It is therefore incorrect to assume that every x402 request must complete on-chain settlement before any operation can take place.
How Do ERC-8004 and x402 Work Together to Build Automated Transaction Workflows for AI Agents?
Together, ERC-8004 and x402 can support a complete business scenario spanning service discovery, payment, delivery, and feedback.
Suppose a crypto research agent needs to analyze a token's on-chain transactions but does not have sufficient data resources of its own.
First, it can use ERC-8004's Identity Registry to find agents that provide on-chain data analysis services and obtain the relevant service descriptions and interface information.
Next, it can read historical feedback in the Reputation Registry and check for independent validation records based on the task's importance. Historical performance may be sufficient for a low-cost basic data query, while a high-value financial analysis task may require additional validation.
After selecting a service, the research agent sends a request through the appropriate communication interface. The service provider uses x402 to return payment requirements, and the research agent authorizes payment within its preset budget and permissions.
After obtaining the data, the research agent can continue its analysis and leave feedback based on service quality. If the results need further verification, it can also involve an independent validation service.
This workflow demonstrates the complementary relationship between the two protocols:
ERC-8004 helps agents discover services and assess trust, while x402 helps them pay for services.
However, ERC-8004 does not automatically guarantee delivery, and x402 does not directly provide a general mechanism for task acceptance or refund arbitration. For high-value services, developers still need to design mechanisms for fulfillment, dispute resolution, and fund protection.
How Do ERC-8004, x402, MCP, and A2A Work Together?
In addition to ERC-8004 and x402, MCP and A2A are important components of agent infrastructure.
MCP (Model Context Protocol) primarily helps AI applications connect to external tools, resources, and data, enabling agents to access databases, search services, and other system capabilities.
A2A (Agent2Agent) focuses on communication and task collaboration between different agents, including capability descriptions, message exchange, and task lifecycle management.
ERC-8004 does not replace MCP or A2A. Instead, it adds discovery and trust mechanisms for cross-organizational environments. x402 can provide payment capabilities for paid services within these workflows.
The relationship between the four can be summarized as follows:
| Protocol |
Core Question |
Role in Agent Collaboration |
| MCP |
How can tools be connected? |
Accessing external data and services |
| A2A |
How can an agent collaborate with other agents? |
Messaging and task management |
| ERC-8004 |
How can agents be discovered and assessed? |
Identity, reputation, and validation |
| x402 |
How can services be paid for? |
Payment authorization and settlement |
For example, a research agent can access data tools through MCP, collaborate with another analysis agent through A2A, look up its identity and reputation through ERC-8004, and then pay for data or computing resources through x402.
The advantage of this modular design is that the protocols can evolve independently. Application developers can choose components according to their actual needs without tying all functionality to a single platform.
How Can AI Agents Safely Manage Automated Payment Permissions?
Automated payments are an important capability of the agent economy, but they also introduce new fund security concerns.
Traditional payments typically require users to confirm the amount and recipient, while AI agents may continuously call services without real-time human supervision. Without clear limits, incorrect task planning, malicious interfaces, or manipulated external data can lead to unnecessary spending.
Automated payment systems therefore need to separate agents' decision-making capabilities from their authority to control funds.
One practical approach is to use a smart contract wallet to set an agent's per-payment limit, daily budget, approved recipient addresses, and authorization scope for specific tasks.
For example, a business can allow a research agent to pay no more than 1 USDC per transaction and spend no more than 20 USDC per day, while restricting payments to reviewed service providers.
For transactions that exceed the budget, the system can require human confirmation rather than allowing the agent to raise its own payment limit.
Smart accounts and account abstraction mechanisms in the Ethereum ecosystem can support more flexible permission designs, including session keys, spending limits, and allowlists.
However, payment limits cannot replace service security reviews. A malicious provider may induce an agent to repeatedly request paid resources or influence subsequent decisions through seemingly normal API responses.
Practical deployments therefore also need to check that payment requests align with the original task, prevent duplicate payments, and establish monitoring and suspension mechanisms for abnormal transactions.
Truly secure automated payments do not give AI agents unrestricted control over funds. They enable autonomous execution within clearly defined authorization limits.
What Technical and Business Challenges Do ERC-8004 and x402 Face?
ERC-8004 and x402 provide important foundational capabilities for the agent economy, but several issues remain before they can support large-scale, stable commercial use.
The first is the credibility of identity and reputation. ERC-8004 can record identities and feedback, but it cannot inherently prevent a single developer from registering many agents or using related accounts to fabricate reviews. Building Sybil-resistant reputation mechanisms still requires additional economic constraints and validation designs.
The second is task result validation. For deterministic computational tasks, results can be checked through reexecution or cryptographic proofs. However, investment analysis, content creation, and complex business decisions often have subjective outcomes whose quality cannot be judged solely from on-chain records.
The third is the relationship between payment and service delivery. x402 can handle payment workflows, but additional refund, escrow, or dispute resolution mechanisms are still needed if service quality falls short of expectations. A successful payment does not mean that a task has necessarily been completed.
The fourth is cross-chain and asset compatibility. Stablecoins, transaction fees, and settlement mechanisms differ across networks. Agents must correctly identify payment networks and assets to avoid losing funds because of configuration errors.
The final challenge is regulation and commercial adoption. As AI agents participate in financial services, data procurement, and enterprise payments, developers need to consider authorization to use funds, customer identity, data privacy, and applicable payment regulations.
These issues show that ERC-8004 and x402 are better suited to serving as open infrastructure than as a complete business solution covering identity, payments, fulfillment, and legal liability.
What Do ERC-8004 and x402 Mean for the Ethereum and Web3 Ecosystems?
The development of ERC-8004 and x402 extends blockchain use cases further into economic collaboration between machines.
In the past, individual users or enterprise systems initiated most on-chain transactions. As AI agents become capable of executing tasks autonomously, blockchains are beginning to support functions such as agent identity registration, payment settlement, and verifiable records.
ERC-8004 provides composable trust information for open agent networks, while x402 makes it easier to integrate pay-per-use digital services into automated payment workflows.
For Ethereum and its Layer 2 ecosystem, agent identity registration, reputation records, and stablecoin payments may create demand for new on-chain applications.
However, ERC-8004 is not limited to Ethereum mainnet. Its registries can be deployed on different compatible networks. x402 is also not exclusive to Ethereum and can operate with other supported blockchains.
The development of these protocols therefore does not mean that all agent transactions will concentrate on Ethereum, nor does it directly imply that the price of ETH will necessarily rise.
Over the longer term, the key question is whether AI agents can establish sustainable service supply and demand relationships in open networks, gradually moving identity, payments, and task execution from proofs of concept into real business operations.
Conclusion
ERC-8004 and x402 address two foundational issues in the AI agent economy: trust and payments.
Through identity, reputation, and validation registries, ERC-8004 provides cross-platform agents with searchable identities and trust signals. Through the HTTP 402 payment mechanism, x402 enables agents to pay for digital resources under preset authorizations when accessing them.
The two are not substitutes for one another. They are infrastructure components that can be combined. ERC-8004 helps agents choose collaborators, x402 helps them conduct economic interactions, and MCP and A2A can handle functions such as tool connectivity and agent communication.
However, identity registration does not establish genuine trustworthiness, and completed payments do not guarantee service quality. Whether the agent economy can scale will still depend on the maturity of mechanisms for identity verification, reputation governance, task acceptance, fund permissions, and regulatory compliance.
ERC-8004 makes AI agents easier to discover and assess, while x402 makes it easier for them to pay for services. Together, they provide an important foundation for an open, composable agent economy.
FAQ
What is ERC-8004?
ERC-8004 is an on-chain identity and trust standard for AI agents. Through identity, reputation, and validation registries, it helps agents from different platforms be discovered, assessed, and validated.
What is x402?
x402 is an open payment protocol based on HTTP 402 Payment Required. It allows applications or AI agents to authorize and settle payments when accessing paid APIs, data, and other internet resources.
What is the main difference between ERC-8004 and x402?
ERC-8004 primarily addresses agent identity discovery and trust, while x402 primarily addresses automated payments. They provide different foundational capabilities.
Can ERC-8004 make payments directly?
No. ERC-8004 does not define a general payment settlement workflow, but it can be used with payment protocols such as x402.
Does x402 have to use Ethereum?
No. x402 can operate with different supported blockchains and payment assets. It is not exclusive to Ethereum.
Do AI agents using x402 need human confirmation for every payment?
Not necessarily. Developers can preset wallet permissions and payment budgets so that agents can pay automatically within their authorization limits. Human approval can be required for high-risk transactions or those that exceed the limits.
Does an ERC-8004 on-chain identity mean an agent has passed a security review?
No. On-chain registration only provides a searchable identity identifier. Assessing trustworthiness still requires reputation, independent validation, and other security measures.
What use cases can ERC-8004 and x402 support?
Typical use cases include AI agents purchasing data, making pay-per-call API requests, paying for computing resources, delegating tasks to other agents, and establishing cross-platform service feedback records.
