Abstract

This article translates and analyzes the ERC-8004: Trustless Agents proposal (draft version), which adds a “trust layer” on top of the existing Agent-to-Agent (A2A Protocol), enabling participants to discover, select, and interact with agents in cross-organizational contexts without pre-existing trust.

It introduces three lightweight and on-chain registries: Identity, Reputation, and Validation; while delegating application-level logic details to off-chain components.

Original Proposal: ERC-8004 on EIPs

Motivation

The existing A2A Protocol already covers agent authentication, skill announcement via AgentCard, direct messaging, and complete task lifecycle collaboration. Its adoption by major tech companies demonstrates clear market demand.

However, the protocol currently operates mostly within organizational boundaries and assumes trust exists between Server Agent and Client Agent.

To facilitate an open, cross-organizational agent economy, we need mechanisms to discover and establish trust in trustless environments.

Core Architecture: Three-Layer Registry

This ERC addresses this need with three core components (deployable on any L2 or Mainnet):

graph TB subgraph "ERC-8004 Trustless Agents Architecture" A[Agent] --> IR[Identity Registry] A --> RR[Reputation Registry] A --> VR[Validation Registry] IR --> |Register| ID[AgentID + AgentDomain + AgentAddress] ID --> |Resolve| AC[AgentCard
off-chain] RR --> |Authorize| FB[Feedback Authorization] FB --> |Feedback| OC1[Off-chain Attestations] VR --> |Request| VReq[Validation Request] VReq --> |Validate| Validator{Validator Agent} Validator --> |crypto-economic| CE[Re-run Task Verification] Validator --> |crypto-verifiable| CV[TEE/zkTLS Verification] Validator --> |Response| VResp[Validation Response] VResp --> OC2[Off-chain Evidence] end style IR fill:#e1f5ff style RR fill:#fff4e1 style VR fill:#f0e1ff

1. Identity Registry

A minimized on-chain handle that resolves to an agent’s off-chain AgentCard, providing portable, censorship-resistant identifiers.

Each agent is uniquely identified by three elements:

  • AgentID: An on-chain incrementing global identifier
  • AgentDomain: Per RFC 8615, its AgentCard must be located at https://{AgentDomain}/.well-known/agent-card.json
  • AgentAddress: An EVM-compatible address
graph TD subgraph "Identity Registry Operation Mechanism" Agent[Agent] --> |Register| New[New AgentDomain, AgentAddress] New --> |On-chain| ID[(AgentID
AgentDomain
AgentAddress)] ID --> |Query| Q1[Get AgentID] ID --> |Query| Q2[ResolveByDomain] ID --> |Query| Q3[ResolveByAddress] Q1 --> |Return| Info[Agent Information] Q2 --> |Return| Info Q3 --> |Return| Info Info --> |HTTP Resolve| AC["/.well-known/
agent-card.json"] AC --> |Off-chain Data| Card[AgentCard
- Skills
- Trust Models
- Endpoints] end style ID fill:#e1f5ff style AC fill:#fff4e1 style Card fill:#f0e1ff

Write Endpoints:

  • New(AgentDomain, AgentAddress) → AgentID
  • Update(AgentID, Optional NewAgentDomain, Optional NewAgentAddress) → Boolean

Public Queries:

  • Get(AgentID)
  • ResolveByDomain(AgentDomain)
  • ResolveByAddress(AgentAddress)

2. Reputation Registry

This registry provides a lightweight entry point for exchanging task feedback via off-chain attestations. To reduce on-chain costs, only essential data is stored on-chain.

Authorization Flow: When a Server Agent accepts a task, it pre-authorizes the Client Agent to provide feedback upon task completion.

Core Endpoints:

  • AcceptFeedback(AgentClientID, AgentServerID) → Triggers AuthFeedback event

Feedback Data Structure: Each Client Agent providing feedback must point to a JSON list via FeedbackDataURI in their Agent Card, with items containing:

  • FeedbackAuthID (CAIP-10 format)
  • Optional AgentSkillId, TaskId, contextId
  • Rating, ProofOfPayment, Data, etc.

3. Validation Registry

Provides two validation modes:

Crypto-economic Verification

  • DataHash commits all information needed to re-run the work (including inputs and outputs to validate)
  • AgentValidator can be a single centralized agent, threshold committee (k-of-n) smart contract, or staking-protected service

Crypto-verification

  • DataHash commits all information needed to produce TEE attestation or zkTLS
  • AgentValidator is an on-chain verification smart contract

Core Endpoints:

  • ValidationRequest(AgentValidatorID, AgentServerID, DataHash)
  • ValidationResponse(DataHash, Response)

Three Trust Models

Developers can choose from three trust models based on the risk level of the task:

graph LR subgraph "Trust Model Selection" Task[Task] --> Risk{Risk Level} Risk --> |Low Risk| T1[Reputation-based
Reputation Based] Risk --> |Medium Risk| T2[Stake-secured
Economic Stake] Risk --> |High Risk| T3[TEE Attestations
Verifiable Attestations] T1 --> U1[Food Ordering
Simple Query] T2 --> U2[General Business
Data Processing] T3 --> U3[Medical Diagnosis
Financial Transactions] T1 -.-> C1[Cost: Low
Speed: Fast] T2 -.-> C2[Cost: Medium
Guarantee: Economic Incentive] T3 -.-> C3[Cost: High
Guarantee: Cryptographic] end style T1 fill:#d4edda style T2 fill:#fff3cd style T3 fill:#f8d7da

1. Reputation-based

  • Use Case: Low-risk tasks (e.g., food ordering, simple queries)
  • Mechanism: Build reputation system based on customer feedback
  • Characteristics: Lightweight, fast, low cost

2. Stake-secured Inference Validation

  • Use Case: Medium-risk tasks
  • Mechanism: Validator stakes and re-runs task to verify results
  • Characteristics: Economic incentives guarantee validation quality

3. TEE Attestations

  • Use Case: High-risk tasks (e.g., medical diagnosis, financial transactions)
  • Mechanism: Uses TEE (Trusted Execution Environment) or zkTLS
  • Characteristics: Cryptographically guaranteed verifiability

Participant Roles

All participants must first register in the Identity Registry. Agents can have three roles:

  • Server Agent (A2A Server): Provides services and executes tasks
  • Client Agent (A2A Client): Assigns tasks and provides feedback
  • Validator Agent (Optional): Performs validation via staking or attestation

Agents can simultaneously play multiple roles without restrictions.

sequenceDiagram participant C as Client Agent participant IR as Identity Registry participant S as Server Agent participant RR as Reputation Registry participant V as Validator Agent participant VR as Validation Registry Note over C,VR: Complete Agent Interaction Flow C->>IR: 1. Register (AgentDomain, AgentAddress) IR-->>C: AgentID S->>IR: 2. Register (AgentDomain, AgentAddress) IR-->>S: AgentID C->>IR: 3. Query available Server Agents IR-->>C: Server Agent List C->>S: 4. Assign Task S->>RR: 5. Pre-authorize Feedback (ClientID, ServerID) RR-->>S: FeedbackAuthID S->>S: 6. Execute Task S-->>C: 7. Return Results alt Verification Needed C->>VR: 8. Request Validation (ValidatorID, ServerID, DataHash) VR-->>V: ValidationRequest Event V->>V: 9. Execute Validation (Re-run or TEE) V->>VR: 10. Submit Validation Result (DataHash, Response) VR-->>C: ValidationResponse Event end C->>RR: 11. Provide Feedback (using FeedbackAuthID) RR-->>S: AuthFeedback Event Note over C,VR: Feedback and validation records stored off-chain

Agent Card Structure

Following the A2A Protocol Extension concept, Agent Card should include:

Required Fields

{
  "registrations": [
    {
      "agentAddress": "eip155:1:0x...",  // CAIP-10 format
      "agentId": "12345",
      "agentDomain": "example.com"
    }
  ],
  "trustModels": [
    "feedback",
    "inference-validation",
    "tee-attestation"
  ]
}

Optional Fields

  • FeedbackDataURI: URI pointing to feedback data
  • ValidationRequestsURI: Validation request data
  • ValidationResponsesURI: Validation response data

Design Philosophy

Off-chain Infrastructure

Delegates complex operations to off-chain to enable:

  • Advanced reputation algorithms and aggregation services
  • Flexible validation protocols and custom incentive mechanisms
  • Scalable data storage and retrieval

Interoperability

  • CAIP-10 ensures chain-agnostic address format
  • RFC 8615 standardizes web-based service discovery
  • Modular design allows seamless integration with existing payment and validation systems

Security Considerations

  • Feedback requires pre-authorization
  • On-chain pointers are immutable, ensuring audit trail integrity
  • Validator incentives and penalties are managed by each validation protocol
  • Verification that AgentDomain in Identity Registry actually corresponds to Agent Card is handled by protocol users themselves

Possible Future Directions

  • Cross-chain identifiers
  • Agent minting/ownership/transfer represented by NFTs
  • ENS support
  • Integration with A2A payment extensions
  • Incentives for feedback/validation availability
  • AgentDomain verification in Identity Registry

Summary

ERC-8004 provides a lightweight, modular, and scalable trust framework for the AI Agent ecosystem. Through the three-layer Registry design (Identity, Reputation, Validation), it achieves:

  1. Discoverability: Standardized agent registration and query mechanisms
  2. Trustworthiness: Multi-tiered trust models suitable for different risk scenarios
  3. Scalability: Off-chain design reduces costs while maintaining flexibility
  4. Interoperability: Adopts industry standards (CAIP-10, RFC 8615)

This proposal represents an important step in the convergence of Web3 and AI Agents, laying the foundation for a future cross-organizational agent economy.

References

The original proposal is licensed under CC0 (rights waiver).