ERC-8004 Explained: Identity, Reputation and Limits

ERC-8004 is an Ethereum proposal for discovering AI agents and sharing trust signals across applications. It defines an identity registry based on ERC-721, a common interface for publishing reputation feedback, and a registry for independent validation requests and responses. The goal is to help software find agents beyond one platform—not to certify that any agent is safe. As of 1 October 2026, the EIP is still labelled Draft, even though its implementation repository lists contracts on Ethereum mainnet and other networks.

What ERC-8004 standardizes

Created on 13 August 2025, ERC-8004 proposes three registries that can be deployed on Ethereum or an L2. In the proposal, an agent’s identity and its trust evidence are separate layers:

Registry	What it does	What it does not establish by itself
Identity	Uses an ERC-721 token ID (`agentId`) as a portable identifier. Its `agentURI` points to a registration file that can describe the agent and list services such as A2A or MCP endpoints.	That the advertised endpoint is safe, available, or controlled by the person or team a user expects.
Reputation	Lets clients publish a signed numeric feedback value, optional tags, and optional evidence references. Feedback can be queried and filtered by applications.	One universal rating formula or a reputation score immune to manipulation.
Validation	Lets an agent request a check from a named validator and lets that validator record a response, with optional evidence.	A guarantee that every validator is independent, accurate, or economically accountable. Those assumptions depend on the validation system.

The identity token can be transferred, and the owner can delegate management of the agent record. The registration file may live off-chain and its URI can be updated, so consumers should verify the file, its endpoint claims, and who controls updates instead of treating the token as a certificate.

A practical implementation note: the linked contract repository lists mainnet deployments, but its README says the Validation Registry section is still under active discussion and revision. The EIP’s specification and a particular chain’s deployed implementation are therefore not interchangeable; check the contract version and supported functions before integrating them.

How an ERC-8004 registration works

A basic discovery-and-feedback flow looks like this:

Register an agent. A controller creates an identity token in the registry on a chosen chain and receives an agentId.
Publish the agent record. The token’s agentURI resolves to a registration file containing a name, description and optional service endpoints. It can point to HTTPS, IPFS, or another URI scheme allowed by the proposal.
Discover and inspect. A client or directory reads the identity and decides whether the advertised endpoint fits its needs. ERC-8004 does not prescribe one discovery interface or ranking algorithm.
Record feedback. After an interaction, a client can submit a value and optional tags or evidence. The registry prevents the agent owner and approved operators from directly reviewing their own agent.
Request validation when needed. For a task where a review is insufficient, an agent can ask a validator to assess a request and record a response. The application still has to decide which validators and evidence it trusts.

ERC-8004 is complementary to agent communication protocols. MCP exposes tools and resources to an AI application; A2A supports communication and task handoffs between agents. ERC-8004 aims to give those agents a portable discovery and trust-signal layer across organizational boundaries. For the adjacent identity and permission problem, see our guide to AI agent identity and least privilege; for protocol roles, read MCP vs A2A.

What ERC-8004 can—and cannot—prove

A shared registry improves interoperability: different apps can read identity and feedback using the same broad interface. But a common data format is not the same as a common definition of trust.

Feedback can be Sybil-manipulated. Blocking feedback from an agent’s owner and operators stops one direct form of self-review, not a group of newly created or coordinated addresses. The proposal itself warns about Sybil attacks and leaves complex reputation aggregation to off-chain systems.
A numeric value needs context. The proposal supports optional tags and precision, but applications decide how to interpret ratings, weight reviewers, handle old feedback, and surface disputes. A score without that policy is easy to misread.
A metadata hash proves integrity, not truth. A hash can help show that referenced evidence has not changed; it cannot show that the evidence is accurate or that an advertised capability works.
Validation inherits the validator’s assumptions. The proposal describes hooks for methods such as re-execution, zkML verification, or trusted-execution-environment attestations. Incentives and slashing are handled by the specific validation protocol, not supplied universally by the registry.
Payments are out of scope. ERC-8004 can carry references associated with an interaction, but it does not define a payment rail or settle an agent’s work.

The safest interpretation is modest: ERC-8004 can make an agent easier to identify and let applications exchange trust-related evidence. It does not make that evidence conclusive. This is similar to the operational distinction between knowing an agent’s identity and knowing what it is authorized to do; our separate guide to observability for AI agents covers another layer of production assurance.

An implementation checklist for builders

Before relying on an ERC-8004 profile in a product:

Pin the chain, registry address, contract version and ABI; verify that each address comes from the implementation project or another primary source.
Resolve the agent record safely. Validate the URI, endpoint domains, content type and update history; do not execute metadata or follow arbitrary instructions merely because they are listed.
Define what feedback means in your application. Record reviewer provenance where possible, filter Sybil patterns, account for revoked or disputed reviews, and avoid presenting a raw number as a universal trust score.
Choose validators according to the value and risk of the task. Document what each validation result proves, what evidence it uses, and who is accountable for errors.
Keep wallet controls and authorization separate from agent discovery. A registry entry is not spending permission; apply transaction limits, scoped keys, monitoring and human approval where the action warrants them.
Re-test when a profile, endpoint, registry implementation or validation policy changes. Agent trust is operational data, not a one-time onboarding checkbox.

FAQ

Is ERC-8004 a finalized Ethereum standard?

No. On 1 October 2026, the canonical EIP page labels ERC-8004 as Draft. Its implementation repository lists deployed contracts, but deployment does not change the proposal’s status.

Does ERC-8004 make an AI agent trustworthy?

No. It standardizes identifiers and ways to publish feedback or validation responses. A consumer still needs to judge the source, quality and relevance of those signals and the agent’s actual permissions.

Is ERC-8004 the same as MCP or A2A?

No. MCP connects an AI application to tools and resources; A2A connects agents for task communication. ERC-8004 proposes shared on-chain registries for discovering agents and exchanging trust signals. They address different layers and can be used together.

The SignorCrypto view

ERC-8004 is useful infrastructure for agent discovery, but the word “trustless” should not be read as “trust is solved.” The standard can make identities and evidence more portable; it cannot choose a trustworthy reviewer, prove an agent’s future behaviour, or replace application-level security. Builders should treat the registries as inputs to a risk model—not as a green light.

Sources

If you’re designing a cross-platform agent directory or integrating trust signals into a product, talk to SignorCrypto about the architecture and implementation trade-offs.