AI agents can already do useful work: call tools, pull data, draft code, and run analyses. What’s still missing is a reliable way to evaluate agents you did not build or operate.
If your agent discovers a third-party service agent, how does it know who runs it, where to reach it, and whether it has a track record worth trusting? Without that, open agent ecosystems turn into a mix of unknown endpoints and brand-based guessing.
ERC-8004 proposes a minimal standard for agent identity, reputation, and third-party validation that can be reused across platforms. The goal is not to run models on-chain. It is to put durable identifiers and trust signals on-chain, while keeping the actual agent logic and payloads off-chain.
Overview
ERC-8004 defines three registries that work together:
- Identity Registry: an ERC-721 identity for each agent, with an agentURI that resolves to an off-chain registration JSON.
- Reputation Registry: a standardized way to record feedback about an agent’s behavior and results.
- Validation Registry: a standardized way to request and record verification of work for higher-stakes tasks.
If you have ever wished there was a DNS-like discovery layer for agents, plus a Yelp-like (but programmable) trust layer, this is in that direction. Payments are explicitly out of scope. Some examples reference how payment receipts could be attached as evidence, but ERC-8004 itself is about identity and trust signals, not value transfer.
Responsibilities:
ERC-8004 is designed around a clear division of responsibilities.
On-chain responsibilities (durable anchors and compact signals)
These are the pieces that benefit from being public, verifiable, and portable:
- Durable identity: agentRegistry + agentId (the global identifier), plus ERC-721 ownership and transfer history.
- Pointer to metadata: agentURI (tokenURI) that tells you where to fetch the registration file.
- Payment destination safety: the reserved agentWallet metadata, updated only with proof-of-control and cleared on transfer.
- Compact trust signals:
- Reputation: numeric value and valueDecimals, plus tags and revocation state.
- Validation: request hashes and validator responses (scores), with optional evidence pointers and hashes.
Think of on-chain as the place for identifiers, commitments, and small trust primitives that other systems can reliably reference.
Off-chain responsibilities (everything large, fast-moving, or sensitive)
These are the pieces you do not want in contract storage:
- The full agent registration JSON content, even though it is referenced by agentURI.
- The actual service endpoints and interactions (MCP, A2A, HTTP request/response traffic).
- Evidence payloads: logs, transcripts, evaluation artifacts, receipts, documents.
- Most sophisticated scoring logic
Off-chain is where the real work happens and where you keep flexibility, privacy, and operational control.
Why put any of this on-chain instead of using a third-party directory?
A centralized directory can work, but it comes with platform risk:
- Portability: In a third-party system, reputation is usually locked to that platform. On-chain identity and signals are readable by any marketplace, dashboard, or agent router.
- Tamper-evidence: A third party can edit or delete history, even if they claim audit logs. On-chain records are much harder to rewrite after the fact.
- Composability: Other tools can consume the same identity and trust signals without negotiating private APIs or accepting a single company’s policies.
- Reduced dependency on one operator: If the directory changes terms, gets acquired, or deplatforms agents, integrations break. On-chain anchors remain available as long as the chain does.
This does not mean everything belongs on-chain. It means the shared reference points are not owned by one company, while bulk data and operations remain off-chain.
Protocol Mechanics
1) Identity Registry: an agent is an ERC-721 plus a registration file
In ERC-8004, each agent identity is an ERC-721 token. The token’s URI (agentURI) must resolve to an agent registration file. That file is the agent’s directory entry: it tells consumers what the agent does and how to reach it (MCP endpoint, A2A agent card, plain HTTP endpoint, and so on). The EIP also allows optional domain verification via a well-known path if you want a stronger binding between an HTTPS domain and an on-chain identity.
Two practical notes:
- Use https:// for operational simplicity, or ipfs:// if you want content-addressed durability.
- Keep this file boring. It should read like config, not marketing.
{
"type": "https://eips.ethereum.org/EIPS/eip-8004#registration-v1",
"name": "InvoiceExtractor",
"description": "Extracts invoice totals and line items from PDFs and returns normalized JSON.",
"image": "ipfs://bafy.../agent.png",
"services": [
{ "name": "web", "endpoint": "https://agent.example.com/" },
{ "name": "MCP", "endpoint": "https://agent.example.com/mcp" },
{ "name": "A2A", "endpoint": "https://agent.example.com/.well-known/agent-card.json" }
],
"active": true,
"registrations": [
{ "agentId": 22, "agentRegistry": "eip155:1:0xYourIdentityRegistryAddress" }
],
"supportedTrust": ["reputation"]
}
2) agentWallet: a small safety feature that matters later
ERC-8004 defines a reserved metadata key, agentWallet, which specifies the wallet address that should receive funds for the agent.
Two properties make it robust:
- Authenticated updates: changing agentWallet requires proof of control; EIP-712 signatures for EOAs, or ERC-1271 validation for smart-contract wallets.
- No stale payouts after transfer: implementations clear agentWallet on token transfer, so payments don’t silently continue to the prior owner after the identity NFT changes hands.
Even if you’re not taking crypto payments today, this is a useful pattern: the destination for value is treated as a verifiable, owner-bound attribute, not just an unchecked string in off-chain JSON.
3) Reputation Registry: raw signals, not a global score
Reputation in ERC-8004 is a numeric signal stored as a fixed-point value (value + valueDecimals), with optional tags and optional off-chain evidence referenced by URI and committed to via a hash. The important thing is what the protocol does not do: it does not try to create a single universal reputation score you should trust. In fact, summary reads are designed around the idea that you filter reputation by a reviewer set you already trust.
If you’re implementing this, you get better outcomes if tags look like reliability dimensions, for example:
- successRate (per task category)
- latencyMs
- uptime
- accuracy (only if you can define the evaluation method)
4) Validation Registry
Validation is the optional higher-assurance piece. It lets an agent request validation for a specific task and record a validator’s response, typically via a URI plus a hash commitment.
ERC-8004 does not force a validator model. A validator could be stake-secured re-execution, a zk verifier, a TEE oracle, or a trusted auditor. The registry is the standardized audit trail, not the verification mechanism.
Overall workflow
Here is a realistic flow you could implement without needing a giant platform:
- Register your agent
- Publish an agent registration JSON with your endpoints and capabilities.
- Store it somewhere durable.
- Mint an identity token pointing to it.
- Discovery
- A client agent searches an indexer for agents tagged “invoice_parsing” or “code_audit.”
- It filters to agents with reputation from a set of trusted reviewer addresses.
- Run the job
- The client calls the endpoint listed in the agent card.
- The agent produces output and returns it off-chain (file, JSON, diff, whatever).
- Optional validation
- For high-stakes jobs, the client or the agent requests validation.
- A validator reviews or re-executes, then posts a validation result.
- Write feedback
- The client posts reputation feedback with tags like accuracy, latency, completeness.
- Optionally attach an evidence hash so disputes are possible later.
That loop is the trust flywheel: identity makes discovery possible, validation builds confidence for serious use, and reputation compounds over time.
Practical use cases
1) Discoverable MCP servers and tool agents
If you run an MCP server or a specialized tool agent, ERC-8004 gives you a standard agent card shape and a durable identifier. Indexers can list you, and other agents can reason about compatibility based on your declared services.
2) Autonomous code maintenance with third-party verification
A dev bot proposes a patch. A validator agent (or a validator service) runs tests or checks the diff in a controlled environment, then posts a validation score. A repo manager (human or DAO) can gate merges on validation thresholds.
3) High-speed DeFi bots with portable track records
Bots are everywhere. The missing piece is a portable record of behavior that is not trapped inside one exchange, one Telegram group, or one app database. An ERC-8004 identity plus reputation events gives you a shared, queryable history.
4) Content moderation swarms
Instead of one centralized moderation model, you can have multiple moderation agents competing. The platform can route tasks to agents with the best reputation among reviewers it trusts, and drop agents whose decisions consistently diverge from the consensus you care about.
5) Specialist agent markets (research, data cleaning, extraction)
These are the boring use cases, which is exactly why they matter. If you can reliably find and evaluate agents that do extraction, reconciliation, tagging, or monitoring, you get a real marketplace of machine labor instead of a demo.
Limits worth stating plainly
ERC-8004 helps with discovery and trust signaling, but it does not make agents safe by default:
- The chain can anchor identities and signals, but endpoints are still off-chain and can fail or misbehave.
- Sybil resistance is not solved, which is why reviewer filtering matters.
- Off-chain availability matters. If registration files or evidence links rot, trust signals lose context.
- Validation quality depends entirely on the validator mechanism and incentives.
Closing
ERC-8004 is a small, composable standard for the pieces agent ecosystems keep rebuilding: identifying an agent, finding its endpoints, and sharing simple trust signals about how it performs. It keeps the blockchain role minimal, stores the heavy data off-chain, and lets you decide what to trust based on the reviewer sets and policies you choose.