---

🎯 The Big Picture: What Are These Standards?

EIP-8004 and ERC-8041 work together to create a complete ecosystem for AI agents on Ethereum:

• EIP-8004 (Trustless Agents) = The foundation - an unlimited, open registry where ANY AI agent can get a unique on-chain identity

• ERC-8041 (Fixed-Supply Agent NFT Collections) = The extension - allows creation of limited-edition, curated collections of those agents

Think of it like this: EIP-8004 is like getting a social security number (anyone can get one), while ERC-8041 is like being part of an exclusive club with limited membership.

---

📋 EIP-8004: Trustless Agents - The Foundation

Core Metadata

What Problem Does It Solve?

EIP-8004 addresses a critical gap in the AI agent ecosystem: How do you discover, trust, and interact with AI agents across different organizations without pre-existing relationships?

Current protocols like MCP (Model Context Protocol) and A2A (Agent-to-Agent) handle communication, but they don't solve:

• Discovery: How do you find agents?

• Identity: How do you verify an agent's identity?

• Trust: How do you know an agent will perform as promised?

The Three-Registry Architecture

EIP-8004 introduces three interconnected registries:

1. Identity Registry (ERC-721 Based)

This is the core registry where every agent gets a unique, globally-identifiable token.

Global Agent Identifier Format:

plaintext

eip155:{chainId}:{identityRegistry}:{agentId}

Example: eip155:1:0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb7:42

Key Functions:

// Register a new agent
function register(string tokenURI, MetadataEntry[] calldata metadata) 
    returns (uint256 agentId);

// Set on-chain metadata
function setMetadata(uint256 agentId, string key, bytes value);

// Get on-chain metadata
function getMetadata(uint256 agentId, string key) 
    returns (bytes value);

Agent Registration File Structure:

{
  "type": "https://eips.ethereum.org/EIPS/eip-8004#registration-v1",
  "name": "myAgentName",
  "description": "What the agent does, pricing, etc.",
  "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",

2. Reputation Registry (Trust Through Feedback)

This registry allows clients to leave feedback about their experiences with agents, creating a decentralized reputation system.

The Feedback Flow:

1. Agent authorizes feedback by signing a feedbackAuth when accepting a task

2. Client gives feedback after task completion

3. Feedback is permanently recorded on-chain with optional off-chain details

Core Function:

function giveFeedback(
    uint256 agentId,
    uint8 score,           // 0-100
    bytes32 tag1,          // e.g., "skill-type"
    bytes32 tag2,          // e.g., "task-category"
    string calldata fileuri,
    bytes32 calldata filehash,
    bytes memory feedbackAuth
) external;

Events:

event NewFeedback(
    uint256 indexed agentId,
    address indexed clientAddress,
    uint8 score,
    bytes32 indexed tag1,
    bytes32 tag2,
    string fileuri,
    bytes32 filehash
);

Off-Chain Feedback File Example:

{
  "agentRegistry": "eip155:1:{identityRegistry}",
  "agentId": 22,
  "clientAddress": "eip155:1:{clientAddress}",
  "score": 100,
  "tag1": "data-analysis",
  "tag2": "financial",
  "skill": "as-defined-by-A2A",
  "proof_of_payment": {
    "fromAddress": "0x00...",
    "toAddress": "0x00...",
    "chainId": "1",
    "txHash": "0x00..."
  }
}

Read Functions:

// Get summary statistics
function getSummary(
    uint256 agentId,
    address[] calldata clientAddresses,
    bytes32 tag1,
    bytes32 tag2
) external view returns (uint64 count, uint8 averageScore);

// Read all feedback with filters
function readAllFeedback(
    uint256 agentId,
    address[] calldata clientAddresses,
    bytes32 tag1,
    bytes32 tag2,
    bool includeRevoked
) external view returns (
    address[] memory clientAddresses,
    uint8[] memory scores,
    bytes32[] memory tag1s,
    bytes32[] memory tag2s,

3. Validation Registry (Cryptographic Verification)

For high-stakes tasks, reputation isn't enough. The Validation Registry enables agents to request independent verification of their work through:

• Staked re-execution (validators re-run the task and stake on the result)

• zkML proofs (zero-knowledge machine learning verification)

• TEE attestations (Trusted Execution Environment proofs)

Request Validation:

function validationRequest(
    address validatorAddress,
    uint256 agentId,
    string requestUri,
    bytes32 requestHash
) external;

Validator Response:

function validationResponse(
    bytes32 requestHash,
    uint8 response,        // 0-100 score
    string responseUri,
    bytes32 responseHash,
    bytes32 tag
) external;

Trust Models: Tiered Security

EIP-8004 supports pluggable trust models with security proportional to value at risk:

Security Considerations

• Spam/Sybil attacks: Only partially mitigated; relies on ecosystem reputation systems

• Audit trail: On-chain pointers and hashes ensure integrity

• No cryptographic guarantee: The protocol can't guarantee advertised capabilities are real - trust models address this

---

🎨 ERC-8041: Fixed-Supply Agent NFT Collections

Core Metadata

What Problem Does It Solve?

While EIP-8004 provides unlimited agent registration, many use cases require:

1. Fixed-supply collections - Limited editions (e.g., "Genesis 100", "Season 1")

2. Collection metadata - Associate agents with specific collections

3. Mint number tracking - Permanent record of position (#5 of 1000)

4. Time-gated releases - Collections that activate at specific blocks

5. Curated drops - Controlled minting vs. open registration

Collection Structure

Every ERC-8041 collection MUST maintain:

uint256 maxSupply;      // Maximum agents in collection
uint256 currentSupply;  // Current number minted
uint256 startBlock;     // When minting becomes available
bool open;              // Currently accepting mints?

Core Interface

interface IERC8041Collection {
    // Events
    event CollectionCreated(uint256 maxSupply, uint256 startBlock);
    event AgentMinted(
        uint256 indexed agentId,
        uint256 mintNumber,
        address indexed owner
    );

    // Get agent's position in collection (0 if not in collection)
    function getAgentMintNumber(uint256 agentId) 
        external view returns (uint256 mintNumber);

    // Get collection details
    function getCollectionDetails() external view returns (
        uint256 maxSupply,
        uint256 currentSupply,
        uint256 startBlock,
        bool open
    );

The Critical Link: Collection Metadata

When an agent is minted through an ERC-8041 collection, the collection contract writes metadata to the agent's EIP-8004 token using the key "agent-collection":

Metadata Format:

abi.encodePacked(
    address collectionAddress,  // 20 bytes: collection contract
    uint8 mintNumberLength,     // 1 byte: length of mint number
    bytes mintNumberBytes       // variable: the mint number
)

Example Implementation:

function mint(uint256 agentId) external {
    require(currentSupply < maxSupply, "Supply exceeded");
    require(agentRegistry.ownerOf(agentId) == msg.sender, "Not owner");
    require(_agentMintNumber[agentId] == 0, "Already in collection");

    currentSupply++;
    uint256 mintNumber = currentSupply;
    _agentMintNumber[agentId] = mintNumber;

    // Encode and store collection metadata
    bytes memory mintNumberBytes = abi.encode(mintNumber);
    uint8 mintNumberLength = uint8(mintNumberBytes.length);
    bytes memory collectionMetadata = abi.encodePacked(
        address(this),
        mintNumberLength,
        mintNumberBytes
    );

    // Write to EIP-8004 registry
    IOnchainMetadata(address(agentRegistry)).setMetadataByContract(

🔒 Critical Security Consideration

The agent owner can modify or remove the "agent-collection" metadata at any time!

Therefore, clients MUST:

1. ✅ Query the collection contract directly using getAgentMintNumber(agentId) for verification

2. ✅ Use metadata only as a convenience lookup to discover which collection to query

3. ✅ Treat mintNumber == 0 from the collection contract as definitive proof the agent is NOT in the collection

Never trust the metadata alone!

---

🔗 How They Work Together: The Complete Flow

Scenario: Gaming Company Launches AI Character Collection

Step 1: Deploy EIP-8004 Registry (One-time, per chain)

// Deployed once as a singleton on the chain
IdentityRegistry registry = new IdentityRegistry();

Step 2: Deploy ERC-8041 Collection Contract

// Gaming company creates "Season 1 Heroes" collection
ERC8041Collection season1 = new ERC8041Collection(
    registry,        // EIP-8004 registry address
    10000           // maxSupply: 10,000 heroes
);

Step 3: User Mints a Character

// User calls the collection contract
season1.mint(agentId);

// Behind the scenes:
// 1. Agent is registered in EIP-8004 registry (if not already)
// 2. Mint number is assigned (e.g., #42)
// 3. Collection metadata is written to agent's EIP-8004 token
// 4. AgentMinted event is emitted

Step 4: Verification Flow

// Client wants to verify agent #123 is in Season 1 collection

// Step 4a: Read metadata from EIP-8004 (convenience lookup)
bytes memory metadata = registry.getMetadata(123, "agent-collection");
address collectionAddr = address(bytes20(metadata[0:20]));

// Step 4b: Verify with collection contract (definitive proof)
uint256 mintNumber = season1.getAgentMintNumber(123);
// Returns: 42 (agent is #42 of 10,000)
// If returns 0, agent is NOT in this collection

---

💡 Key Concepts

1. Unlimited vs. Fixed Supply

• EIP-8004: Open, permissionless, unlimited minting - anyone can register

• ERC-8041: Curated, limited supply - controlled by collection creator

2. Identity vs. Collection

• EIP-8004: Provides the identity layer (the "passport")

• ERC-8041: Provides the collection layer (the "exclusive club membership")

3. Trust Hierarchy

Low Stakes → Reputation only
     ↓
Medium Stakes → Reputation + Validation sampling
     ↓
High Stakes → zkML proofs or TEE attestation

4. Metadata vs. Contract Truth

• Metadata = Convenience (can be changed by owner)

• Contract query = Truth (immutable record)

---

🛠️ Practical Use Cases

EIP-8004 Standalone

• DeFi Protocol Agent: Single AI agent managing a protocol, building reputation over time

• Personal AI Assistant: Your own AI with portable identity across platforms

• Research Agent: Academic AI building credibility through validated outputs

ERC-8041 + EIP-8004

• Gaming: 10,000 unique AI-powered NPCs with provenance

• Art: Limited edition AI artists (e.g., "Genesis 100 AI Creators")

• Professional Services: Curated collection of verified medical/legal AI agents

• Seasonal Drops: "Q1 2025 Trading Bots" - limited to 500

---

📊 Technical Comparison

---

🎓 Master-Level Insights

1. Gas Optimization Strategy

EIP-8004 is designed for EIP-7702 compatibility, allowing applications to sponsor gas for frictionless feedback submission. This is crucial for adoption.

2. Indexing & Discovery

Both standards are designed for easy indexing:

• On-chain events provide complete audit trail

• IPFS usage enables decentralized storage

• Subgraph-friendly architecture

3. Cross-Chain Agents

Agents can operate across multiple chains while maintaining a single identity:

"registrations": [
  {"agentId": 22, "agentRegistry": "eip155:1:{registry}"},
  {"agentId": 45, "agentRegistry": "eip155:137:{registry}"}
]

4. Composability

The three-registry architecture is intentionally modular:

• Use Identity only for basic discovery

• Add Reputation for trust signals

• Add Validation for high-stakes verification

Medical Record Verification System

🎯 System Overview

A blockchain-based medical record verification system that combines EIP-8004 (agent identity & trust), ERC-8041 (certified medical agent collections), and HTTP 402 (payment-required protocol) to create a secure, auditable healthcare AI ecosystem.

---

📋 Core Components

1. EIP-8004: Agent Identity & Trust Infrastructure

• Identity Registry: Each medical AI gets unique on-chain identity (ERC-721)

• Reputation Registry: Doctors submit feedback after using agents

• Validation Registry: TEE attestations prove secure execution

2. ERC-8041: Certified Medical Agent Collections

• Government/hospital creates limited collection (e.g., "FDA-Cleared Diagnostic Agents")

• Only 100 certified agents allowed

• Each agent gets mint number (#1 of 100) for provenance

• Collection metadata proves certification

3. HTTP 402: Payment Protocol

• Agent returns 402 Payment Required before service

• Client pays on-chain (e.g., 50 USDC)

• Payment proof included in feedback

• Creates economic accountability