As AI agents evolve from tools to autonomous economic entities, they become economic participants capable of making autonomous decisions, executing operations, and exchanging value. However, traditional payment infrastructure cannot meet a series of core needs of agents, such as autonomous transactions, cross-ecosystem interaction, and verifiable identity.

These bottlenecks have spurred the emergence of a new generation of protocols—x402, Agent Payments Protocol (AP2), and ERC-8004—to build a reliable foundation for value exchange in the coming machine economy. This article will delve into the technical principles, application scenarios, and current ecosystem of these three protocols, revealing how they collectively shape the payment landscape of the future AI Agent economy.

x402: HTTP-native on-chain payment protocol

x402, launched by Coinbase, is innovative in that it activates the underutilized HTTP 402 status code ("PaymentRequired") on the Internet, natively embeds payment logic into the web request-response stream, realizes "API call as payment", and completes settlement through stablecoins or other cryptocurrencies to solve the high friction problem of traditional payments.

Protocol Details

Because x402 is an open protocol built on the HTTP 402 status code, its architecture is a client/server architecture. The client is the buyer purchasing services/goods, and the server is the seller providing the services/goods. Building upon this client/server architecture, Coinbase provides facilitators to simplify the verification and payment settlement process between buyers and sellers.

Let's take Canza (an AI that provides transaction information), the top-ranked server on x402scan, as an example. First, the user initiates a request on the client to access Canza's paid services.

The Canza server then uses an HTTP 402 Response to define the payment requirements: the client needs to provide an X-PAYMENTHeader and make the payment via USDC on the Base Chain. See the diagram below:

After the client parses the 402 ResponseJSON content, the wallet will prompt you to sign a TransferWithAuthorization message (implemented via ERC-3009). This message allows the signer to make a gas-free transfer from the signer's address by delegating a third-party EOA address or contract address. In this example, we will delegate the transfer of USDC from our wallet to Canza's receiving address 0x4e9bCe2547A9491b09ed092c433B19888e665edB.

The user then signs the message, and the client submits the payload using a base64-encoded X-PAYMENTHeader. Upon receiving the payload, the Canza server has it verified by facilitators, who then settle the payment on the blockchain. After the Canza server confirms the payment, Canza provides the requested service to the user.

Based on the above examples, the operation process of the x402 protocol can be summarized as follows:

It is particularly noteworthy that the x402 protocol supports multiple blockchains (Base, Avalanche and other EVM chains, Solana) for payments using various crypto assets (must support ERC-3009, default is USDC), and only the server side needs to be configured.

Agent Payments Protocol (AP2): A trusted payment system within the agent ecosystem

AP2 is an open payment framework based on the Agent-to-Agent (A2A) communication protocol and the Model Context Protocol (MCP). Its core objective is to solve three major problems in agent-based commerce: authorization verification (proving that the agent has obtained user permission), authenticity (ensuring that the transaction reflects the user's true needs), and transaction accountability (clarifying the attribution of responsibility in case of disputes), so as to enable AIAgent to conduct secure transactions with any compliant merchant.

The AP2 protocol's workflow is built around the core concept of digital mandates, which are tamper-proof, cryptographically signed digital contracts serving as verifiable evidence of user instructions. Specifically, there are three types of mandates:

1. Intent Mandate

This is suitable for automated transactions where the user is not present. The user provides the AIAgent with pre-defined instructions, including clear constraints, such as "Buy concert tickets with a budget of no more than 500 yuan".

2. Shopping Cart Mandate

This applies to transactions confirmed in person by the user. It is generated when the agent has prepared the specific goods and prices for the user's confirmation. The user's approval involves signing a shopping cart authorization form, creating a secure and immutable record of the exact goods and prices, ensuring that what you see is what you pay for.

3. Payment Mandate

This is a separate credential shared with payment networks and card issuers, designed to convey information about AI Agent participation and user presence, helping to resolve transaction disputes, conduct risk assessments, and facilitate regulation.

ERC-8004: Decentralized AIAgent Identity and Reputation System

ERC-8004 is Ethereum's decentralized AIAgent identity solution, designed to address the issues of verifying the authenticity of AIAgent identities and the reliability and verifiability of behavioral records. Unlike AP2, ERC-8004 focuses on building trust between AIAgents, rather than trust in transactions between the user, AIAgent, and merchant.

The ERC-8004 design is built around three lightweight registry entries, each responsible for a different aspect of the trust model:

1. Identity Registry

Implemented based on the ERC-721 standard and with extended URIStorage functionality, this design allows AIAgent identities to be compatible with the existing NFT ecosystem.

Each AIAgent registers by calling the register function, obtaining a unique agentId (i.e., an ERC-721 tokenId). During registration, the agent needs to provide a tokenURI pointing to its agent registration file, which follows a standardized JSON format and contains information such as the agent's name, description, endpoints, and supported trust models.

2. Reputation Registry

It provides standard interfaces for publishing and retrieving service feedback from AIAgents, supporting a rating feedback system from 0-100, tag classification, and payment proof association. The registry adopts a hybrid on-chain and off-chain architecture, ensuring the on-chain composability of core data while leaving complex aggregation calculations to off-chain processing to improve efficiency.

The reputation registry's contract structure is closely linked to the identity registry—the address of the identity registry must be passed in during deployment to ensure that only registered AIAgents can obtain reputation records.

3. Validate the registry.

It provides a general Hook for requesting and recording independent verification results, and supports multiple verification mechanisms, including economic staking (verifier reruns the task) and cryptographic proofs (TEE proof, zkML verification, etc.). This design allows verification mechanisms with different security requirements to coexist in the same ecosystem.

The contract interface for verifying the registry is relatively simple, mainly consisting of two functions: ValidationRequest for submitting verification requests and ValidationResponse for recording verification results.

ERC-8004 is the identity layer protocol for the AIAgent ecosystem. It provides on-chain AI Agents with a verifiable identity, reputation system, and registration mechanism, which is crucial for establishing a trust foundation for the machine economy.

The combination of x402, AP2, and ERC-8004 constitutes a complete AIAgent payment system: ERC-8004 solves the AIAgent's identity problem, x402 solves the problem of "how to use cryptocurrency for high-frequency micro-payments", and AP2 provides a secure and standardized framework for the x402 payment protocol, setting independent economic behavior boundaries for AI Agents, enabling them to process information, hold and control assets, and truly participate in commercial value exchange, thereby giving rise to a new economic form driven by machine autonomy.