Author: ShirleyLi, researcher at Web3Caff Research

Compared with human users, the biggest advantage of AI Agent is that under ideal circumstances, it has stronger autonomous execution capabilities: it can complete tasks by itself, perform operations by itself, and actively call external tools without continuous human intervention. However, there are still some problems faced in the actual process of AI Agent calling tools (such as trading platform APIs, data analysis tools, oracles).

First of all, access to these tools is scattered across GitHub, official websites, centralized API platforms, etc., lacking a unified discovery channel. It is difficult for AI Agents to independently locate and access the required tools without manual intervention. Moreover, the specific payment methods of different platforms are also different, and there is a lack of standardized processes. This will cause some troubles in the process of AI Agent calling tools.

Secondly, on the traditional Internet, calling APIs usually requires developers to register an account, obtain an API Key, and conduct permission verification according to specific rules. This process was originally developed for human participants, but for AI Agents, there is still a lack of open and standardized implementation solutions to automatically complete registration, obtain credentials, and call tools.

Although the current x402 protocol can already support AI Agents to automatically complete payments, it is mainly suitable for "pay-and-use" open interfaces and is difficult to cope with more complex permission scenarios. For example, only subscribed users can access services, or users holding certain credentials can enjoy discounts, etc.

To fill this gap, OpenSea recently tried to launch the ERC-8257 standard draft, which is dedicated to establishing an open, permissionless on-chain tool directory for AI Agents, allowing AI Agents to independently discover tools, understand access rules, and automatically complete calls and payments after meeting conditions.

To put it simply, the core of ERC-8257 is a set of on-chain tool registry. The registry is essentially a smart contract. Tool developers can register the relevant information and access rights of their tools on the chain and make it public to the entire network.

However, due to the high cost of uploading all data directly to the chain, ERC-8257 allows developers to store more detailed tool information on servers or domain names maintained by themselves, in the form of a JSON format file (Manifest), and the on-chain registry only records the link to the file. The off-chain file usually includes: tool name, function description, API interface, calling method, pricing information, payment agreement, access rules, etc. The on-chain registry needs to record key data such as the address of the off-chain file, file hash value, and tool developer information. This design is intended to prevent developers from tampering with tool content later. When the AI ​​Agent calls the tool, it can verify whether the off-chain content is consistent with the information registered on the chain by verifying the file hash value.

In ERC-8257, there is another key design: access permissions are not in a fixed format, but are defined through independent smart contracts. Tool developers are free to define this contract to dictate who is eligible to call their tools. For example, developers can check whether the AI ​​Agent holds a certain NFT, whether it holds a certain Token, whether it is subscribed, whether it is in a certain whitelist, etc.

Let’s look at an example. A certain on-chain analysis tool stipulates that the fee for ordinary users to call ordinary APIs is US$0.05/time, while users who hold a certain NFT only need to pay US$0.01/time. At the same time, if users subscribe to its services (continuous payment through designated Token or payment protocol), they can also gain access to the advanced analysis interface.

In this scenario, "holding a certain NFT" and "subscribing to a service" are two special access credentials. If the AI ​​Agent currently does not have the corresponding permissions, it can obtain these conditions on the chain or in the market (such as purchasing NFT or completing a subscription), and then reapply for the call.

However, it should be noted that when access rights exist in the form of assets such as NFT or Token, they themselves may enter the market circulation system, which will be affected by the supply and demand relationship and lead to higher value fluctuations or speculation.

Therefore, ERC-8257 does not limit the permission system to a single asset model, but chooses to remain open. Tool or service developers can choose different access mechanisms based on specific needs. For example, introduce non-transferable Soulbound NFTs to avoid value fluctuations caused by trading behaviors, or introduce non-asset-based mechanisms such as reputation scores to reduce the impact of speculation.

At the payment level, ERC-8257 is not responsible for defining specific payment logic. Instead, it only requires developers to declare in a JSON file which payment protocol is supported, such as x402, on-chain ERC-20 payment, or other machine payment protocols. The actual payment execution will be completed by the corresponding protocol.

From the overall process, ERC-8257 works roughly as follows:

• Tool developers deploy tool services, write corresponding access permissions, and then submit relevant information to the on-chain registry;

• When the AI Agent needs to call a certain tool or service, it can scan the registry on the chain, and when it finds a tool or service that meets its needs, it can further read the detailed description file to understand the calling rules;

• If the AI Agent does not meet the access conditions, you can try to obtain the corresponding permissions and initiate the call again;

• Ultimately, the AI Agent can autonomously complete the entire process of tool discovery, permission verification, payment and invocation without human intervention.

Image source:The App Store for Agent Tools: ERC-8257

In general, what ERC-8257 is trying to solve is not just the problem of how to get APIs on the chain, but how AI Agents can automatically discover tools, understand access rules, obtain access permissions, and call these tools in a standardized way, just like human users. From the design goal, 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 rights based on rules;

• The x402 protocol is responsible for payment and settlement during the process of calling tools. After the tool is allowed to be called, the AI ​​Agent is supported to be paid on a pay-per-time or call-frequency basis.

However, in addition to the previously mentioned value fluctuations and speculation risks that may be introduced if access rights exist in the form of assets such as NFT or Token, the ERC-8257 standard will also face some potential risk challenges during the actual implementation process.

For example, although ERC-8257 provides a standardized tool registration and access framework, different developers still have differences in setting access conditions. Although AI Agent can rely on a unified on-chain index path at the discovery tool level, during the actual call process, it still needs to be compatible with different permission judgment logic, which will bring certain technical complexity.

In addition, in terms of trust mechanism, the current AI Agent will verify whether the file has been tampered with during the transmission process by comparing the hash value recorded on the chain with the tool description file off the chain. However, this mechanism can only solve the problem of whether the data is consistent, and cannot further guarantee whether the tool's operating logic is correct, whether its interface is trustworthy, and whether there are risks such as potential information leakage during data processing. At the same time, since tool services are usually deployed on off-chain infrastructure, their long-term availability and stability still depend on the developer's operational capabilities, which means that AI Agents also need to be screened through external reputation mechanisms.

It can be seen that before the ERC-8257 standard is actually applied, its tool credibility, permission rule consistency, etc. still need to be further verified and improved.

Key points structure chart: