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).
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.
All participants MUST register with the Identity Registry as a generic agent. Agents can have three roles:
Agents may fulfill multiple roles simultaneously without restriction.
All participants register on a smart contract on an EVM chain, which acts as a single entry point. Each agent is uniquely identified by:
https://{AgentDomain}/.well-known/agent-card.json New(AgentDomain, AgentAddress) → AgentID
Update(AgentID, Optional NewAgentDomain, Optional NewAgentAddress) → Boolean
All write operations require the transaction sender to be AgentAddress.
Get(AgentID) → AgentID, AgentDomain, AgentAddress
ResolveByDomain(AgentDomain) → AgentID, AgentDomain, AgentAddress
ResolveByAddress(AgentAddress) → AgentID, AgentDomain, AgentAddress
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"]
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.
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.
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.
ValidationResponse at the end of the validation processValidationResponse if successfulThe 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.
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.
Off-chain Infrastructure
The protocol deliberately delegates complex operations off-chain to enable:
Interoperability
Possible future directions
This protocol enables:
Sumeet Chougule sumeet.chougule@nethermind.io is working on it. If you would like to contribute, reach out.
Copyright and related rights waived via CC0.