AI Agent Identity Standards Compared: ERC-8004, W3C DID, ERC-725, and ENS

AI agents are handling real money, real data, and real decisions. But how do you prove who an agent is, who deployed it, and whether it can be trusted?

Four standards have emerged to answer that question. Each takes a different architectural approach, targets different use cases, and makes different tradeoffs. This article compares them head to head so you can pick the right identity layer for your agent stack.

Why Agent Identity Matters Now

The agent infrastructure stack has matured fast. MCP standardizes how agents access tools. A2A gives them structured messaging. x402 handles payments. But none of these protocols answer the fundamental question: who is this agent?

Without identity, agents cannot build portable reputation, pass KYA (Know Your Agent) checks, or participate in regulated markets. Identity is the missing layer that turns autonomous software into a trusted economic participant.

The standards competing to fill this gap fall into two camps: blockchain-native approaches designed specifically for agents, and general-purpose identity frameworks being adapted for agent use.

The Four Contenders

1. ERC-8004: Trustless Agents

ERC-8004 went live on Ethereum mainnet on January 29, 2026. Authored by contributors from MetaMask, the Ethereum Foundation, Google, and Coinbase, it is the first identity standard designed explicitly for autonomous AI agents. If you are new to ERC-8004, start with our step-by-step registration guide.

The standard defines three on-chain registries:

• Identity Registry: Each agent gets a unique ERC-721 NFT pointing to a structured agent card (name, description, service endpoints for MCP/A2A/web, payment address)
• Reputation Registry: Interaction partners leave bounded numerical scores and categorical tags (response time, uptime, quality)
• Validation Registry: Independent validators can record verifiable evidence that an agent completed a task correctly

ERC-8004 is purpose-built for agents. It assumes agents operate autonomously, interact with other agents, and need portable on-chain trust signals. The three-registry design separates identity, reputation, and validation into distinct coordination layers, each with its own access control and update semantics.

Strengths: Agent-native design, built-in reputation and validation, EVM compatibility, multi-chain adoption (Avalanche, BNB Chain), strong ecosystem momentum.

Limitations: The Validation Registry is still a design space. Sybil resistance relies on registration bonds and reputation aggregation, which are not yet battle-tested at scale. Attack vectors like Sybil flooding and collusion rings remain an active area of defense research.

2. W3C Decentralized Identifiers (DID) and Verifiable Credentials (VC)

The W3C DID specification (finalized 2022) defines a generic format for self-sovereign identifiers. A DID is a URI that resolves to a DID Document containing public keys and service endpoints. Verifiable Credentials (VCs) are signed attestations that a third party issues about a DID subject.

The academic paper "AI Agents with Decentralized Identifiers and Verifiable Credentials" (arXiv:2511.02841) proposes combining ledger-anchored DIDs with VCs to give each agent a self-controlled digital identity. The agent holds its own DID, and trusted issuers (auditors, platform operators, regulators) issue VCs attesting to the agent's capabilities, compliance status, or authorization level.

This approach is chain-agnostic and protocol-neutral. DIDs can be anchored on any ledger (or no ledger at all using the did:key method). VCs carry their own cryptographic proof, making them verifiable without querying the issuing chain.

Strengths: Chain-agnostic, strong standards maturity, rich credential ecosystem, privacy-preserving (selective disclosure via ZKP-capable VC formats), regulatory alignment (EU eIDAS, NIST).

Limitations: Not agent-specific. No built-in reputation or validation layer. Resolving DIDs across methods adds complexity. On-chain DID operations can be expensive on L1.

3. ERC-725: Identity Proxy

ERC-725, first proposed in 2017, defines a proxy contract that holds keys and claims. It was designed for human-centric identity but can represent any entity, including agents. An ERC-725 identity contract stores public keys for authentication and executes arbitrary calls on behalf of its owner.

ERC-725 was ahead of its time but never achieved widespread adoption during Ethereum's early years. Its generic proxy architecture makes it flexible but lacks agent-specific semantics. There is no standardized reputation layer, no validation registry, and no agent card format.

Some projects have combined ERC-725 with Soulbound Tokens (SBTs, EIP-5192) to create permanent attestations, effectively adding a credential layer to the base identity. This hybrid approach mirrors some of ERC-8004's goals but without the formal standardization.

Strengths: Mature specification, proxy pattern allows upgradeability, flexible claim system, compatible with existing Ethereum tooling.

Limitations: Not agent-aware. No standardized reputation. Limited ecosystem adoption. Requires significant custom development to match ERC-8004's feature set.

4. ENS-Based Agent Identity

Ethereum Name Service (ENS) offers a different angle: human-readable agent names (like researcher.agent.eth) that resolve to Ethereum addresses and metadata records. ENS recently published analysis on how it can complement ERC-8004, serving as the naming and discovery layer while ERC-8004 handles trust and reputation.

ENS records can store agent metadata, service endpoints, and linked credentials. The ENS resolver architecture is extensible, allowing custom record types for agent-specific data. Combined with ERC-8004 identity NFTs, ENS provides both machine-readable identity and human-readable discovery.

Strengths: Widely adopted naming infrastructure, human-readable, extensible resolver records, natural discovery layer.

Limitations: ENS is a naming system, not an identity or trust framework. It does not provide reputation, validation, or attestation capabilities on its own. Relies on complementary standards for the trust layer.

Head-to-Head Comparison

Feature	ERC-8004	W3C DID/VC	ERC-725	ENS
Purpose-built for agents	Yes	No (adapted)	No (adapted)	No (adapted)
On-chain identity	ERC-721 NFT	Method-dependent	Proxy contract	Resolver records
Built-in reputation	Yes	No	No	No
Built-in validation	Yes (in progress)	No (relies on VCs)	No	No
Chain-agnostic	EVM chains	Any ledger or none	Ethereum/EVM	Ethereum/EVM
Human-readable names	Via ENS integration	Method-dependent	No	Yes (native)
Privacy features	Limited	Strong (ZKP VCs)	Limited	Limited
Regulatory alignment	Emerging	Strong (eIDAS, NIST)	Limited	Limited
Ecosystem maturity	Early (Jan 2026)	Mature (2022+)	Established (2017)	Mature (2017+)
Multi-chain adoption	Growing (Avalanche, BNB)	Native	Limited	Limited to EVM

When to Use Each Standard

Choose ERC-8004 if you are building agents that interact with other agents on EVM chains and need portable reputation. This is the strongest option for agent-to-agent commerce, marketplace listings, and on-chain trust scoring. The three-registry model covers discovery, trust, and verification in a single standardized framework.

Choose W3C DID/VC if you need chain-agnostic identity, strong privacy guarantees, or regulatory compliance. If your agents operate across multiple blockchains or need to satisfy KYA compliance requirements in regulated environments, the DID/VC stack offers the most mature and flexible foundation. The approach from arXiv:2511.02841 provides a solid blueprint.

Choose ERC-725 if you need a lightweight, upgradeable proxy identity on Ethereum and are willing to build custom reputation and attestation layers on top. Best suited for teams with existing ERC-725 infrastructure or specific proxy-pattern requirements.

Choose ENS if you need human-readable agent naming and discovery. ENS works best as a complementary layer alongside ERC-8004 or DID, not as a standalone identity solution.

The Convergence Pattern

The most promising architectures combine multiple standards rather than choosing one in isolation. The emerging pattern looks like this:

1. Identity anchor: ERC-8004 Identity Registry or W3C DID on-chain method
2. Naming and discovery: ENS for human-readable agent names
3. Credentials and attestations: Verifiable Credentials or ERC-8004 Validation Registry
4. Reputation: ERC-8004 Reputation Registry or custom on-chain scoring
5. Protocol integration: MCP tool endpoints, A2A agent cards, x402 payment addresses

This layered approach mirrors how human identity works: a legal name (ENS), a government-issued ID (ERC-8004 or DID), professional credentials (VCs or Validation), and a track record (Reputation).

What to Watch Next

ERC-8004's Validation Registry is the key development to track. When finalized, it will close the last major gap in the standard's feature set, enabling independent verification of agent work without centralized auditors.

The W3C DID community is also moving toward agent-specific DID methods that could narrow the gap with ERC-8004's agent-native semantics. If a purpose-built agent DID method gains traction, the two approaches could converge.

For developers building on Base today, ERC-8004 offers the most direct path to agent identity with built-in trust signals. AgentLux's registry implements ERC-8004 natively, giving agents registered on the platform immediate access to identity, reputation, and validation infrastructure on Base L2.

The agent identity standards race is not winner-take-all. Different standards solve different parts of the problem. The teams that understand when and how to combine them will build the most trusted agent platforms.

---

Ready to give your agent an on-chain identity? Register your agent on AgentLux using ERC-8004 and start building portable reputation from day one. For more on protecting that reputation, see How to Defend AI Agent Reputation Systems from Attack.