ERC-8004 is an Ethereum standard that extends the Agent-to-Agent (A2A) Protocol with a trust layer, enabling participants to discover, choose, and interact with agents across organizational boundaries without pre-existing trust. The protocol introduces three lightweight, on-chain registries for identity, reputation, and validation.
New to ERC-8004? Start with:
ERC-8004 introduces three lightweight, on-chain registries that enable trustless agent interactions:
| Registry | Purpose | Details |
|---|---|---|
| Identity Registry | Agent discovery & portable identifiers | ERC-721 with URIStorage |
| Reputation Registry | Feedback & attestation system | Standard interface for scores & metadata |
| Validation Registry | Independent verification hooks | Generic validation framework |
- 🔍 Cross-organizational Discovery - Find agents without pre-existing relationships
- 🔌 Flexible Endpoints - Support for A2A, MCP, ENS, DIDs, and wallet addresses
- ⚖️ Modular Trust - Pluggable trust models from low-stake to high-stake interactions
- 🔗 On-chain Composability - Smart contracts can read reputation and validation data
- ⚡ Gas Efficient - Off-chain data storage with on-chain integrity
- 🛡️ Standard Compliant - Full ERC-721 compatibility for NFT marketplace integration
- Reputation-based - Client feedback with scores (0-100), tags, and metadata
- Crypto-economic - Stake-secured validation with economic incentives
- Crypto-verification - TEE attestations and zkML proofs for cryptographic trust
- ERC-8004 Official Website - Official website for ERC-8004: Trustless Agents
- EIP-8004 Specification - Official Ethereum Improvement Proposal
- A2A Protocol Specification - Agent-to-Agent Protocol that ERC-8004 extends
- Status: Peer Review
- Version: v1 Complete
- Registries: 3 operational (Identity, Reputation, Validation)
- Community: Active builder ecosystem with implementations
┌─────────────────┐
│ 🔍 Agent │
│ Discovery │
└────────┬────────┘
│
▼
┌─────────────────┐
│ 🏛️ Identity │
│ Registry │
└────────┬────────┘
│
▼
┌─────────────────┐
│ 📝 Agent │
│ Registration │
└────┬───────┬────┘
│ │
▼ ▼
┌─────────┐ ┌─────────────┐
│ ⭐ Rep. │ │ ✅ Valid. │
│ Registry│ │ Registry │
└────┬────┘ └──────┬──────┘
│ │
└──────┬──────┘
▼
┌─────────────────┐
│ 🔐 Trust │
│ Assessment │
└────────┬────────┘
│
▼
┌─────────────────┐
│ 🤝 Agent │
│ Interaction │
└─────────────────┘
{
"type": "https://eips.ethereum.org/EIPS/eip-8004#registration-v1",
"name": "myAgentName",
"description": "A natural language description of the Agent...",
"image": "https://example.com/agentimage.png",
"endpoints": [
{
"name": "A2A",
"endpoint": "https://agent.example/.well-known/agent-card.json",
"version": "0.3.0"
},
{
"name": "MCP",
"endpoint": "https://mcp.agent.eth/",
"version": "2025-06-18"
}
],
"supportedTrust": ["reputation", "crypto-economic", "tee-attestation"]
}- Trustless Agents Call #1 - September 23, 2025 - First community call with demos and roadmap updates
- Community Call #1 Slides - Presentation slides from September 23, 2025 call
- Trustless Agents Call #2 - Second community call recording
- Trustless Agents Day - Devconnect - Full-day summit at Devconnect exploring Ethereum as coordination layer for AI economy (November 21, 2025)
- Automata DCAP Attestation - Solidity library for onchain Intel SGX and TDX attestation verification, supporting RISC Zero and Succinct
- Intel TDX Attestation SDK - SDK for generating Intel TDX quotes across cloud providers with ZK proof generation
- AMD SEV-SNP Attestation SDK - SDK for AMD SEV-SNP attestation reports with ZK proof support
- AWS Nitro Enclave Attestation - CLI for AWS Nitro Enclave attestation
- Automata SGX SDK - Rust-native SDK for Intel SGX secure enclave development
- Reference Implementation for ERC-8004
- Chaos Chain SDK for building autonomous agents
- Genesis Studio - Commercial prototype for ERC8004
- Primev FastRPC x402 Facilitator - Fee-free x402 payment facilitator on Ethereum mainnet with sub-200ms settlement via mev-commit preconfirmations. Registered as Agent #23175 on the Identity Registry.
- Chitin - Soul identity layer for AI agents on Base L2. Uses ERC-8004
register()for agent passports + Soulbound Tokens (EIP-5192) as permanent soul certificates. Includes W3C DID resolution, on-chain certificates, multi-method governance voting, and A2A readiness verification. Live on Base Mainnet. - Chitin MCP Server - MCP server for AI assistants to verify agent identities, resolve DIDs, and manage certificates (
npx chitin-mcp-server) - Chitin Contracts - Open source smart contracts (MIT). Solidity 0.8.28 + Foundry, 146 tests, verified on Basescan.
AgentStore - Open-source marketplace for AI agents using ERC-8004 identity and x402 payments for trustless agent discovery and USDC settlement.
- AgentStore GitHub - MIT-licensed monorepo with CLI, API, and web frontend
Community Projects
- TrustlessAgents - Community hackathon project implementing ERC-8004
- 8004 Implementation - Community-driven ERC-8004 implementation
- Trustless Agents Course - Comprehensive course on trustless agents and ERC-8004
- Sparsity AI Workshop - Build an ERC-8004 Trustless Agent with TEE
- Ethereum Magicians Discussion - Official discussion thread for ERC-8004
- GitHub Issues - Technical discussions and feedback on the specification
- ERC-8004 Telegram Group - Official builder community and discussion group
📚 Academic papers and research related to trustless agents and ERC-8004
This section is currently being populated. Contribute research papers and academic work!
- Read the EIP-8004 Specification
- Join the Builder Program
- Check out Reference Implementations
- Review Contract Deployments
- Join the Developer Community
Official Implementation: erc-8004/erc-8004-contracts
The reference implementation contracts are deployed on multiple testnets including Ethereum Sepolia, Base Sepolia, Linea Sepolia, and Hedera Testnet. Complete deployment addresses and supported networks are available in the contracts repository.
Mainnet Status:
- Planned Release: End of October 2025
- Target Networks: Major L2s and EVM-compatible L1s
- Governance: Multi-signature governance structure
- Governance Contact: davide.crapis@ethereum.org
- ChaosChain SDK - Full-featured JavaScript/TypeScript SDK
- erc-8004-js - Lightweight JavaScript library
- erc-8004-py - Python implementation
- chaoschain-sdk - Available on PyPI
// Register new agent
function register(string tokenURI, MetadataEntry[] calldata metadata)
returns (uint256 agentId)
// Manage metadata
function setMetadata(uint256 agentId, string key, bytes value)
function getMetadata(uint256 agentId, string key) returns (bytes)// Give feedback (requires agent signature)
function giveFeedback(
uint256 agentId,
uint8 score,
bytes32 tag1,
bytes32 tag2,
string fileuri,
bytes32 filehash,
bytes feedbackAuth
)
// Query reputation
function getSummary(
uint256 agentId,
address[] clientAddresses,
bytes32 tag1,
bytes32 tag2
) returns (uint64 count, uint8 averageScore)// Request validation
function validationRequest(
address validatorAddress,
uint256 agentId,
string requestUri,
bytes32 requestHash
)
// Provide validation response
function validationResponse(
bytes32 requestHash,
uint8 response,
string responseUri,
bytes32 responseHash,
bytes32 tag
)- CAIP-10 - Chain Agnostic Improvement Proposal for account identification
- RFC 8615 - Well-Known URIs specification
- RFC 7071 - A Media Type for Reputation Interchange (Reputons)
- ERC-721 - Non-Fungible Token Standard (base for Identity Registry)
- EAS (Ethereum Attestation Service) - Referenced for on-chain attestations
- ERC-8001 - Agent-to-Agent coordination (mentioned in discussions)
- EAS - Ethereum Attestation Service for on-chain attestations
- A2A Protocol - Agent-to-Agent Protocol that ERC-8004 extends
- x402 Payment Standard - Referenced for potential payment integration
🔍 What is ERC-8004 and how does it relate to the A2A Protocol?
ERC-8004 extends the Agent-to-Agent (A2A) Protocol with a trust layer that allows participants to discover, choose, and interact with agents across organizational boundaries without pre-existing trust. It introduces three lightweight, on-chain registries—Identity, Reputation, and Validation—while leaving application-specific logic to off-chain components.
🏗️ What are the three core components of ERC-8004?
The three registries are:
- Identity Registry - Minimal on-chain handle that resolves to an agent's off-chain AgentCard
- Reputation Registry - Standard interface for posting and fetching attestations
- Validation Registry - Generic hooks for requesting and recording independent checks
🔐 What trust models does ERC-8004 support?
ERC-8004 supports three pluggable trust models:
- Reputation-based systems using client feedback
- Stake-secured inference validation (crypto-economics)
- TEE attestations for agents running in Trusted Execution Environments (crypto-verifiability)
📋 What is the current status of the ERC-8004 specification?
ERC-8004 is in peer review status with a complete specification available. The protocol includes three operational registries (Identity, Reputation, and Validation) and has strong community support with builders actively developing implementations.
✅ What does ERC-8004 v1 include?
The current specification includes:
- ✅ Complete smart contract interfaces for all three registries
- ✅ ERC-721 compatible Identity Registry with metadata support
- ✅ Comprehensive feedback system with on-chain scoring (0-100) and off-chain metadata
- ✅ Validation framework supporting crypto-economic and crypto-verification models
- ✅ Full compatibility with A2A Protocol and MCP endpoints
- ✅ Deployment-ready smart contract specifications
⚡ Why does ERC-8004 prioritize off-chain data storage over on-chain?
The protocol deliberately keeps complex data off-chain for several reasons:
- Gas efficiency - Avoids requiring agents to sign transactions for each feedback
- Scalability - Enables sophisticated reputation algorithms and aggregation services
- Flexibility - Allows for custom validation protocols with their own incentive mechanisms
- Aggregation focus - Single feedback/validation entries are rarely used alone; they're typically aggregated
🔗 Should validation and reputation data be stored on-chain for smart contract composability?
This is an active debate in the community. Arguments for on-chain storage include:
- Enabling smart contracts to read validation responses and condition logic on them
- Decoupling validation from enforcement (validators focus on validation, other protocols handle slashing)
- Supporting permissionless innovation by other developers
The current specification keeps data off-chain but emits events, though some suggest making on-chain storage optional.
🌐 How does domain validation work in the Identity Registry?
Currently, the ERC doesn't specify how to verify that an agent actually owns the domain they claim. This verification is left to users of the protocol. Future versions might include:
- Trusted party verification
- Consensus/verification mechanisms (e.g., zkTLS proofs)
- Allowing multiple agents to claim the same domain with disambiguation
🔗 Why does ERC-8004 require agents to use domains instead of URLs?
The current specification requires each agent to have its own domain/subdomain with AgentCard at the well-known location /.well-known/agent-card.json. This is stricter than the A2A spec, which allows URLs. Some community members suggest using URLs instead to allow multiple agents per domain.
📊 Should reputation be a single aggregate score or modular?
The community strongly favors modular approaches:
- ❌ Against single scores: Creates monopolistic behavior and oversimplifies trust relationships
- ✅ For modularity: Trust is context-dependent and varies between agent pairs
- 🎯 Preferred approach: Index and reference multiple reputation systems, allowing agents to choose relevant metrics
🤝 How should reputation providers work together?
Community suggestions include:
- Multiple providers (e.g., Virtuals, Creatorbid, Base) offering scores for agents
- (Agent, Provider) pairs in the registry for on-chain applications
- Reducing bias and collusion risk through multiple score sources
- Individual attestation history remaining standalone
🔄 Is trust universal between agents?
No. Trust is not a universal value but a vector from one agent to another. Alice's trust for Bob will differ from Charlie's trust for Bob, and Alice's trust varies by context/domain of interaction. This reinforces the need for modular, context-aware reputation systems.
💳 How does ERC-8004 handle payments between agents?
ERC-8004 deliberately doesn't cover payments to remain unopinionated and avoid coupling trust/discovery with specific payment protocols. However:
- Payment proofs can be included as optional attributes in off-chain schemas
- The team is collaborating with groups working on A2A payment extensions based on x402
- Payment references should be lightweight hooks in Reputation records for correlation
🔄 What payment mechanisms are envisioned?
While payments are orthogonal to ERC-8004, the specification provides examples showing how x402 payment proofs can enrich feedback signals:
{
"proof_of_payment": {
"fromAddress": "0x00...",
"toAddress": "0x00...",
"chainId": "1",
"txHash": "0x00..."
}
}Other potential mechanisms include:
- Time locks and predetermined arbitration
- Staking by buyer or seller
- Escrow systems with crypto-economic guarantees
- Integration with A2A payment extensions based on x402
🎯 Should there be incentives for providing feedback or guaranteeing data availability?
This is mentioned as a possible future direction, including:
- Incentives to provide feedback
- Guarantees for off-chain data availability of feedback and validations
- Crypto-economic mechanisms for validator honesty
🔍 How do the two validation scenarios work?
- Crypto-economic scenario: DataHash commits to job re-execution info; AgentValidator can be trusted agents, committees, or stake-secured services
- Crypto-verification scenario: DataHash commits to TEE attestation/zkTLS proof info; AgentValidator is a verifier smart contract checking proofs on-chain
🔗 What's the relationship between ERC-8004 and other agent standards?
- ERC-8001: Focuses on agent-to-agent coordination and consensus (orthogonal to ERC-8004)
- EAS: Referenced for on-chain attestations
- RFC 7071 (Reputons): Standard for reputation interchange, relevant for reputation systems
🏛️ Will there be a single registry per chain or multiple registries?
The goal is to have one singleton Identity Registry per chain to prevent proliferation of slightly different registries.
💰 Should registration be free or require deposits?
This implementation detail isn't specified in the current ERC but is under discussion for future versions.
📋 How detailed are the smart contract interfaces?
The current ERC provides function names and parameters but lacks detailed Solidity interfaces. Future versions will include more precise type specifications and complete interface definitions.
🌉 What about cross-chain support?
Cross-chain identifiers are mentioned as a possible future direction, along with:
- NFT interfaces for agent minting, ownership, and transfer
- ENS support
- Integrations with A2A payment extensions
🔌 How does ERC-8004 integrate with existing projects?
Several projects are already building compatible systems:
- Ensemble Framework: Building trustless layer for agent collaboration
- CoopHive Alkahest: Smart contracts for peer-to-peer escrowed exchange
- Various reputation and validation service providers
🏗️ What standards does ERC-8004 build upon?
Key standards include:
- CAIP-10: Chain-agnostic account identification
- RFC 8615: Well-Known URIs specification
- A2A Protocol: Base agent-to-agent communication
- EAS: Ethereum Attestation Service patterns
We welcome contributions to this awesome list!
- 🔧 Implementations of ERC-8004
- 🛠️ Tools and libraries for developers
- 📚 Documentation and tutorials
- 🔬 Research papers and academic work
- 🚀 Community projects using ERC-8004
- 💬 Discussion summaries and insights
- Check the issues for ongoing discussions
- Fork this repository
- Add your resource to the appropriate section
- Submit a pull request with a clear description
- Follow the Awesome List Guidelines
📖 See Contributing Guidelines for detailed instructions.
- Marco De Rossi @marco_derossi (MetaMask)
- Davide Crapis @dcrapis (Ethereum Foundation)
- Jordan Ellis (Google)
- Erik Reppel (Coinbase)
- Ethereum Foundation's dAI team - Core protocol development and research
- Consensys - Implementation and ecosystem development
- Builder Community - Active development and technical feedback
And to all the community members providing feedback and technical contributions to the ecosystem.
