让 AI Agent 自己调用 API、购买权限与完成支付，ERC-8257 如何实现？

Original Author: Shirley Li, Researcher at Web3Caff Research

How can you easily grasp the market hotspots, technological trends, ecosystem developments, and governance dynamics currently unfolding in the new generation of FinTech? Web3Caff Research's "Market Pulse Analysis" column delves deep into the front lines to discover and select current hot events, providing value interpretation, commentary, and principle analysis. Let's see through the surface to the essence and quickly capture the front-line market风向 alongside us.

Compared to human users, the biggest advantage of an AI Agent is that, under ideal circumstances, it possesses stronger autonomous execution capabilities: it can complete tasks, execute operations, and proactively call external tools without continuous human intervention. However, in the actual process of AI Agents calling tools (e.g., trading platform APIs, data analysis tools, oracles), some issues still arise.

First, the access points for these tools are scattered across GitHub, official websites, centralized API platforms, etc., lacking a unified discovery channel. It's difficult for an AI Agent to autonomously locate and access the required tools without human intervention. Furthermore, the specific payment methods vary across different platforms, lacking a standardized process. This creates complications for the AI Agent's tool-calling process.

Second, in the traditional internet, calling an API typically requires a developer to register an account, obtain an API Key, and perform permission verification according to specific rules. This process was originally designed for humans. For an AI Agent to automatically complete registration, obtain credentials, and call tools, there is still a lack of publicly available and standardized implementation solutions.

Although the x402 protocol can currently support AI Agents in automatically completing payments, it is mainly suitable for "pay-per-use" open interfaces. It struggles to handle more complex permission scenarios, such as services only accessible to subscribed users, or users holding certain credentials eligible for discounts.

To fill this gap, OpenSea recently proposed the ERC-8257 standard draft. It aims to establish an open, permissionless on-chain tool directory for AI Agents, enabling them to autonomously discover tools, understand access rules, and automatically complete calls and payments upon meeting conditions.

Simply put, the core of ERC-8257 is an on-chain tool registry. This registry is essentially a smart contract. Tool developers can register their tool's information and access permissions on-chain, making them public to the entire network.

However, since storing all data directly on-chain can be costly, ERC-8257 allows developers to store more detailed tool information on their own servers or domains, presented in JSON format files (Manifest). The on-chain registry only records links pointing to these files. These off-chain files typically include: tool name, functional description, API endpoints, calling methods, pricing information, payment protocols, access rules, etc. The on-chain registry needs to record key data such as the off-chain file's address, file hash, and developer information. This design aims to prevent developers from arbitrarily tampering with the tool content later. When an AI Agent calls a tool, it can verify the file hash to check if the off-chain content matches the information registered on-chain.

Another crucial design in ERC-8257 is that access permissions are not fixed but are defined through independent smart contracts. Tool developers can freely define these contracts to specify who is eligible to call their tools. For example, a developer could check whether an AI Agent holds a specific NFT, holds a particular token, has a subscription, or is on a specific whitelist.

Let's look at an example. An on-chain analysis tool stipulates that a standard API call costs $0.50 for regular users, while users holding a specific NFT only pay $0.01 per call. Meanwhile, if a user subscribes to the service (paying continuously via a designated token or payment protocol), they gain access to advanced analysis interfaces.

In this scenario, "holding a specific NFT" and "subscribing to the service" are two special access credentials. If the AI Agent currently lacks the required permissions, it can acquire these conditions on-chain or in the market (e.g., buying the NFT or completing the subscription) before re-applying to call the tool.

However, it's important to note that when access permissions exist as assets like NFTs or tokens, they can enter the market circulation system. Consequently, they are subject to supply and demand dynamics, potentially leading to high price volatility or speculative behavior.

Therefore, ERC-8257 does not restrict the permission system to a single asset model but chooses to maintain openness. Tool or service developers can select different access mechanisms based on specific needs. For example, introducing non-transferable Soulbound NFTs to avoid price fluctuations caused by trading, or implementing non-asset-based mechanisms like reputation scores to reduce the impact of speculation.

On the payment front, ERC-8257 does not define the specific payment logic either. It only requires developers to declare in the JSON file which payment protocol they support, such as x402, on-chain ERC-20 payments, or other machine payment protocols. The actual payment execution will be handled by the corresponding protocol.

Looking at the overall workflow, ERC-8257 operates roughly as follows:

• The tool developer deploys the tool service, writes the corresponding access permissions, and submits the relevant information to the on-chain registry.
• When an AI Agent needs to call a specific tool or service, it can scan the on-chain registry. Upon finding a suitable tool or service, it can further read the detailed description file to understand the calling rules.
• If the AI Agent does not meet the access conditions, it can attempt to acquire the necessary permissions and re-initiate the call.
• Finally, the AI Agent can autonomously complete the entire process of tool discovery, permission verification, payment, and calling without human involvement.

Source: The App Store for Agent Tools: ERC-8257

Overall, ERC-8257 aims to solve not just the problem of putting APIs on-chain but enabling AI Agents to autonomously discover tools, understand access rules, acquire access permissions, and call these tools in a standardized way, just like human users. From a design perspective, ERC-8257 will form a complementary relationship with the x402 protocol:

• ERC-8257 is expected to enable AI Agents to discover tools globally and determine whether they have access based on rules.
• The x402 protocol handles payment and settlement during the tool-calling process. Once a tool is allowed to be called, it supports AI Agents paying per use or based on call frequency.

However, besides the previously mentioned risk that access permissions existing as asset forms like NFTs or tokens might introduce value volatility and speculation, the actual implementation of the ERC-8257 standard will face other potential risk challenges.

For example, although ERC-8257 provides a standardized framework for tool registration and access, different developers may still have variations in setting access conditions. While AI Agents can rely on a unified on-chain indexing path for tool discovery, they still need to adapt to different permission judgment logics during the actual calling process, introducing certain technical complexity.

Furthermore, regarding trust mechanisms, current AI Agents compare the hash value recorded on-chain with the off-chain tool description file to verify if the file was tampered with during transmission. However, this mechanism only resolves data consistency issues. It cannot guarantee that the tool's operational logic is correct, its interface is trustworthy, or whether there are potential information leak risks during data processing. Additionally, since tool services are typically deployed on off-chain infrastructure, their long-term availability and stability still depend on the developer's operational capabilities. This means AI Agents need to rely on external reputation mechanisms for verification.

Thus, before the ERC-8257 standard is practically applied, aspects like tool trustworthiness and consistency of permission rules still require further verification and improvement.< /p>

Key Points Structure Diagram:

References:

[1] The App Store for Agent Tools: ERC-8257

[2] ERC-8257: Agent Tool Registry

Disclaimer

This report is prepared by Web3Caff Research and is for informational purposes only. It does not constitute any forecast, investment advice, recommendation, or solicitation, and investors should not rely on it to buy or sell any securities, cryptocurrencies, or adopt any investment strategies. The terminology used and views expressed herein are intended to help understand industry trends and promote responsible development in the FinTech field, including Web3, blockchain, AI, payments, etc., and should not be construed as definitive legal opinions or the views of Web3Caff Research. The opinions expressed reflect the author's personal views as of the date stated and are unrelated to the position of Web3Caff Research, and may change subsequently. The information and opinions contained in this report are derived from proprietary and non-proprietary sources deemed reliable by Web3Caff Research but do not necessarily cover all data, and their accuracy is not guaranteed. Therefore, Web3Caff Research makes no warranties of any kind regarding their accuracy or reliability and assumes no responsibility for errors or omissions arising in any other manner (including liability to any person due to negligence). This report may contain "forward-looking" information, which may include predictions and forecasts, and nothing herein constitutes a guarantee of any forecast. Reliance on the information contained in this report is entirely at the reader's own risk. This report is for informational purposes only and does not constitute investment advice, recommendation, or solicitation to buy or sell any securities, cryptocurrencies, or adopt any investment strategy, and you are strictly advised to comply with the relevant laws and regulations of your country or region.