GoPlus Security 🚦 (@GoPlusSecurity): AI Agent Economy Infrastructure: ERC-8004 & A2A & MCP

AI Agent Economy Infrastructure: ERC-8004 & A2A & MCP ERC-8004, A2A, and MCP together build the infrastructure for the AI Agent economy, with ERC-8004 playing the role of the trust layer on Ethereum, bringing Web2 protocols originally used only for communication and tool invocation into Web3's trusted environment. Division of Roles: Communication, Tools, and Trust To understand the integration of these three, we must first clarify their core roles in the AI Agent ecosystem: In summary: A2A handles horizontal agent dialogue. MCP handles vertical agent tool invocation. ERC-8004 sits external to the entire A2A/MCP collaboration, providing trusted "rules and ledger" through blockchain, ensuring that in open markets: "who you are (identity)", "how well you perform (reputation)", and "whether you completed the task (verification and settlement)" are all trustworthy and auditable. This three-layer architecture enables AI agents to evolve from isolated programs into economic entities capable of trusted, verifiable, and transactional collaboration in decentralized networks, as analyzed in detail below. Integration of ERC-8004 and A2A ERC-8004 is the "trust enhancement package" or "Web3 extension" for the A2A protocol in decentralized environments. The A2A protocol itself defines how agents dialogue and distribute subtasks (for example: a client agent delegates analysis tasks to a financial agent). However, A2A lacks trust and security capabilities, which ERC-8004 complements. Identity & Discovery:The A2A protocol describes agent capabilities, API endpoints, and other information through AgentCard (agent description file). The Identity Registry introduced by ERC-8004 binds the agent's on-chain address with its AgentCard description file (usually a URI) and records it on-chain. Effect: This provides A2A with immutable on-chain identity. An agent can query another agent's A2A communication metadata through the ERC-8004 registry using the on-chain address, achieving trusted agent discovery. Reputation & Selection:Before A2A collaboration, client agents need to decide which service agent to trust. The Reputation Registry of ERC-8004 allows both parties to record hash values/proofs of feedback and ratings about service quality (including task descriptions, signatures, etc.) on-chain after collaboration is complete. Effect: Any agent can query and aggregate these public on-chain records to form a decentralized credit report. This adds a foundation for trust decisions to the A2A collaboration negotiation step, avoiding malicious or inefficient agents. Task Execution & Settlement (Validation & Settlement):During A2A collaboration, how to ensure the service agent actually completed the task? The Validation Registry of ERC-8004 provides on-chain hooks for various verification models, such as supporting staking guarantees (Restaking), Trusted Execution Environment (TEE) proofs, or Zero-Knowledge Proofs (ZK Proofs). Effect: Task execution result hashes or verification proofs are submitted to this registry. This makes A2A task delivery trustworthy, and can seamlessly integrate with the x402 payment protocol (a micropayment protocol) or other payment standards to achieve automatic settlement based on verification results. Synergy between ERC-8004 and MCP MCP (Model-Controller Protocol) focuses on how individual agents interact with their toolbox (models, data, APIs) in a standardized way. It enables agents to use external capabilities in a unified format, like using functions. When a complex task is split and coordinated among multiple agents through A2A, one of the service agents may need to use MCP internally to invoke tools. A2A Coordination: Client agent (Charlie) uses A2A protocol to send task requests to market analysis agent (Alice). ERC-8004 Trust Check: Before sending the task, Charlie verifies Alice's identity and past records through ERC-8004's Identity and Reputation Registries. MCP Tool Invocation (Internal): After receiving the task, Alice uses MCP protocol internally to invoke a search API or financial model to perform analysis work. Result Return & Validation: Alice returns the analysis results to Charlie through A2A. ERC-8004 Settlement: To ensure result quality, Alice and/or a Validator Agent (Bob) submit proof of results to ERC-8004's Validation Registry. Charlie triggers payment settlement based on x402 protocol or other mechanisms according to the on-chain verification results. Case Analysis This case is based on the publicly available ERC-8004 example code repository, which demonstrates how to use ERC-8004's three registries to coordinate AI agents. Role Definition (Based on A2A Protocol) In this use case, we define three agent roles whose collaborative communication follows the A2A protocol pattern: Implementation Process: Step-by-Step Details The entire workflow is an A2A task flow, with trust and settlement guarantees provided by ERC-8004, and tool invocation capabilities provided by MCP. Phase One: Discovery & Trust (A2A + ERC-8004) Identity Binding: Alice and Bob first register their on-chain addresses with their AgentCard (A2A description file) URIs in the ERC-8004 Identity Registry. Trusted Discovery: Client Agent (Charlie) wants to find a market analysis service. It queries the ERC-8004 Reputation Registry to view the historical rating records of potential Server Agent (Alice), and queries the Identity Registry to obtain Alice's A2A description file to confirm her capabilities and communication endpoint. Task Negotiation: Based on trust assessment, Charlie uses A2A protocol to send market analysis task requests and detailed parameters to Alice. Phase Two: Task Execution & Tool Invocation (MCP Intervention) MCP Execution: After Server Agent (Alice) receives the A2A task, she needs to perform specific analysis work. During this process, Alice uses MCP protocol internally to access the required tools and data:Tool Invocation: Alice uses MCP standard format to invoke external financial data APIs or Large Language Models (LLMs) for data retrieval and reasoning. MCP Advantage: Whether Alice invokes a private RAG system or public Bing search API, MCP ensures that these tool and model interface invocations are standardized. Result Generation: Alice completes the analysis and generates a report. Phase Three: Result Verification & Feedback Settlement (ERC-8004 + A2A) This is the core value provided by ERC-8004, bringing A2A communication results on-chain for trusted verification: Verification Task: Alice submits the encrypted hash value of the analysis report and necessary metadata to the ERC-8004 Validation Registry. Trusted Verification: Validator Agent (Bob) receives the A2A message and, according to the task protocol, uses Trusted Execution Environment (TEE) or Restaking Network (Restaking AVS) off-chain to verify Alice's report. Verification Results On-Chain: Bob submits the verification results (such as "task successful" or "fraud detected") in the form of cryptographic proof to the ERC-8004 Validation Registry. Reputation Update:After Charlie confirms service completion and successful verification, he submits hash values/proofs of feedback and rating records for Alice to the ERC-8004 Reputation Registry. This accumulates trusted on-chain credit for Alice. Automatic Settlement: Charlie's smart contract monitors the status of the ERC-8004 Validation Registry. Once verification passes, it triggers micropayments based on the x402 payment protocol, automatically paying service fees to Alice's on-chain address. Code Implementation Examples Key Collaboration Steps (A2A Pattern) This example simulates the A2A workflow among Client Agent (Charlie), Server Agent (Alice), and Validator Agent (Bob). Key Code Snippet Analysis: Identity Registration (Foundation of A2A Discovery) The A2A protocol relies on AgentCard to describe agent capabilities and endpoints. ERC-8004's Identity Registry binds this off-chain A2A description file with the on-chain address, achieving trusted discovery. Below is simplified code implementing this functionality in a Solidity smart contract: Integration Analysis: When Client Agent (Charlie) wants to collaborate with Alice through A2A protocol, it first queries this Identity Registry, using Alice's on-chain address (trusted) to obtain her AgentDomain. Subsequently, Charlie can obtain the AgentCard through that domain (e.g., market-analysis.agent.eth) and conduct A2A task negotiation. Key Code Snippet Analysis: AgentCard Supports MCP According to ERC-8004's design, the agent's AgentCard (A2A description file) is off-chain, containing not only A2A communication information but also the MCP service information provided by the agent. AgentCard (JSON format, simplified): Integration Analysis: After Client Agent discovers Alice, it downloads her AgentCard. The mcp_definition_uri in the AgentCard indirectly guides Client/Server Agent on how to use MCP protocol to invoke models or tools (for example, querying Alice's dedicated API or model). Therefore, ERC-8004 is responsible for trusted discovery (Identity Registry), while MCP is responsible for execution (tool/model interfaces defined in AgentCard). Key Code Snippet Analysis: Validation & Payment The x402 protocol is used to handle machine-to-machine micropayments. ERC-8004 aims to serve as its trust and verification hook, achieving automatic payment based on task completion quality. ERC-8004's Validation Registry records whether tasks are trustworthily completed, which is key to triggering x402 payments. Below is a simplified model of Payment Release based on successful verification in a Solidity smart contract: Integration Analysis: A2A Collaboration: Task completed. ERC-8004 Verification: Validator Agent (Bob) submits success status (VALIDATION_SUCCESS) to Validation Registry. x402 Settlement: Client Agent (Charlie) or escrow contract queries that status. Once the status is confirmed, funds are automatically released to Server Agent (Alice) according to the pre-negotiated x402 payment credential terms. In short, x402 defines the payment process, while ERC-8004 provides immutable conditional judgment for this process through its on-chain registry. Reference Links https://8004.org/ https://eips.ethereum.org/EIPS/eip-8004 https://github.com/google-agentic-commerce/a2a-x402 https://ethereum-magicians.org/t/erc-8004-trustless-agents/25098 https://github.com/chaoschain/erc-8004-example