ERC-8004: a practical explainer for trustless agents

For agents to cooperate with each other, they need to know about the existence of other agents, what abilities they have, and to be able to trust them to do what is promised. In the case of use within an organization, the matter is simple, but it becomes more complicated if we want a trustless environment.

Scope and goals

ERC-8004 defines a minimal trust layer for automated services called trustless agents that interact with users, other agents, and contracts. It proposes to “use blockchains to discover, choose, and interact with agents across organizational boundaries without pre-existing trust, thus enabling open-ended agent economies”.

The goal is simple: make agents discoverable and enable trust to be scored.

What ERC-8004 standardizes

A shared on-chain interface for agent identity, feedback entries, and validation results.
Event formats and lookups that indexers and contracts can query.
Linkage to off-chain artifacts via URIs for rich, verifiable context.

What ERC-8004 leaves out

Payments and escrow. Payment flows and receipts are handled by complementary mechanisms.
A single reputation formula. The trust score is standardised, but aggregation and scoring strategies are intentionally external.
One validation method. Any verification approach – re-execution, proofs, or attestations – can plug in.

The three registries defined by ERC-8004

1) Identity Registry: portable identifiers for agents

The Identity Registry assigns each agent a globally unique, tokenized entry using ERC-721 semantics with URI storage. The token owner controls the entry; the token’s URI points to an agent registration file (off-chain JSON). That file lists:

Basic agent information (type, name, description, image).
Network endpoints (for example, Agent-to-Agent or Model Context Protocol servers).
Registered instances (can have multiple).
Supported trust models (high-level categories of assurance mechanisms).

Minimal extra metadata can be kept on chain and emitted via events. The combination of ERC-721 ownership and a registration file gives agents a portable identity that indexing services can discover and display.

2) Reputation Registry: structured feedback

The Reputation Registry standardizes how a client (the end user or other agent) records feedback about an interaction with a server agent:

A bounded score (compact integer).
Optional tags to label the context.
A URI pointing to a detailed off-chain report (JSON) with logs, artifacts, or receipts.
KECCAK-256 file hash to guarantee integrity.

To reduce spam and forged feedback, the server agent issues a signed feedback authorization to the client. Signatures can be verified using widely adopted schemes (such as EIP-191 or ERC-1271).

Indexers read events and linked files to power dashboards, but contracts can also query summaries through the registry’s read methods. What is also important is that the feedback can be revoked.

3) Validation Registry: independent checks of agent work

The Validation Registry captures verification signals from independent validators:

A validator references a request by hash or identifier.
The validator submits a compact result code and optional tag on-chain.
A URI links to evidence such as re-execution traces, cryptographic proofs, or attestation reports.

Multiple validation models can coexist. Incentives, staking, and slashing logic are outside the standard, allowing specialized networks to evolve without changing the registry interface.

Interaction model: a typical lifecycle

Register the agent. A builder mints an entry in the Identity Registry. The token URI points to the agent registration file with endpoints and identifiers.
Discover and select. A client or agent directory queries the registry to find candidates by capability or trust model.
Execute a task. The client engages the agent over an off-chain protocol such as A2A or MCP.
Record feedback. The agent server pre-authorizes feedback; the client posts a score, tags, and an evidence URI.
Request validation. A third party re-checks the work and posts a validation result with a link to evidence.
Aggregate for context. Indexers and contracts read summaries to inform future interactions or on-chain decisions.

This lifecycle shows how ERC-8004 keeps identifiers and trust signals on chain while leaving detail-heavy artifacts off chain.

On-chain vs. off-chain boundaries

ERC-8004 treats the chain as a control plane. On chain you will find:

Unique agent identifiers (as ERC-721 tokens).
Small, structured entries for feedback and validation.
Events for indexing and audits, plus read methods for common summaries.

Off chain you will find:

Registration files with endpoints and names.
Feedback reports with logs, receipts, and analysis.
Validation evidence such as traces, proofs, or TEE attestation documents.

URIs connect the two planes. Hashes and event logs create an immutable audit trail, while the bulk of data remains inexpensive to store and easy to evolve.

How ERC-8004 relates to A2A and MCP

Agent-to-Agent (A2A) and Model Context Protocol (MCP) focus on how agents expose capabilities and exchange messages. ERC-8004 focuses on who an agent is and why a counterparty might trust its outputs. The Identity Registry lists the agent’s A2A or MCP endpoints in the registration file. The Reputation and Validation registries then collect trust signals arising from work performed over those channels.

Security considerations noted in the proposal

Sybil and spam resistance. Pre-authorized feedback reduces spam, but many identities can still exist. Public signals enable downstream filtering and weighting strategies.

Pointer integrity. On-chain references and hashes form a durable record. Linked content can be versioned and anchored to prevent silent changes.

Validator economics. Economics—collateral, rewards, penalties—are not specified. Different domains can choose the incentive structures that match their risk.

Capability claims. Registration connects identity to endpoints; it does not by itself prove that an agent fulfills its advertised capabilities. Validation and reputation signals provide the additional context.

These considerations apply at the protocol level. Production deployments also need operational controls appropriate to the value at risk.

ERC-8004 Reference Implementation

A public reference implementation demonstrates the three registries and includes tests and example flows. The contracts model agents as ERC-721 tokens with URI storage and event-rich registries for feedback and validation. Example integrations show signature-based authorizations and URI-linked payloads in practice. Builders can study the repository to understand expected behaviors and event semantics before experimenting on test networks.

Status and discussion channels

ERC-8004 is an ERC-track proposal with an active discussion on the Fellowship of Ethereum Magicians forum and a public reference implementation. The EIP text is the source of truth for interfaces and intent; the forum thread and repository track open questions and iteration.

Summary

ERC-8004 provides a minimal, composable trust layer for agents on Ethereum. The standard anchors identity and compact trust signals on chain through three registries while keeping large or evolving data off chain via URIs. Identity entries make agents discoverable; feedback entries capture structured experience; validation entries record verification outcomes.

Community discussion focuses on on-chain accessibility, aggregation pitfalls, incentives, and the balance between minimalism and usability. The reference implementation and open debate continue to shape how builders use ERC-8004 alongside agent communication protocols and complementary economic systems.