Skip to content

README.md

Latest commit

 

History

History
997 lines (707 loc) · 53.8 KB

README.md

File metadata and controls

997 lines (707 loc) · 53.8 KB
ERC-8004 Logo

Awesome ERC-8004

A curated list of awesome resources for ERC-8004: Trustless Agents

Table of Contents

What is ERC-8004?

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. It introduces three lightweight, on-chain registries:

Core Components

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

Key Properties

  • Cross-organizational Discovery - Agents can be found 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 Efficiency - Off-chain data storage with on-chain integrity
  • ERC-721 Compatibility - Full compatibility for NFT marketplace integration

Trust Models

  1. Reputation-based - Client feedback using signed fixed-point values, tags, and metadata
  2. Crypto-economic - Stake-secured validation with economic incentives
  3. Crypto-verification - TEE attestations and zkML proofs for cryptographic trust

Official Resources

Specification

Current Status

  • Status: Draft (EIP process), contracts are audited and final
  • Registries: Identity and Reputation final contracts deployed; Validation Registry under active revision
  • Specification: ERC8004SPEC.md in the contracts repository

Architecture Overview

┌─────────────────┐
│ Agent           │
│ Discovery       │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│ Identity        │
│ Registry        │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│ Agent           │
│ Registration    │
└────┬───────┬────┘
     │       │
     ▼       ▼
┌─────────┐ ┌─────────────┐
│ Rep.    │ │ Validation  │
│ Registry│ │ Registry    │
└────┬────┘ └──────┬──────┘
     │             │
     └──────┬──────┘
            ▼
    ┌─────────────────┐
    │ Trust           │
    │ Assessment      │
    └────────┬────────┘
             │
             ▼
    ┌─────────────────┐
    │ Agent           │
    │ Interaction     │
    └─────────────────┘

Agent Registration Schema

{
  "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",
  "services": [
    {
      "name": "web",
      "endpoint": "https://web.agentxyz.com/"
    },
    {
      "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"
    },
    {
      "name": "OASF",
      "endpoint": "ipfs://{cid}",
      "version": "0.8",
      "skills": [],
      "domains": []
    },
    {
      "name": "ENS",
      "endpoint": "agent.eth",
      "version": "v1"
    },
    {
      "name": "DID",
      "endpoint": "did:method:foobar",
      "version": "v1"
    },
    {
      "name": "email",
      "endpoint": "mail@myagent.com"
    }
  ],
  "x402Support": false,
  "active": true,
  "registrations": [
    {
      "agentId": 22,
      "agentRegistry": "{namespace}:{chainId}:{identityRegistry}"
    }
  ],
  "supportedTrust": ["reputation", "crypto-economic", "tee-attestation"]
}

The type, name, description, and image fields ensure compatibility with ERC-721 apps. The services list is fully customizable. The supportedTrust field is optional; if absent, the registration is used for discovery only.

Community Calls & Content

Recorded Sessions

Events & Conferences

Builder Projects

Infrastructure & SDKs

UFX Agentic Commerce

  • ERC-8183 Hook & Reputation Middleware - First IACPHook implementations and ERC-8004 reputation bridge for ERC-8183 (Agentic Commerce Protocol). Includes ReputationHook (auto-writes job outcomes to ReputationRegistry), ReputationGateHook (reputation-based funding gate), SLAHook (deadline enforcement), AI evaluators, and Python SDK. 208 Solidity tests (incl. 9 fuzz). Live on Base Mainnet with Iamalive Agent #1734. MIT licensed.

Automata Network

Praxis Protocol

Ch40s Chain

Vistara Labs

Collaboration Frameworks

Commerce & Escrow

UFX Agentic Commerce — First IACPHook implementations and ERC-8004 reputation bridge for ERC-8183 (Agentic Commerce Protocol). The EIP defines hooks; we built and deployed them.

Azeth

Trust infrastructure for the machine economy. TypeScript SDK suite providing ERC-8004 identity registration, weighted reputation with Sybil-resistant opinions, capability-based service discovery, and x402 payment settlement with automatic reputation feedback. Agents get non-custodial ERC-4337 smart accounts with guardian-enforced guardrails. Deployed on Base Sepolia and Ethereum Sepolia with deterministic CREATE2 addresses.

Verification & Identity

ORIGIN Protocol — Proof of Agency: Cognitive verification for AI agents

  • ORIGIN Registry (Base Mainnet) - ERC-8004 compatible soulbound Birth Certificate registry
  • ERC-8004 Adapter (Base Mainnet) - Adds getMetadata/setMetadata, agent wallets, services array
  • @origin-dao/sdk - 3 lines of code to verify any agent
  • Proof of Agency Gauntlet - 5-challenge verification: adversarial resistance, chain reasoning, memory proof, code generation, philosophical flex
  • Soulbound Birth Certificates with on-chain reputation (trust levels 0→2)
  • CLAMS governance token with staking rewards and fee splitting
  • Genesis Mode: First 100 agents earn founding status
  • First agent verified March 4, 2026 — Score: 89/100

M2M TRC-8004 Registry

  • Smart Contracts (Solidity) - ERC-8004 implementation on TRON with 4 registries: Identity, Reputation, Validation, and Incident. Live on mainnet and Shasta testnet.
  • Python SDK - pip install trc8004-m2m — Async Python SDK with TronClient, RegistryAPI, and IPFS integration
  • Backend API - FastAPI service with event indexing, full-text search, and PostgreSQL. 332 unit tests, 97.9% coverage.

Ensemble Framework

ISEK

Payment Infrastructure

Primev

Security & Verification

AsterPay

  • AsterPay EUR Settlement - EUR settlement infrastructure for x402 payments. USDC→EUR via SEPA Instant for EU/EEA businesses with MiCA compliance. Registered as Agent #16850 on the Identity Registry. Python SDK available (pip install asterpay).

Phala Network

Sparsity

Identity & Trust

Agent Services (x402 + ERC-8004)

xbird

  • xbird MCP Server - Twitter/X API with 30 tools (read, search, post, engage, media upload) using x402 micropayments on Base
  • Agent Card - ERC-8004 compliant agent card with x402 endpoints
  • Registered on ERC-8004 Identity Registry on Base (0x8004A169FB4a3325136EB29fA0ceB6D2e539a432)

Mintware Attribution

"On-chain reputation scoring for AI agents and wallets across 100+ chains. EIP-712 gasless oracle — oracle signs off-chain, agent submits on-chain. Register once, score accumulates automatically. Registered as Agent #37297 on the Base Identity Registry."

8k4 Protocol

  • 8k4 API - Reputation infrastructure for ERC-8004 agents: trust scoring (IGGY-Score), metadata hosting, and cross-chain lookup. Public stats currently show 106,996 indexed agents across Base (33,939), BSC (44,020), and Ethereum (29,037), with x402 pay-per-query support (USDC on Base).

Helixa

  • Helixa - Onchain identity and reputation protocol for AI agents on Base. 1,000+ agents minted. Features an 11-factor Cred Score system (0-100) with five tiers (JUNK → PREFERRED), SIWA (Sign-In With Agent) authentication, $CRED token staking, and agent discovery via .well-known/ai-plugin.json. Contract: 0x2e3B541C59D38b84E3Bc54e977200230A204Fe60.
  • Helixa API - REST API for agent identity, Cred Scores, search, and staking. OpenAPI spec at /.well-known/openapi.json.
  • Helixa Agent Skill - Open-source agent skill with 13 shell scripts and reference docs for AI agents to interact with the protocol (mint, verify, query scores, stake).

Chitin

  • 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.

Applications & Demos

AgentStamp

  • AgentStamp - Trust intelligence platform for AI agents with ERC-8004 bridge — identity stamps, reputation scoring (0-100), forensic audit trails, and x402 micropayments. Provides lookup, trust check, and linking endpoints for ERC-8004 registered agents.
  • AgentStamp GitHub - Open-source Node.js server and SDK with MCP tools, HMAC signature verification, and admin audit endpoints

MolTrust

  • MolTrust - Swiss trust infrastructure for the AI agent economy. W3C DID-based identity, Ed25519 signed Verifiable Credentials anchored on Base mainnet. ERC-8004 registered (agentId #21023). 7 verticals including MT Salesguard for brand product provenance — BrandRegistryCredentials, AuthorizedResellerCredentials, and ProductProvenanceCredentials verifiable by any shopping agent before purchase.
  • MolTrust MCP Server - 30 MCP tools for agent identity, trust scoring, skill verification, and credential issuance (pip install moltrust-mcp-server)
  • @moltrust/x402 - Trust verification middleware for x402 payments (Hono + Express). Extracts wallet from X-PAYMENT header, verifies via MoltGuard trust scoring.

DJD Agent Score

  • DJD Agent Score - Reputation API for the agent economy on Base L2. Returns a 0-100 behavioral trust score for any wallet, combining 7 scoring dimensions (transaction history, partner diversity, volume patterns, account age, balance stability, activity consistency, USDC usage) with sybil detection and gaming velocity checks. Scores feed directly into the ERC-8004 Reputation Registry as off-chain attestations. Monetized via x402 micropayments on Base USDC.
  • djd-agent-score-client - TypeScript SDK for querying wallet reputation scores (npm i djd-agent-score-client)
  • x402-agent-score - Hono middleware to gate outbound agent payments by counterparty reputation score
  • DJD Agent Score GitHub - Open source scoring engine. TypeScript, Hono 4, SQLite, 298 tests.

InsumerAPI — On-chain credential verification across 33 blockchains

  • InsumerAPI - REST API that verifies wallet conditions (token balances, NFT ownership, EAS attestations, Farcaster identity) across 30 EVM chains, Solana, XRPL, and Bitcoin. Returns ECDSA P-256 signed booleans — never raw balances. Used by DJD Agent Score and AsterPay KYA as a verification data source for agent trust scoring. Free tier available.
  • insumer-verify - Zero-dependency verification library. Auto-detects JWT or raw attestation, verifies ES256 signature via JWKS (npm i insumer-verify)
  • mcp-server-insumer - MCP server with 26 tools for wallet verification, trust profiling, and attestation
  • JWKS endpoint - Public key discovery for offline signature verification (ES256, kid insumer-attest-v1)
  • OpenAPI spec - Full API specification

AgentStore - Open-source marketplace for AI agents using ERC-8004 identity and x402 payments for trustless agent discovery and USDC settlement.

Obol - x402-gated AI code generation API. Describe what you want, Obol generates production-ready code and opens a GitHub PR. 7 endpoints ($5 USDC/call on Base): site cloning, Farcaster mini apps, APIs, tests, docs, CI/CD, and refactoring. Registered as Agent #26522 on the Base Identity Registry.

  • Obol API - Cloudflare Worker serving 7 x402-gated endpoints at api.obol.sh
  • Agent Card - A2A-compatible agent descriptor

Cotten IO (Scypted)

Theagora - AI agent exchange with atomic escrow, 4-tier cryptographic verification, per-function reputation, and ERC-8004 agent identity integration. Agents link on-chain ERC-8004 identities to their Theagora accounts for verified commerce.

  • Theagora MCP Server - MCP server with 27 tools for agent registration, function listing, order placement, escrow settlement, and reputation queries (npm i @theagora/mcp)

Community Projects

Educational Resources

Discussions & Forums

Official Channels

Community Groups

Explorer & Scanner Tools

Tools for browsing and querying on-chain ERC-8004 registries.

  • 8004scan.io - Primary explorer built by AltLayer; tracks registered agents, feedback records, and cross-chain activity (iOS and Android apps available)
  • agentscan.info - On-chain agent explorer with registry lookup
  • 8004agents.ai - Agent discovery interface
  • trust8004.xyz - Agent discovery and management tool

Research & Papers

Academic papers and research related to ERC-8004 and trustless agents.

Agent Identity & Trust

  • AI Agents with Decentralized Identifiers and Verifiable Credentials (Nov 2025) - Proposes equipping each AI agent with a self-controlled DID and Verifiable Credentials for trust establishment in agent-to-agent dialogue. Directly addresses the identity bootstrapping problem that ERC-8004's Identity Registry tackles on-chain.

  • A Novel Zero-Trust Identity Framework for Agentic AI (May 2025) - Argues that traditional IAM is fundamentally inadequate for AI agents and proposes rich, verifiable Agent Identities using DIDs and VCs that encode capabilities, provenance, behavioral scope, and security posture.

  • Binding Agent ID: Unleashing the Power of AI Agents with Identity (Dec 2025) - Explores binding unique identifiers to agentic AI instances for runtime attribution and accountability. Relevant to ERC-8004's on-chain identity binding model.

  • Trusted AI Agents in the Cloud (Dec 2025) - Establishes that cross-principal trust requires compositional, verifiable identity reflecting the code, model, and dependencies involved in each invocation. Complements ERC-8004's validation registry approach.

Security & Governance

  • A Survey of Agentic AI and Cybersecurity (Jan 2026) - Comprehensive survey covering BlockA2A (securing A2A communication using decentralized identity and blockchain-anchored audit logs), agent hijacking, and supply chain attacks. Essential context for why ERC-8004's trust layer matters.

  • Sovereign Agents (Feb 2026) - Introduces "agentic sovereignty" — the capacity of an agent to persist, act, and control resources with non-overrideability inherited from infrastructure. Analyzes TEEs, DePIN, and agent key continuity protocols. Raises the accountability question for agents that become non-terminable.

  • Practices for Governing Agentic AI Systems (OpenAI) - Framework for governing autonomous AI systems, addressing delegation chains, oversight mechanisms, and accountability structures.

Policy & Frameworks

Industry Reports

  • Securing Autonomous AI Agents (Strata Identity & Cloud Security Alliance, Feb 2026) - Survey finding only 23% of organizations have formal agent identity management strategies, 45.6% still use shared API keys for agent authentication, and only 21.9% treat agents as independent identity-bearing entities.

Development Resources

Getting Started

  1. EIP-8004 Specification
  2. ERC-8004 Contracts Repository
  3. Best Practices Guide
  4. Telegram Community

Contract Deployments

Official Implementation: erc-8004/erc-8004-contracts

The contracts are deployed as per-chain singletons. The Identity Registry uses vanity address 0x8004A169... on mainnets and 0x8004A818... on testnets. Complete deployment addresses for all networks are maintained in the contracts repository.

Security Audits: The contracts have been audited by Cyfrin, Nethermind, and the Ethereum Foundation Security Team.

Mainnet Deployments

Network Identity Registry Reputation Registry
Ethereum 0x8004A169...432 0x8004BAa1...b63
Base 0x8004A169...432 0x8004BAa1...b63
Arbitrum 0x8004A169...432 0x8004BAa1...b63
Optimism 0x8004A169...432 0x8004BAa1...b63
Polygon 0x8004A169...432 0x8004BAa1...b63
Linea 0x8004A169...432 0x8004BAa1...b63
Scroll 0x8004A169...432 0x8004BAa1...b63
Avalanche 0x8004A169...432 0x8004BAa1...b63
BNB Chain 0x8004A169...432 0x8004BAa1...b63
Celo 0x8004A169...432 0x8004BAa1...b63
Gnosis 0x8004A169...432 0x8004BAa1...b63
Monad 0x8004A169...432 0x8004BAa1...b63
Abstract 0x8004A169...432 0x8004BAa1...b63
Mantle 0x8004A169...432 0x8004BAa1...b63
Soneium 0x8004A169...432 0x8004BAa1...b63
Taiko 0x8004A169...432 0x8004BAa1...b63

See the contracts repository for the full list including SKALE, GOAT Network, MegaETH, Metis, XLayer, and all testnet addresses (Hedera, Arc).

SDKs and Libraries

JavaScript/TypeScript

  • Agent0 SDK - TypeScript and Python SDK with subgraph queries and an interactive playground; developed by Agent0 Lab
  • create-8004-agent - CLI scaffolding package (npx create-8004-agent) for bootstrapping ERC-8004 agents
  • Lucid Agents / Daydreams - Agent framework with built-in ERC-8004 integration
  • ChaosChain SDK - Full-featured JavaScript/TypeScript SDK
  • erc-8004-js - Lightweight JavaScript library
  • Azeth SDK (@azeth/sdk) - Full-stack TypeScript SDK for ERC-8004 identity, reputation, discovery, and x402 payments

Python

  • Agent0 SDK - Python support included alongside TypeScript
  • erc-8004-py - Python implementation
  • chaoschain-sdk - Available on PyPI
  • agentwallet-sdk - Non-custodial TypeScript SDK for AI agents: ERC-8004 identity, x402 payments, CCTP cross-chain transfers, Uniswap V3 swaps. First ERC-8004 implementation on npm with 158 tests.
  • trc8004-m2m - TRC-8004 Python SDK for TRON (async, Pydantic models)

Infrastructure & Data

Smart Contract Interfaces

Identity Registry (ERC-721 Compatible)

Agents are identified globally by:

  • agentRegistry: {namespace}:{chainId}:{identityRegistry} (e.g., eip155:1:0x8004A169FB4a3325136EB29fA0ceB6D2e539a432)
  • agentId: the ERC-721 tokenId assigned incrementally by the registry
// Register a new agent (three overloads)
function register(string agentURI, MetadataEntry[] calldata metadata) external returns (uint256 agentId)
function register(string agentURI) external returns (uint256 agentId)
function register() external returns (uint256 agentId)

// Update agent URI
function setAgentURI(uint256 agentId, string calldata newURI) external

// Optional on-chain metadata
function getMetadata(uint256 agentId, string memory metadataKey) external view returns (bytes memory)
function setMetadata(uint256 agentId, string memory metadataKey, bytes memory metadataValue) external

// Agent wallet (reserved metadata key, requires EIP-712 or ERC-1271 proof)
function setAgentWallet(uint256 agentId, address newWallet, uint256 deadline, bytes calldata signature) external
function getAgentWallet(uint256 agentId) external view returns (address)
function unsetAgentWallet(uint256 agentId) external

Reputation Registry

Feedback is stored as a signed fixed-point value (int128 + uint8 decimals), enabling a wide range of metrics (quality scores, uptime percentages, response times, revenues, etc.).

// Submit feedback for an agent (caller must not be owner or operator of agentId)
function giveFeedback(
    uint256 agentId,
    int128 value,
    uint8 valueDecimals,
    string calldata tag1,
    string calldata tag2,
    string calldata endpoint,
    string calldata feedbackURI,
    bytes32 feedbackHash
) external

// Revoke previously given feedback
function revokeFeedback(uint256 agentId, uint64 feedbackIndex) external

// Append a response to received feedback (anyone may call)
function appendResponse(
    uint256 agentId,
    address clientAddress,
    uint64 feedbackIndex,
    string calldata responseURI,
    bytes32 responseHash
) external

// Read a specific feedback entry
function readFeedback(
    uint256 agentId,
    address clientAddress,
    uint64 feedbackIndex
) external view returns (int128 value, uint8 valueDecimals, string memory tag1, string memory tag2, bool isRevoked)

// Read all feedback for an agent
function readAllFeedback(
    uint256 agentId,
    address[] calldata clientAddresses,
    string calldata tag1,
    string calldata tag2,
    bool includeRevoked
) external view returns (
    address[] memory clients,
    uint64[] memory feedbackIndexes,
    int128[] memory values,
    uint8[] memory valueDecimals,
    string[] memory tag1s,
    string[] memory tag2s,
    bool[] memory revokedStatuses
)

// Count responses appended to a feedback entry
function getResponseCount(
    uint256 agentId,
    address clientAddress,
    uint64 feedbackIndex,
    address[] calldata responders
) external view returns (uint64 count)

// Aggregated summary
function getSummary(
    uint256 agentId,
    address[] calldata clientAddresses,
    string calldata tag1,
    string calldata tag2
) external view returns (uint64 count, int128 summaryValue, uint8 summaryValueDecimals)

// Enumerate clients and feedback indexes
function getClients(uint256 agentId) external view returns (address[] memory)
function getLastIndex(uint256 agentId, address clientAddress) external view returns (uint64)

Validation Registry

// Request validation (must be called by the owner or operator of agentId)
function validationRequest(
    address validatorAddress,
    uint256 agentId,
    string calldata requestURI,
    bytes32 requestHash
) external

// Provide validation response (must be called by the validatorAddress from the request)
function validationResponse(
    bytes32 requestHash,
    uint8 response,
    string calldata responseURI,
    bytes32 responseHash,
    string calldata tag
) external

// Query a specific validation record
function getValidationStatus(
    bytes32 requestHash
) external view returns (
    address validatorAddress,
    uint256 agentId,
    uint8 response,
    bytes32 responseHash,
    string memory tag,
    uint256 lastUpdate
)

// Aggregated validation statistics (agentId mandatory; validatorAddresses and tag are optional filters)
function getSummary(
    uint256 agentId,
    address[] calldata validatorAddresses,
    string calldata tag
) external view returns (uint64 count, uint8 averageResponse)

// List all validation request hashes for an agent or validator
function getAgentValidations(uint256 agentId) external view returns (bytes32[] memory requestHashes)
function getValidatorRequests(address validatorAddress) external view returns (bytes32[] memory requestHashes)

Standards & References

Core Standards

  • 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)

Related Services

Related Standards

Ethereum Ecosystem

  • ERC-8001 - Agent-to-Agent coordination (mentioned in discussions)
  • EAS - Ethereum Attestation Service for on-chain attestations

Cross-Chain and Alternative Implementations

Hashgraph Online (HOL) — Trust engine for the agentic internet

Universal agentic registry built on Hedera Hashgraph. Provides blockchain-based identity for AI agents using ERC-8004 standard and HCS-14 Universal Agent IDs (UAIDs). Enables agent discovery, verification, and autonomous commerce via x402 protocol.

TRON Implementation: M2M-TRC8004-Registry

The TRC-8004 implementation on TRON is deployed on both mainnet and Shasta testnet with four registries (Identity, Reputation, Validation, Incident). See m2mregistry.io for details.

External Protocols

FAQ

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:

  1. Identity Registry - Minimal on-chain handle that resolves to an agent's off-chain AgentCard
  2. Reputation Registry - Standard interface for posting and fetching attestations
  3. 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)

Specification Status

What is the current status of the ERC-8004 specification?

ERC-8004 is currently in Draft status in the EIP process. The final audited contracts for Identity and Reputation registries are deployed on Ethereum mainnet and 20+ networks. The Validation Registry is under active revision with the TEE community.

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 using signed fixed-point values (int128 + uint8 decimals) 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

Technical Implementation

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.

Reputation and Trust

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.

Payment and Economics

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

Validation and Verification

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

Implementation and Development

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

Integration and Ecosystem

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

Contributing

We welcome contributions to this awesome list!

What to Contribute

  • 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

How to Contribute

  1. Check the issues for ongoing discussions
  2. Fork this repository
  3. Add your resource to the appropriate section
  4. Submit a pull request with a clear description
  5. Follow the Awesome List Guidelines

See Contributing Guidelines for detailed instructions.

Acknowledgments

Core Authors & Contributors

  • Marco De Rossi @marco_derossi (MetaMask)
  • Davide Crapis @dcrapis (Ethereum Foundation)
  • Jordan Ellis (Google)
  • Erik Reppel (Coinbase)

Contributing Organizations

  • Ethereum Foundation's dAI team - Core protocol development and research
  • Consensys - Implementation and ecosystem development
  • Builder Community - Active development and technical feedback

🌟 Community

And to all the community members providing feedback and technical contributions to the ecosystem.

📄 License

CC0

To the extent possible under law, the contributors have waived all copyright and related or neighboring rights to this work.

Made with ❤️ by the ERC-8004 community