Everything You Need to Know About ERC-8004

From everyday errands to professional workflows, AI agents are quickly becoming default “workers” on the internet—calling APIs, negotiating services, and even moving funds. The vision of an autonomous, self-organizing agent economy is no longer a sci-fi concept; it is already emerging across crypto trading, DeFi ops, on-chain research, and agentic commerce.

But beneath the hype sits a hard question:

When two AI agents (built by different teams, with no prior relationship) need to collaborate, how do they establish trust?

If you hired a contractor you have never met, you would check references, past reviews, and credentials. ERC-8004 brings that same idea to decentralized networks—using Ethereum as a neutral trust anchor for agent identity, reputation, and validation. (eips.ethereum.org)

---

What ERC-8004 actually is (and what it is not)

ERC-8004 ( “Trustless Agents” ) is a draft Ethereum application-layer standard designed to help agents be discovered and evaluated across organizational boundaries—without relying on a centralized platform to vouch for them. (eips.ethereum.org)

It does this by standardizing three lightweight on-chain registries:

1. Identity Registry
2. Reputation Registry
3. Validation Registry (eips.ethereum.org)

Just as importantly, ERC-8004 is not a complete agent stack:

• It does not try to replace agent communication protocols (it can point to them).
• It does not define payments (but it can reference payment proofs in feedback). (eips.ethereum.org)

If you want the canonical spec, start here: ERC-8004: Trustless Agents. (eips.ethereum.org)

---

Why crypto needs an “agent trust layer” in 2025–2026

In 2025, crypto UX shifted toward automation: intent-based execution, chain abstraction, smarter wallets, and “AI copilots” for portfolio ops. In 2026, the natural next step is agent-to-agent markets—agents hiring other agents for data, execution, auditing, routing, and settlement.

The problem: automation amplifies adversarial risk.

Without portable trust primitives, open agent markets quickly degrade into:

• Impersonation (fake endpoints, spoofed service descriptions)
• Sybil reputation attacks (many fake agents rating each other)
• Unverifiable claims ( “I ran the strategy” / “I checked the proof” )
• Key compromise (agents that can sign or move funds become high-value targets)

ERC-8004 is Ethereum’s attempt to make trust composable, auditable, and portable—so credibility can travel with an agent across ecosystems. (eips.ethereum.org)

---

The core design: three registries

1) Identity Registry: an agent “passport” as ERC-721

ERC-8004 uses an ERC-721-style identity to register agents, so each agent gets an on-chain handle that existing NFT tooling can already index and display. (eips.ethereum.org)

Key ideas:

• Each agent is identified by:
  • agentRegistry = {namespace}:{chainId}:{identityRegistry}
  • agentId = tokenId (eips.ethereum.org)
• Each agent’s agentURI points to a registration JSON that can include:
  • name / description / image
  • service endpoints (e.g., web, A2A, MCP, ENS, DID, email)
  • whether it supports reputation / crypto-economic validation / TEE attestation (eips.ethereum.org)

Why this matters in practice:

• An agent can advertise a Model Context Protocol ( MCP ) endpoint (tools/resources), enabling standardized tool calling across AI apps. See: Introducing the Model Context Protocol. (anthropic.com)
• It can also advertise on-chain payment receiving via reserved metadata like agentWallet—updated only with proper signatures (EIP-712 / ERC-1271). (eips.ethereum.org)

ERC-8004 also includes optional endpoint-domain verification using a /.well-known/agent-registration.json file—useful when you want users/agents to confirm the operator controls the advertised domain. (eips.ethereum.org)

---

2) Reputation Registry: standardized feedback signals

After an interaction, a client (human or agent) can post feedback to the agent using a standard interface.

Notable design choices:

• Feedback is stored as a signed fixed-point value ( int128 + decimals ) plus optional tags. (eips.ethereum.org)
• Detailed evidence can live off-chain (e.g., IPFS) while the chain stores:
  • events for indexing
  • integrity commitments (hashes) for non-content-addressed URIs (eips.ethereum.org)
• Summaries should be filtered by known client addresses to reduce Sybil/spam risk. (eips.ethereum.org)

This is important for crypto because reputation becomes a routing primitive:

• “Which agent should execute this intent?”
• “Which agent should quote my OTC swap?”
• “Which agent should audit the output before settlement?”

---

3) Validation Registry: verification hooks for high-stakes tasks

Reputation alone is often not enough. ERC-8004 introduces a generic mechanism where:

• An agent requests validation by referencing an off-chain payload (and its hash).
• A validator contract responds with a score (0–100), optionally pointing to evidence. (eips.ethereum.org)

The spec explicitly allows different validation models, including:

• stake-secured re-execution
• zkML-style proofs
• TEE oracles (eips.ethereum.org)

In crypto terms, this is how you upgrade from:

• “people say this agent is good” to:
• “a third party can cryptographically / economically attest the work was done correctly”

---

ERC-8004 and the broader agent stack: MCP, A2A, and payments

A practical mental model:

• MCP standardizes how agents use tools and context (vertical capability). MCP docs. (docs.anthropic.com)
• A2A focuses on agent-to-agent communication and task orchestration (horizontal collaboration).
• ERC-8004 sits outside those flows as the trust and discovery layer (who the agent is, whether it has credibility, whether results can be validated). (eips.ethereum.org)

Payments are deliberately “out of scope,” but ERC-8004 anticipates using proof of payment inside feedback objects. For the payment rail itself, one of the most discussed directions is x402 (HTTP 402 “Payment Required” revived for internet-native payments), pushed as an open standard by major infrastructure players. See: Cloudflare and Coinbase Will Launch x402 Foundation. (cloudflare.net)

---

Current status: draft standard, real-world momentum

ERC-8004 was created on August 13, 2025 and remains in Draft status in the official ERC repository. (eips.ethereum.org)

At the same time, the ecosystem has been moving fast: multiple reports indicate that core ERC-8004 registries were deployed on Ethereum mainnet on January 29, 2026, signaling that “reference implementations” can go live even while standardization continues. (forbes.com)

For an industry-facing perspective in Chinese media, Foresight News has published deep dives on how ERC-8004 + A2A + MCP form a layered agent-economy infrastructure (communication, tools, trust). Reference: AI Agent Economy 基础设施：ERC-8004 & A2A & MCP. (share.foresightnews.pro)

---

Security and user concerns you should not ignore

ERC-8004 improves trust portability, but it does not magically remove risk. Key issues to plan for:

1. Sybil and reputation gaming
   Expect attacker-controlled “review networks.” Use curated reviewer sets, weighting, and validation tiers. (eips.ethereum.org)

2. Endpoint hijacking and malicious upgrades
   Agent registration files can point to endpoints that change behavior over time. Treat endpoint domain verification as a baseline, not a guarantee. (eips.ethereum.org)

3. Key management becomes existential
   If an agent identity is an ERC-721 token, the owner key is effectively the “root of trust.” If that key is compromised, attackers can redirect endpoints, change payment wallets, or transfer ownership.

4. Over-trusting “identity”
   ERC-8004 can prove that a registration file corresponds to an on-chain agent, but cannot guarantee the agent is competent or non-malicious—hence reputation + validation. (eips.ethereum.org)

---

Practical checklist: how to evaluate an ERC-8004 agent before you interact

If you are a user or a protocol integrating agents:

• Confirm the agent’s on-chain identity (registry + agentId)
• Read the agent registration file and verify endpoints (including optional /.well-known/ checks when relevant)
• Treat reputation as contextual: filter by trusted reviewers, specific tags, and relevant endpoints
• For high-value actions, require validation (and define which validators you accept)
• Minimize approvals: do not give agents unlimited token allowances “for convenience”
• Prefer explicit, signed intents over silent background execution

---

Where OneKey fits: securing the keys behind agent identity

ERC-8004 makes agent identity and reputation more portable—but it also raises the stakes on private key security for both agent operators and users.

A hardware wallet like OneKey can be a practical part of an ERC-8004 security model:

• Keeping the agent owner key offline helps reduce endpoint takeover via key theft.
• Hardware-based confirmation can add friction to dangerous actions like transferring an agent identity (ERC-721 ownership) or changing sensitive metadata such as the payment receiving wallet.
• For users interacting with agent-driven flows, using a hardware wallet helps ensure that “agent convenience” does not quietly become “unreviewed signing.”

In an open agent economy, the winners will not just be the smartest agents—they will be the ones with credible trust signals and robust operational security. ERC-8004 is a meaningful step toward that future.