ERC-8004: Building a Trust Layer for Agent Collaboration on Ethereum
Table of Contents
- Introduction
- Why ERC-8004 Exists
- Core Components of ERC-8004
- Community Insights & Enhancements
- Real-World in Action: ChaosChain's Demo
- Developer Quickstart: Building with ERC-8004
- Conclusion
- About Us
Introduction
In a decentralized world where autonomous agents (AI, bots, dApps) must collaborate across organizational boundaries, trust becomes the missing link. ERC-8004, titled Trustless Agents, introduces a minimal but robust on-chain infrastructure that provides agent identity, reputation, and validation while preserving flexibility and modularity.
Created by Marco De Rossi, Davide Crapis, and Jordan Ellis (August 13, 2025), this proposal extends the Agent-to-Agent (A2A) Protocol with trust primitives that are interoperable, lightweight, and future-proof. Ethereum Improvement Proposals
Why ERC-8004 Exists
A2A already enables skill advertising, task orchestration, and messaging among agents, but only in trusted silos. ERC-8004 addresses the cross-organizational trust gap by:
- Preserving minimalist on-chain logic for scalability
- Offering pluggable trust models (reputation, stake, TEE attestations)
- Leveraging standards like CAIP-10 and RFC-8615 for interoperability and discovery
Ethereum Improvement Proposals
The result: a modular, composable trust layer for any Ethereum-compatible environment.
Core Components of ERC-8004
ERC-8004 implements a three-registry architecture that separates concerns while enabling powerful combinations:
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ Identity │ │ Reputation │ │ Validation │
│ Registry │◄──►│ Registry │◄──►│ Registry │
└─────────────────┘ └─────────────────┘ └─────────────────┘
│ │ │
▼ ▼ ▼
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ Agent Cards │ │ Feedback Data │ │ Validation Data │
│ (Off-chain) │ │ (Off-chain) │ │ (Off-chain) │
└─────────────────┘ └─────────────────┘ └─────────────────┘
1. Identity Registry
Agents register their on-chain identity (AgentID), domain (AgentDomain), and address (AgentAddress). Off-chain AgentCards, discoverable via well-known URIs, link back to this identity registry.
2. Reputation Registry
Clients pre-authorize feedback by emitting an AuthFeedback
event. Feedback itself is stored off-chain but tied back to on-chain events and optionally enriched with proof-of-payment hooks suggested by the Ethereum Magicians discussion.
3. Validation Registry
Server agents commit output via DataHash
, which validators then assess. The validation response (0--100 score) is submitted on-chain. This supports both stake-driven and cryptographic validation models.
Ethereum Improvement Proposals
Community Insights & Enhancements
The Ethereum Magicians thread sparked vibrant discussion around keeping the protocol lean while enabling composability and optional extensibility:
- On-chain composability: Some wanted registry responses readable by smart contracts for enforcement logic (e.g., slashing).
- Aggregate reputation scoring: Others proposed optional on-chain functions to compute agent reputation scores from multiple attestations.
- Payment separation: Contributors emphasized keeping payments out of ERC-8004 while enabling feedback to reference payment proofs.
Fellowship of Ethereum Magicians
Real-World in Action: ChaosChain’s Demo
ChaosChain built a full working demo using ERC-8004:
-
Agents: Alice (Server), Bob (Validator), Charlie (Client)
-
Workflow:
- Agents registered via Identity Registry
- Alice submits market analysis and triggers validation
- Bob validates and submits a score on-chain
- Alice authorizes Charlie to leave feedback
- A full on-chain audit trail emerges
-
Architecture: On-chain identity, validation, and reputation registries; off-chain AI logic, orchestration, and data packaging; content-addressed hashes for immutable linkage
Developer Quickstart: Building with ERC-8004
Use this quick guide to get started integrating ERC-8004 registries into your application workflows.
1. Register Agent Identity
identityRegistry.registerAgent( "myagent.example.com", // AgentDomain hosting AgentCard agentAddress // Your Ethereum-compatible agent address );
Then publish an AgentCard at https://myagent.example.com/.well-known/agent-card.json
:
{ "registrations": [ { "agentId": 123, "agentAddress": "eip155:1:0x...", "signature": "0x..." } ], "trustModels": ["feedback","inference-validation","tee-attestation"] }
2. Enable Reputation Feedback
reputationRegistry.acceptFeedback(clientAgentID, serverAgentID);
Then publish feedback off-chain (referenced by the event). Suggested schema:
{ "FeedbackAuthID": "eip155:1:0xabc", "Rating": 90, "ProofOfPayment": { /* optional proof */ } }
3. Register Validation Flow
validationRegistry.validationRequest(validatorAgentID, serverAgentID, dataHash);
Validator responds:
validationRegistry.validationResponse(dataHash, responseScore); // 0--100
4. Run Off-Chain Indexers
Deploy a subgraph or crawler to:
- Read AgentCards and trust model metadata
- Process
AuthFeedback
andValidationResponse
events - Compute reputation or trigger workflow logic
5. Build Trust-Aware Applications
With trust data available, your applications can:
- Discover agents
- Filter by validation or reputation thresholds
- Automate task workflows with offline oracles
- Display transparent, audit-ready trust histories
Conclusion
ERC-8004 is a significant step towards establishing a robust trust framework for decentralized AI agents. By integrating identity, reputation, and validation mechanisms, it empowers agents to interact with confidence and accountability.
About Us
At SC Audit Studio, we specialize in protocols security assessments. Our team of experts is dedicated to ensuring the safety and reliability of your projects. Partner with us to enhance your project's security and gain peace of mind.
Reach out to us for queries and security assessments!
Explore protocols
See DeFi apps and protocols connected to this article, whether they use, implement, or relate conceptually.

GMX V2
Explore GMX V2 on SC Audit Studio, explore audits, security insights, and more.

Aave V3
Explore Aave V3 on SC Audit Studio, explore audits, security insights, and more.
Debita Finance V3
Explore Debita Finance V3 on SC Audit Studio, explore audits, security insights, and more.
Related vulnerabilities
View security reports related to this article, found by our internal systems.

n33k - LMPVault: DoS when `feeSink` balance hits `perWalletLimit`
Tokemak - medium - CrosschainLiquidity

Issue M-2: Incorrect Freshness Logic Validation in PythOracle breaking the entire mechanism for triggering orders
Oku Trade Orders - medium - DEX

BRTR-1 | Redundant Validation
GMX V2 - low - Perpetuals