What Is ERC-8004? Inside Ethereum’s Proposed Standard for Trustless AI Agents

The era of trustless agents is here. AI agents can register persistent on-chain identities via ERC-8004 registries, with mainnet deployment on January 29, 2026.

Originally proposed by Ethereum developer Davide Crapis, ERC-8004 outlines a shared trust layer for autonomous agents that register and interact on-chain.

ERC-8004 is an Ethereum Improvement Proposal (EIP) that allows AI agents to be registered and verified through on-chain registries. 

This lets them discover each other, authenticate themselves, and interact without human intermediaries.

According to Ethereum, developers can implement trust via pluggable mechanisms such as client feedback, validation via stake-secured re-execution, zero-knowledge machine learning (zkML) proofs, or trusted execution environment (TEE) oracles, enabling activities such as ordering pizza or receiving a diagnosis to soon be completed by AI agents. 

This article explains what ERC-8004 is, how it fits into the evolution of AI in blockchain, and why it may become a key standard for decentralized agent coordination. Additionally, it addresses the risks and how they are tied to understanding the system’s design, function, and practical limits.

What Is ERC-8004 and Why It Matters

ERC-8004 creates a shared trust standard for autonomous agents on Ethereum. It offers a public way for AI agents to identify themselves, build reputation and prove completed tasks using the blockchain via three on-chain registries, explained further in this article. 

ERC-8004 replaces platform-level identity and validation logic with shared on-chain registries, allowing agents to authenticate and verify actions without relying on centralized services.

Current AI systems often depend on private APIs or third-party services to authenticate actions or users. ERC-8004 replaces that setup with on-chain tools that allow agents to interact securely and independently. 

The system supports portable, verifiable and decentralized machine coordination. 

By using ERC-8004, developers can create AI agents that operate across apps and ecosystems. Ethereum becomes the trust layer, not the bottleneck. 

With mainnet deployment imminent (according to the Ethereum Foundation), this shift may reshape how agents collaborate, automate services, and deliver results in decentralized environments.

How ERC-8004 Works: The Three Core Registries

ERC-8004 relies on three on-chain registries that give AI agents the structure to act independently while remaining accountable. These are the registries that handle identity, reputation, and task validation, mentioned before and detailed in this section.

They are deployed as singleton contracts, meaning each registry is set up only once per chain to reduce resource use. 

These contracts are lightweight to minimize on-chain storage and costs. Instead of holding all agent data directly, they link to off-chain files using Uniform Resource Identifiers (URIs) or InterPlanetary File System (IPFS) hashes. This allows agents to publish detailed information without bloating the blockchain.

Identity Registry

This registry provides a digital identity for each AI agent. It issues a non-fungible token (NFT) under the ERC-721 standard, which acts as the agent’s on-chain identifier. It has the following characteristics:

• Metadata structure: The NFT links to an off-chain file containing details such as the agent’s name, capabilities, endpoint addresses, payment information, and references.
• Interoperability: It supports Machine Coordination Protocol (MCP) endpoints and agent cards, helping agents communicate across ecosystems.
• Ownership control: The identity can be transferred or delegated, which makes it flexible, censorship-resistant, and portable.
• Cross-platform compatibility: Built using existing NFT tools, the identity works across different Ethereum-based networks.

This registry ensures agents have a consistent and verifiable presence, which is essential before any interaction can occur.

Reputation Registry

This registry records how each agent has performed in past interactions.

It helps other agents or users assess whether an agent can be trusted. It allows the following:

• Feedback entries: Reputation is submitted as signed entries that include scores, tags, comments, and optional payment proofs.
• Spam protection: Agents must prove authorization through cryptographic methods like Ethereum Improvement Proposal 191 (EIP-191) or  Ethereum Request for Comments 1271 (ERC-1271), helping prevent fake reviews or Sybil attacks.
• Filtering and analysis: On-chain filters allow basic searches by tag or reviewer. Complex analytics and rankings are handled off-chain through indexing tools like subgraphs, which index and structure registry data for faster querying.

By linking all feedback directly to an agent’s identity, this registry allows others to check credibility before starting any task.

Validation Registry

This registry confirms whether agents completed tasks as promised. It helps ensure accuracy, especially in high-stakes use cases. Validation registry aims to provide:

• Validation flow: Agents request validation, and third-party validators respond with proof of execution. Validators may include other agents or decentralized services.
• Verification methods: Supported proofs include stake-secured re-execution, zkML,  and TEE attestations.
• Context awareness: Each result is tied to the agent’s identity, making it easy to track the outcome back to the source.
• Flexible design: Developers can choose different mechanisms based on task complexity. Low-risk tasks may only need reputation checks, while high-risk cases can use cryptographic or hardware-backed proofs.

The registry allows verification without needing human oversight, making it a key part of full agent autonomy.

Together, these three registries form the core of ERC-8004’s trust framework. They give agents the tools to operate transparently, interact freely, and maintain accountability on public infrastructure. 

The standard supports Ethereum’s vision of an open agent economy and works alongside protocols like Agent-to-Agent (A2A) for communication and x402, an open payments protocol developed by Coinbase.

The standard aligns with Ethereum’s broader infrastructure goals, but the flexibility it offers also shifts key responsibilities to developers and protocol designers.

With vs. Without ERC-8004: How Agent Coordination Changes

Before ERC-8004, developers had no unified standard for trust, identity, or validation among autonomous agents. 

Each system relied on isolated logic, private APIs, or custom contracts. This table highlights how ERC-8004 changes agent workflows across coordination, security, and scale.

ERC-8004 is defined by what it enables and what it exposes. Understanding its risks is inseparable from grasping its core capabilities. Both are part of learning how the system works and where boundaries must be set.

Building With ERC-8004: What Comes Next for Developers

Ethereum developer Davide Crapis, who originally proposed ERC-8004, shared the next steps for builders in the recent post previously shown on X.

According to Crapis, developers who want to work with ERC-8004 can start by exploring the official resources available at 8004.org, which include documentation explaining the standard, technical guides for implementation, and tools for deploying agent registries.

He also pointed to the ERC-8004 Telegram community as a space for coordination and early collaboration among teams building agent-based systems.

Crapis highlighted February as “Genesis Month,” a period focused on showcasing projects and teams experimenting with decentralized agent infrastructure.

He framed this phase as an early opportunity for developers to influence how agent identity, trust, and coordination evolve on Ethereum, noting that the foundational design decisions made now will shape future agent-driven economies.

The message reinforces ERC-8004’s position as an open framework rather than a finished product. Its impact will depend on how developers apply the standard, define trust models, and translate on-chain identity into real-world functionality.

ERC-8004 Security Risks and Practical Limits

ERC-8004 provides on-chain primitives for agent identity and reputation, along with proof-based task validation. The standard represents a meaningful step toward decentralized delegation, agent interaction, and outcome verification in trust-minimized environments. 

However, these tools only signal trust. They do not guarantee honest behavior or technical competence. 

Security depends on how each implementation uses the framework and what safeguards developers apply beyond the base protocol. 

As AI systems begin to mediate more on-chain interactions, human oversight remains essential. 

Developers, validators, and governance mechanisms must act as gatekeepers to detect manipulation, enforce limits, and define what trust means in each context. 

For this reason, the following risks tied to ERC-8004 implementations and their design limitations across agent identity, reputation, and task validation are essential to consider and address.

Reputation Manipulation and Sybil Risk

The reputation registry can be exploited through Sybil attacks, which distort trust signals and weaken coordination. Addressing this requires layered technical and economic measures that reduce abuse while keeping participation open.

• Authorization controls: ERC-8004 mitigates part of this risk through feedback authorization using EIP-191, which verifies message signatures, and ERC-1271, which allows contract-based identities to validate those signatures.
• Identity loopholes: These mechanisms confirm that a specific identity posted the feedback, but they do not limit how many identities a malicious actor may control.
• Friction requirements: To reduce manipulation, applications should require reviewers to spend gas, prove ownership of prior validated actions, or hold a minimum stake.
• Weight and cost measures: Assigning different weights to feedback based on reviewer history or setting cost-based barriers can further discourage fake entries and identity farming.

The risk of identity manipulation is only one layer. Attackers may also try to overwhelm the system’s core registries by flooding them with low-cost or malicious submissions.

Spam and Registry Abuse

Without limits, agents could exploit low-cost operations to overload the system or degrade its usability.

• Submission volume risks: Reputation and validation registries can be spammed with empty or repetitive entries if gas costs remain low or unchecked.
• Storage pressure: Unbounded entries per agent may lead to bloated registries that slow down querying and increase infrastructure strain.
• Recommended safeguards: Applications should enforce rate limits, cap the number of entries an agent can post, and apply size or cost constraints to reduce storage abuse.
• Design alignment: Gas-efficient data structures and bounded on-chain operations help contain long-term registry bloat.

Registry abuse is not limited to what happens on-chain. Because much of the agent data lives off-chain, the reliability of that information becomes another source of risk.

Off-Chain Metadata Exposure

ERC-8004 relies on off-chain storage for agent metadata, which introduces reliability and authenticity concerns.

• Content integrity risks: Metadata stored using URIs or IPFS hashes may be altered, removed, or incorrectly configured after registration.
• Untrusted claims: An agent’s on-chain identity does not validate the truth of off-chain content, including endpoints, capabilities, or service references.
• Verification safeguards: Implementations should verify metadata through trusted channels such as HTTPS proofs or domain control signatures.
• Content durability: To reduce failure points, developers should pin important IPFS content, mirror key files, or use redundant gateways.

Each validation method provides a different level of assurance. Reputation checks may work for simple tasks. High-risk cases require stronger proofs, such as zkML or TEE attestations. 

If agents submit too many requests, they increase storage load and slow the registry. Applications must set clear limits to keep validation functional and efficient.

However, even if metadata is accessible and intact, it can still be misleading. Agents may attempt to mimic trusted services by presenting fake endpoints or domain references.

Endpoint and Domain Impersonation

It is important to point out that the protocol does not verify domain ownership or service authenticity, leaving room for deceptive identity claims.

• Impersonation risk: Agents can link to domains or endpoints they do not control, creating the appearance of legitimacy.
• Lack of enforcement: ERC-8004 does not include native checks to confirm whether an agent actually owns or manages a linked domain.
• Suggested verification tools:Implementations should use external methods such as zero-knowledge Transport Layer Security (zkTLS), which proves domain ownership without revealing private data, or signed DNS-based proofs, which confirm control of a domain through verifiable records.
• Risk mitigation note: Without additional verification layers, agents may pass off fraudulent identities by referencing well-known services or interfaces. For example, a malicious agent could claim to represent a major wallet provider like MetaMask or an exchange like Uniswap by linking to similar-looking domains or copied metadata without controlling the real service.

Deceptive domain references are not the only way malicious agents may gain an advantage. Front-running risks also affect how identities and linked resources are claimed at the time of registration.

Front-Running and Registration Capture

Attackers can exploit timing‑based weaknesses in ERC‑8004, especially during agent registration.

• Priority-based manipulation: Adversaries may monitor pending transactions and preemptively register agent metadata, tokenURIs, or domain references.
• No native delay protection: The protocol does not include built-in protections against front-running during agent or registry setup.
• Suggested mitigations: Developers can implement commit-reveal schemes, reservation windows, or delayed activation to prevent opportunistic capture.
• Context-specific design: Developers may need to build time-based protections into applications that depend on exclusive identity claims or sensitive resource links. Attackers can exploit timing differences in registration to capture high-value references. 

Even when identity and registration follow the intended flow, only proper validation, implemented and enforced by the application, can confirm whether agents behave as expected. ERC-8004 provides the structure, but developers are responsible for enforcing verification standards.

Validation Guarantees and Proof Limits

Validation outcomes depend on the mechanism each agent or application uses. Some systems rely on reputation signals, which may be enough for basic tasks. Others need stronger methods to confirm outcomes.

• Inconsistent trust levels: Reputation-based checks may be suitable for low-risk tasks, but they do not guarantee correct execution in cases where accuracy is critical.
• Optional proof enforcement: While ERC-8004 allows the use of stronger options such as stake-secured re-execution, zkML attestations, TEE responses, it does not mandate them.
• Storage impact risks: Without constraints, agents could flood the validation registry with frequent or duplicate proof requests, creating long-term storage overhead.
• Risk-tiered approach: Applications should assign proof requirements based on task sensitivity and exposure, ensuring that high-value actions use cryptographic or hardware-backed validation.

The choice of proof method shapes both the trust model and system load. Beyond verification logic, the contracts behind ERC-8004 bring their own operational risks.

Smart Contract Exposure

ERC-8004 defines registries that run entirely on smart contracts. While the protocol keeps the structure lightweight, it still depends on the correctness and security of contract logic. 

The standard leaves most implementation details to developers, increasing flexibility but also introducing risk. 

Bugs in access control, reentrancy, or upgrade patterns can compromise registry integrity. Each deployment must follow strict auditing and monitoring practices to protect agent interactions from on-chain failure.

• Code-level vulnerabilities: Contract-based registries may face issues such as reentrancy, access control misconfigurations, or unchecked upgrade logic.
• Minimal safeguards by design: The protocol avoids prescriptive patterns, so it does not include built-in defenses against common smart contract exploits.
• Implementation responsibility: Developers must ensure secure deployment, but agents or delegated services can also handle tasks like contract monitoring, upgrade checks, and routine audits. Each registry must stay verifiable, regardless of who oversees the system after launch.
• Permission controls: Each application should define clear roles and restrict access to sensitive contract functions. High-value operations, such as issuing identity tokens or writing to validation logs, require stricter rules than public read functions. These limits help reduce the attack surface and prevent unintentional exposure.

Security design cannot end at the contract level. Even with strong permissioning and verified identities, agents remain vulnerable to manipulation within the broader ecosystem.

Ecosystem-Level Threats

Even with a verified identity and on-chain history, agents can behave dishonestly or fail in unexpected ways. ERC-8004 does not prevent broader coordination failures.

• No competence guarantee: A valid agent identity does not confirm technical ability, ethical behavior, or service quality.
• Adversarial coordination risk: Agents may collude, amplify each other’s reputations, or use feedback loops to distort trust signals.
• Manipulation risk over time: Identity age or transaction volume can be gamed to appear legitimate without delivering real utility.

Developers must treat ERC-8004 registries as input signals, not final answers. To build reliable systems, they need to apply filters, enforce constraints, and monitor agent behavior throughout deployment. 

These risks do not weaken the standard. 

They clarify its purpose: ERC-8004 is not a finished solution, but a flexible base for designing secure, trustless agent coordination. It opens the door to decentralized automation at scale, but success depends on how each system puts those tools to work.

The Road Ahead for ERC-8004

ERC-8004 lays the groundwork for scalable agent coordination on Ethereum. As registries become active and implementations expand, developers will shape what agent-driven infrastructure looks like in practice. 

The flexibility of the standard gives projects room to innovate across AI, decentralized finance (DeFi), automation, and messaging. 

The challenge now is to build systems that not only follow the protocol but also define clear limits, enforceable roles, and measurable outcomes. Adoption will depend on how well these systems balance trust signaling with actual proof.

FAQs

About the Author

Dr. Lorena Nessi

Dr. Lorena Nessi is an award-winning journalist and media technology expert with 15 years of experience in digital culture and communication. Based in Oxfordshire, UK, she combines academic insight with hands-on media practice.

She holds a PhD in Communication, Sociology, and Digital Cultures, and an MA in Globalization, Identity, and Technology.

Lorena has taught at Fairleigh Dickinson University, Nottingham Trent University, and the University of Oxford. She is a former producer for the BBC in London, with additional experience creating television content in Mexico and Japan.

Her research focuses on digital cultures, social media, technology, capitalism, and the societal impact of blockchain innovation.

She has written extensively on digital media and emerging technologies, with her work featured in both academic and media platforms. Her Web3 expertise explores how blockchain technologies shape culture, economics, and decentralized systems.

Outside of work, Lorena enjoys reading science fiction, playing strategic board games, traveling, and chasing adventures that get her heart racing. A perfect day ends with a relaxing spa and a good family meal.

[email protected] LinkedIn X.com