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

Original Author: ShirleyLi, Researcher at Web3Caff Research

How to easily grasp the market hotspots, technological trends, ecological developments, and governance dynamics occurring in the new generation of FinTech industry? The "Market Pulse Analysis" column by Web3Caff Research delves deep to explore and screen current hot events, providing value interpretation, commentary, and principle analysis. See through the appearance to perceive the essence, and follow us now to quickly capture frontline market trends.

Compared to human users, the biggest advantage of AI Agents is that, under ideal conditions, they possess stronger autonomous execution capabilities: they can complete tasks, perform operations, and actively call external tools without continuous human intervention. However, in the actual process of AI Agents calling tools (such as exchange 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 is difficult for AI Agents to autonomously locate and integrate the required tools without human intervention. Furthermore, the specific payment methods vary across different platforms, lacking a standardized process. This creates challenges in the tool-calling process for AI Agents.

Secondly, in the traditional internet, calling an API typically requires developers to register an account, obtain an API Key, and perform permission verification according to specific rules. This process was originally designed for human participants. However, for AI Agents to automatically complete registration, obtain credentials, and call tools, there is currently a lack of public 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 attempted to introduce the ERC-8257 draft standard, aiming to establish an open, permissionless on-chain tool directory for AI Agents. This would enable AI Agents to autonomously discover tools, understand access rules, and automatically complete calling and payment upon meeting conditions.

Simply put, the core of ERC-8257 is an on-chain tool registry. This registry is essentially a smart contract where tool developers can register relevant information and access permissions for their tools on-chain, making them publicly available across the network.

However, since directly storing all data on-chain can be costly, ERC-8257 allows developers to store more detailed tool information on their own maintained 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, function description, API endpoints, calling methods, pricing information, payment protocols, access rules, etc. The on-chain registry then records key data such as the off-chain file address, file hash, and tool developer information. This design aims to prevent developers from subsequently tampering with the tool content. When an AI Agent calls a tool, it can verify whether the off-chain content matches the information registered on-chain by checking the file hash.

In ERC-8257, there is another crucial design: access permissions are not fixed in format 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 can check if an AI Agent holds a specific NFT, holds a specific Token, has a subscription, or is on a certain whitelist.

Consider an example: an on-chain analysis tool stipulates that the fee for regular users to call a standard API is $0.05 per call, while users holding a specific NFT only need to pay $0.01 per call. Additionally, if a user subscribes to its service (paying continuously via a designated Token or payment protocol), they can gain access to advanced analysis interfaces.

In this scenario, "holding a specific NFT" and "subscribing to the service" are two special types of access credentials. If the AI Agent does not currently possess the corresponding permissions, it can acquire these conditions on-chain or in the market (e.g., purchasing the NFT or completing the subscription), and then re-request the call.

However, it is important to note that when access permissions exist in the form of assets like NFTs or Tokens, they can enter the market circulation system. Consequently, they may be subject to supply and demand dynamics, leading to significant value volatility or speculative behavior.

Therefore, ERC-8257 does not restrict the permission system to a single asset model. Instead, it chooses to remain open. Tool or service developers can select different access mechanisms based on specific needs, such as introducing non-transferable Soulbound NFTs to avoid value fluctuations caused by trading activity, or introducing non-asset-based mechanisms like reputation scores to mitigate the impact of speculation.

On the payment front, ERC-8257 is also not responsible for defining specific payment logic. 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 process, the working method of ERC-8257 is roughly as follows:

• The tool developer deploys the tool service, writes the corresponding access permissions, and then submits the relevant information to the on-chain registry;
• When an AI Agent needs to call a specific tool or service, it scans the on-chain registry. Upon finding a tool or service that meets its requirements, 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 obtain the necessary permissions and then initiate the call again;
• Ultimately, the AI Agent can autonomously complete the entire process of tool discovery, permission verification, payment, and calling without human participation.

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

In general, what ERC-8257 attempts to solve is not just how to put APIs on-chain, but also how AI Agents can, like human users, automatically discover tools, understand access rules, obtain permissions, and call these tools in a standardized way. From a design perspective, ERC-8257 will form a complementary relationship with the x402 protocol:

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

However, besides the previously mentioned potential for value volatility and speculation risks if access permissions exist as assets like NFTs or Tokens, the ERC-8257 standard may face several potential risk challenges during actual implementation.

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

Furthermore, regarding the trust mechanism, currently, AI Agents verify whether the off-chain tool description file has been tampered with during transmission by comparing the hash recorded on-chain. However, this mechanism only resolves the issue of data consistency. It cannot guarantee whether the tool's operational logic is correct, whether its interface is trustworthy, or whether there are potential information leakage risks during data processing. Additionally, as 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 will also need to utilize external reputation mechanisms for screening.

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

Key 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. The information contained herein is for informational purposes only and does not constitute any forecast or investment advice, recommendation, or solicitation. Investors should not rely on this information to buy or sell any securities, cryptocurrencies, or adopt any investment strategy. The terminology used and views expressed in this report are intended to help understand industry trends and promote responsible development in the FinTech field, including Web3, blockchain, AI, and payments, and should not be interpreted as definitive legal opinions or the views of Web3Caff Research. The views in the report reflect only the author's personal opinions as of the stated date, are independent of 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 they may not 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 liability for errors or omissions arising in any manner (including liability for negligence towards any person). This report may contain "forward-looking" information, which may include projections and forecasts. Nothing herein constitutes a guarantee of any forecast. It is entirely at the reader's own discretion to rely on the information contained in this report. This report is for informational purposes only and does not constitute investment advice, a recommendation, or solicitation to buy or sell any securities, cryptocurrencies, or adopt any investment strategy, and you are requested to strictly comply with the relevant laws and regulations of your country or region.