ERC-8004: Trustless Agents

An interface to discover agents and establish trust through reputation and validation

Abstract

This ERC 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—and leaves application‑specific logic to off‑chain components.

Trust models are pluggable and tiered, with security proportional to value at risk—from low-stake tasks like ordering pizza to high-stake tasks like medical diagnosis. Developers can choose from three trust models: reputation-based systems using client feedback, stake-secured inference validation (crypto-economics), and attestations for agents running in TEEs (crypto-verifiability).

Motivation

The existing A2A protocol handles agent authentication, skills advertisement via AgentCards, direct messaging, and complete task-lifecycle orchestration. Its adoption by leading technology firms demonstrates clear market demand. However, the protocol currently operates within organizational boundaries and assumes trust between Server Agent and Client Agent.

To foster an open, cross-organizational agent economy, we need mechanisms for discovering and trusting agents in untrusted settings. This ERC addresses this need through three core components, which can be deployed on any L2 or on Mainnet:

1. Identity Registry - A minimal on-chain handle that resolves to an agent’s off-chain AgentCard, providing every agent with a portable, censorship-resistant identifier.

2. Reputation Registry - A standard interface for posting and fetching attestations. Scoring and aggregation will likely occur off-chain, enabling an ecosystem of specialized services for agent scoring, auditor networks, and insurance pools.

3. Validation Registry - Generic hooks for requesting and recording independent checks through economic staking (validators re-running the job) or cryptographic proofs (TEEs attestations). The ERC defines only the interface, allowing any validation protocol to integrate seamlessly.

Payment layers —such as x402— are orthogonal to this protocol and not covered here. However, payment proofs can enrich feedback attestations.

This ERC builds on approaches that the Web3 industry is already experimenting with, providing a unified interface and a comprehensive stack to accelerate ecosystem adoption of trustless agents.

Specification

Participants

All participants MUST register with the Identity Registry as a generic agent. Agents can have three roles:

• Server Agent (A2A Server): Offers services and executes tasks
• Client Agent (A2A Client): Assigns tasks to Server Agents and provides feedback
• Validator Agent (Optional): Validates tasks through crypto-economic staking mechanisms (staking validators re-executing the inference) or cryptographic verification

Agents may fulfill multiple roles simultaneously without restriction.

Identity Registry

All participants register on a smart contract on an EVM chain, which acts as a single entry point. Each agent is uniquely identified by:

• AgentID: Global identifier on the blockchain, assigned incrementally by the registry
• AgentDomain: Following RFC 8615 principles, an Agent Card MUST be available at https://{AgentDomain}/.well-known/agent-card.json
• AgentAddress: EVM-compatible address identifying the agent

Write Endpoints

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

All write operations require the transaction sender to be AgentAddress.

Public Resolvers

Get(AgentID) → AgentID, AgentDomain, AgentAddress
ResolveByDomain(AgentDomain) → AgentID, AgentDomain, AgentAddress
ResolveByAddress(AgentAddress) → AgentID, AgentDomain, AgentAddress

Agent Card Structure

Using the concept of “Extension” as defined in the A2A Protocol specs, the Agent Card at the well-known URI SHOULD include a registrations array listing all blockchain registries:

"registrations": [
    { "agentId": 12345,
      "agentAddress": "eip155:1:0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb7",
      "signature": "...proof of ownership of the address..."
      },
    { "agentId": 67890,
      "agentAddress": "eip155:59144:0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb7",
      "signature": "...proof of ownership of the address..."
      }
  ]

The agentAddress field follows the CAIP-10 account identifier standard: {namespace}:{reference}:{address}.

Additionally, following the A2A extensions pattern, the Agent Card SHOULD describe which trust models are supported when the agent acts as a Server Agent:

"trustModels": ["feedback", "inference-validation", "tee-attestation"]

Reputation Registry

The Registry provides a lightweight entry point for task feedback between agents through off-chain attestations.

To minimize on-chain costs, only essential data is stored on-chain. The registry exposes a single endpoint:

AcceptFeedback(AgentClientID, AgentServerID) → emits AuthFeedback event

This emits an AuthFeedback event with parameters (AgentClientID, AgentServerID, FeedbackAuthID).

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

Feedback Data Structure

Each feedback-providing Client Agent’s Agent Card MUST extend A2A by including a FeedbackDataURI that points to a JSON file containing a list of objects like the following:

{
  "FeedbackAuthID": "eip155:1:{FeedbackAuthID}",  // Mandatory, CAIP-10 format
  "AgentSkillId": "string",         // Optional, as per A2A spec
  "TaskId": "string",         // Optional, as per A2A spec
  "contextId": "string",         // Optional, as per A2A spec
  "Rating": 95,            // Optional, Int
  "ProofOfPayment": {},      // Optional, Object
  "Data": {}                 // Optional, Object
}

Multiple entries with the same FeedbackAuthID enable multidimensional feedback for a single task.

Validation Registry

The Validation Registry provides two endpoints:

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

ValidationRequest(AgentValidatorID, AgentServerID, DataHash) emits an event with parameters (AgentValidatorID, AgentServerID, DataHash).

The smart contract stores the tuples (AgentValidatorID, AgentServerID, DataHash) of pending requests in contract memory for X seconds.

In the crypto-economic scenario:

• The DataHash commits to all information needed to re-run the job, including the input and output to be verified
• AgentValidator can be a single centralized trusted agent, a threshold committee (k-of-n) managed by a smart contract, a stake-secured service, or any other kind of programmable governance which calls ValidationResponse at the end of the validation process

In the crypto-verification scenario:

• The DataHash commits to all information needed to create the TEE attestation proof or the zkTLS proof
• AgentValidator is a verifier smart contract which checks the proof on-chain and calls ValidationResponse if successful

Validation Requests

The Server Agent, in its AgentCard, SHOULD extend the A2A specs by including a ValidationRequestsURI. The file can be hosted on centralized systems or IPFS. The JSON file should contain a dictionary DataHash => DataURI with an entry for each validation. The structure of the single DataURI file depends on the validation service.

Validation Responses

When validation is completed, AgentValidatorAddress calls or subcalls ValidationResponse(DataHash, Response). Response is a Int 0 ≤ x ≤ 100 and can be used both as binary (0, 100) or with any value between 0 and 100 for validations with a spectrum of outputs.

The smart contract checks if DataHash is still in the memory of the contract, and fails if it’s not. If successful, a ValidationResponse event is emitted with parameters (AgentValidatorID, AgentServerID, DataHash, Response).

Symmetrically to the ValidationRequests structure, the Validator Agent, in its AgentCard, COULD extend the A2A specs by including a ValidationResponsesURI value. The file can be hosted on centralized systems or IPFS. The JSON file should contain a dictionary DataHash => DataURI with an entry for each validation response. The structure of the single DataURI file, which can for example include evidence of the validation, depends on the validation service.

Both the Validation Requests and Validation Responses JSON files MIGHT include AgentSkillId, TaskId, or contextId references, following A2A specs naming conventions.

Incentives and slashing related to validation and verification are managed by the specific protocol.

Rationale

Off-chain Infrastructure

The protocol deliberately delegates complex operations off-chain to enable:

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

Interoperability

• CAIP-10 standard ensures chain-agnostic addressing
• RFC 8615 compliance enables standard web discovery
• Modular design allows integration with existing payment and validation systems

Possible future directions

• Cross-chain identifiers
• Use NFT interface for agent minting, ownership and transfer
• ENS support
• Integrations with A2A’s extensions managing payments
• Incentives to provide feedback or guarantee the off-chain data availability of feedback and validations
• Verify AgentDomain in the Identity Registry

Test Cases

This protocol enables:

• Crawling all Agent Cards starting from a logically centralized endpoint
• Easy discovery of which trust models an agent supports (feedback, inference validation, TEE attestation) for agent selection criteria
• Development of protocols and applications to browse and discover trustless agents
• Access to complete feedback and validation history for building sophisticated reputation systems

Reference Implementation

Sumeet Chougule sumeet.chougule@nethermind.io is working on it. If you would like to contribute, reach out.

Security Considerations

• Pre-authorization requirements for feedback
• On-chain pointers cannot be deleted, ensuring audit trail integrity
• Validator incentives and slashing are managed by specific validation protocols
• Verifying that the AgentDomain in the on-chain Registry actually corresponds to the one of the Agent Card is left to the user of the protocol (that’s to avoid the involvement of an oracle network)

Copyright

Copyright and related rights waived via CC0.

Citation

Please cite this document as:

Marco De Rossi (@MarcoMetaMask), Davide Crapis (@dcrapis) <davide@ethereum.org>, Jordan Ellis (@jorellis), "ERC-8004: Trustless Agents [DRAFT]," Ethereum Improvement Proposals, no. 8004, August 2025. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-8004.