ERC-8004: What the Standard Is and How It Builds Trust Infrastructure for AI Agents

ERC-8004 is a proposed Ethereum standard for discovering AI agents, registering their identities, and publishing reputation signals and result validation records. Its architecture includes three blockchain registries: the Identity Registry, Reputation Registry, and Validation Registry. They allow applications to find agents from different organizations and assess them using the available data.

The proposal's official name is Trustless Agents. Here, “trustless” means the ability to interact without pre-established trust in the counterparty. An application determines how reliable a particular agent is through its chosen assessment model: client feedback, independent checks, or other evidence.

As of October 13, 2026, the Ethereum Improvement Proposals page lists ERC-8004 as Draft. This article therefore discusses the current draft standard; its interfaces may change. The team's repository already includes implementations and addresses for the Identity Registry and Reputation Registry on several networks, while the Validation Registry section is marked as being under active development. [1][2]

Why AI Agents Need ERC-8004

An AI agent can search for data, call tools, purchase computing resources, and delegate tasks to another agent. Within a single company, trust is usually provided by the owner's infrastructure: an administrator grants access, services undergo internal checks, and responsibility is established through contracts.

In an open environment, this mechanism is less effective. An agent that needs external analytics must choose a provider, verify its service address, understand its interaction history, and determine whether the result is reliable enough for the task at hand.

An accessible API shows that a service can be contacted. A capability description explains what the provider promises to do. Deciding whether to work with it requires additional answers: who controls this identity, which reviews deserve attention, and who has checked the completed work.

ERC-8004 proposes a common format for this information. Identity links an agent to a registry and a registration file. Reputation collects feedback. Validation allows the results of external checks to be recorded. The application uses this information to decide whether to interact. [1]

How ERC-8004 Works: The Three-Registry Architecture

The blockchain stores identifiers, selected metrics, and links to additional materials. The agent itself, its model, API, and detailed results can operate off-chain. This architecture makes it possible to use shared registries while retaining the freedom to choose a runtime environment. [1]

‍

Diagram 1. From Agent Identity to an Interaction Decision

flowchart TD
    I["Identity Registry"] -->|"agentURI"| F["Registration JSON"]
    F -->|"Service address"| A["Off-chain AI agent"]
    I -->|"Identifier"| P["Agent selection policy"]
    R["Reputation Registry"] -->|"Feedback and metrics"| P
    V["Validation Registry"] -->|"Validation results"| P
    P -->|"Allow interaction"| A
  

‍

The agent selection policy is an application component proposed in this diagram. ERC-8004 defines the available signals, while the product determines the criteria: which feedback authors to consider, which checks to require, and which tasks to allow.

Identity Registry: How AI Agent Identity Works

The Identity Registry uses ERC-721, the non-fungible token standard. Upon registration, an agent receives an agentId corresponding to its tokenId. The token owner controls the registered identity and can transfer it to another address. [1]

A complete agent reference consists of two parts:

• agentRegistry — the namespace, network identifier, and registry address;
• agentId — the agent's number within that registry.

For an EVM network, the registry format is eip155:{chainId}:{identityRegistry}. An agentId alone, without the network and contract address, is insufficient: agents with the same number can exist in different registries. [1]

Using ERC-721 provides compatibility with NFT tools and an existing ownership model. Registration confirms the record and control over it; it does not prove the quality of the model or the accuracy of its claimed capabilities.

What the Registration File Contains

The agentURI field points to a JSON file describing the agent. The specification allows HTTPS, IPFS, and data: URIs. The file contains a name, description, image, list of services, and registration references. Services may include an MCP endpoint and an A2A Agent Card. [1]

flowchart TD
    I["Identity Registry"] -->|"agentURI"| F["Registration JSON"]
    F -->|"Service address"| A["Off-chain AI agent"]
    I -->|"Identifier"| P["Agent selection policy"]
    R["Reputation Registry"] -->|"Feedback and metrics"| P
    V["Validation Registry"] -->|"Validation results"| P
    P -->|"Allow interaction"| A
  

After discovering such a record, a client can obtain the service address and then check whether the agent meets its requirements. The active and supportedTrust fields describe the published configuration; the application needs additional checks to confirm availability and the claimed mechanisms.

How an Agent Is Linked to a Wallet

The specification separately manages the reserved agentWallet field, the address for receiving payments. At registration, it is set to the owner's address. Assigning a new wallet requires proof of control: an EIP-712 signature for a regular address or ERC-1271 verification for a smart contract wallet. [1]

When the token is transferred, agentWallet is cleared, and the new owner must confirm the desired address again. This helps prevent the previous owner's payment address from remaining attached to the identity after a transfer. ERC-8004 does not define the service payment process itself.

Reputation Registry: How AI Agent Reputation Is Formed

The Reputation Registry standardizes feedback publication. A record contains a numerical value and decimal precision, and can also include tags, a service address, a link to a detailed file, and its hash. [1]

The main numerical fields are:

• value — a signed integer of type int128;
• valueDecimals — the number of decimal places, from 0 to 18.

For example, value = 9977 and valueDecimals = 2 represent 99.77. The meaning of the metric depends on context. With an uptime tag, it could represent availability as a percentage; with a responseTime tag, it could represent latency, for which the unit of measurement must be agreed upon. [1]

This is a flexible format, but it requires discipline at the product level. To compare two agents, the application must match metrics, units, and observation periods. Averaging availability, ratings, and response times does not produce a meaningful assessment.

Why On-Chain Feedback Does Not Guarantee an Honest Rating

The specification prohibits an agent's owner and approved operators from leaving feedback on their own identity. However, additional addresses can still be used to manipulate ratings. ERC-8004 explicitly identifies the risk of Sybil attacks, in which one participant creates many addresses and poses as independent clients. [1]

In the proposed architecture, ratings should therefore account for the provenance of feedback. A product can consider selected clients, verified interactions, the age of a record, and the relevance of the metric. These are application-level assessment methods that the team must implement separately.

The current getSummary interface requires a non-empty list of clientAddresses. The caller thus explicitly determines whose feedback contributes to the aggregate. A payment record can add context, but payment alone does not prove the client's independence or the quality of the service. [1]

Validation Registry: How an Agent's Results Are Checked

The Validation Registry describes an interface for recording validation requests and responses from a selected validator. In the current draft, an agent's owner or operator calls validationRequest, providing the validator's address, agent identifier, a link to the materials, and the request hash. [1]

The designated validator publishes a response through validationResponse. The response value ranges from 0 to 100. It can be used as a binary outcome, such as 0 or 100, or as a scale whose meaning is defined by the particular validation system. The value itself is not a probability that the result is correct. [1]

Diagram 2. Requesting and Recording an Independent Check

‍

The diagram shows the model from the current draft specification. The validator's infrastructure handles event retrieval, material downloads, and the validation algorithm itself.

The standard lists possible approaches including re-execution backed by economic security, zkML, and TEEs. The registry provides an interface for publishing results; rules for rewards, penalties, and ensuring validator operation fall outside its scope. [1]

For a developer, defining what is being validated is essential. Confirming that particular code ran, verifying a computation, and assessing the usefulness of an answer address different problems. Even a correctly executed program can use unsuitable input data.

The validation section continues to change. Before integrating it, check the draft standard, ABI, and capabilities of the chosen deployed contract. [2]

How ERC-8004 Differs from MCP, A2A, x402, and ERC-4337

These technologies address different parts of agent infrastructure. They can be combined in one product, but the presence of one does not mean the others have already been implemented.

‍

The roles of MCP and A2A are described in ERC-8004's motivation section. x402 uses HTTP 402 to communicate payment requirements and enable programmatic payments. ERC-4337 describes UserOperation processing, including the involvement of a bundler and the EntryPoint contract. [1][3][4]

ERC-8004 and x402: Choosing a Provider and Paying for a Service

One possible integration works as follows: a client discovers an agent, assesses its history, contacts a paid service, and pays for the request through x402. After completion, the client publishes feedback and adds payment information if needed.

This is an application scenario, rather than a mandatory ERC-8004 sequence. The standard does not require x402 or provide automatic escrow, refunds, or dispute resolution. These mechanisms must be designed separately. [1][3]

ERC-8004 and ERC-4337: Identity and Operation Execution

ERC-8004 allows a service to be linked to a registered identity. ERC-4337 provides infrastructure for smart account operations. If an agent is allowed to make transactions, access rules, limits, and approvals are defined by the wallet and application logic.

The presence of ERC-4337 alone does not establish a safe budget for an agent. The team must separately define permitted actions, restrictions, and approval conditions. [4]

Architecture Example: An AI Agent Purchases Analytics Data

Imagine a product in which an agent prepares a liquidity report and obtains data from an external provider. This is an illustrative integration scenario, rather than a description of a live project.

The client searches for providers through a directory, obtains registration references, and verifies service addresses. It then assesses feedback from selected clients, the acceptable age of the data, and the availability of required checks. After choosing a provider, it contacts the API; if the resource requires payment, it can use x402.

The result undergoes application-level checks: does the format meet the requirements, is the data current, and does its coverage match the task? For a higher-stakes task, the product can add an external validator. Only then is the data used in the report.

Diagram 3. Trust Signals in an Application Workflow

‍

In this architecture, the directory, provider assessment, and requirement checks are product components. ERC-8004 provides the standardized records they use. Payment through x402 can accompany the API call and remains a separate process.

How to Integrate ERC-8004 into a Product

Integration should start with the trust problem: whom the application needs to discover, which criteria it should use for selection, and what the consequences of an error are. A tool directory and an agent authorized to perform asset operations will require different safeguards.

This sequence is an engineering recommendation for integration. The standard defines registry interfaces; the team remains responsible for the product's operational and security requirements.

ERC-8004 Limitations to Consider

Registration does not confirm claimed capabilities. An agent can publish a description that does not match its behavior. The specification explicitly states this limitation. [1]

A hash confirms material integrity. A matching hash shows that a particular set of data is being checked. Assessing the truthfulness of its contents requires a separate method.

Reputation depends on sources and context. Public feedback can be manipulated, and metrics without a shared definition are difficult to compare. The provenance of a signal and its relevance to the task must be assessed. [1]

External files and services can become unavailable. A link remains on-chain, but an HTTPS server may stop responding. IPFS requires separate arrangements for data storage and availability.

Ownership and configuration can change. In the proposed product model, it is sensible to account for changes in owner, model, or service address when interpreting older feedback.

Registration on multiple networks does not automatically create a shared rating. The standard allows multiple registrations and permits an agent to operate on other networks. Combining records and signals requires application logic. [1]

These limitations define the scope of development: the registries provide a common foundation, while reliable interaction depends on how the product checks and uses their data.

Where ERC-8004 Can Be Useful

AI agent marketplaces. A shared format for identity and feedback makes it possible to build directories, compare providers for specific tasks, and offer interaction histories.

Paid APIs and data providers. A registration file can link a service to an identity, while feedback can reflect availability, latency, or data quality. x402 can be added as a separate payment method.

Multi-agent systems. When working with providers from different organizations, a shared record layer helps apply a consistent selection and validation policy.

Agents for blockchain operations. Public signals can support the selection of analytics or execution services. Asset operations additionally require wallet restrictions and execution controls.

These are possible product applications of the architecture, rather than claims that the standard has proven effective in every scenario.

Building AI Agent Infrastructure with ERC-8004

ERC-8004's value for a product lies in a common format that links a provider's identity, feedback history, and validation results. This foundation can support directories and agent interaction systems with consistent assessment rules.

Implementation requires registries or integration with existing contracts, an indexer, metadata management, a reputation policy, and an appropriate validation mechanism. If the agent pays for resources or makes transactions, payment infrastructure and wallet restrictions are added to the architecture.

Sources

1. ERC-8004: Trustless Agents — official specification. Status and interfaces checked on October 13, 2026.
2. ERC-8004 Contracts — the team's repository. Implementations, published addresses, and the note on ongoing Validation Registry development.
3. x402 — official documentation.
4. ERC-4337: Account Abstraction Using Alt Mempool — official specification.

‍