Before the ERC-8257 standard is practically applied, its credibility in tools, consistency of permission rules, and other aspects still need further verification and improvement.

Written by: Shirley Li, Researcher at Web3Caff Research

Compared to human users, the greatest advantage of AI Agents lies in their ideally stronger autonomous execution capabilities: they can complete tasks by themselves, perform operations independently, and actively call external tools without continuous human intervention. However, during the actual process of AI Agents calling tools (such as trading platform APIs, data analysis tools, or oracles), they still encounter some issues.

First, the access points for these tools are scattered across GitHub, official websites, centralized API platforms, and others, lacking a unified discovery channel. Without human intervention, it is challenging for AI Agents to autonomously locate and access the required tools, and different platforms also have varying payment methods, lacking standardized processes. This causes some challenges for AI Agents when calling tools.

Second, in the traditional internet, calling APIs typically requires developers to register an account, obtain API keys, and perform permission verification according to specific rules. This process was originally designed for human participants, but for AI Agents, there is still a lack of public and standardized implementation solutions to automatically complete registration, obtain credentials, and call tools.

Although the x402 protocol can currently support AI Agents in automatically completing payments, it is mainly applicable to "pay-per-use" open interfaces, making it difficult to address more complex permission scenarios, such as services only available to subscribed users or users holding specific credentials enjoying discounts.

To fill this gap, OpenSea has recently attempted to launch a draft of the ERC-8257 standard, aiming to create an open, permissionless on-chain tool directory for AI Agents to autonomously discover tools, understand access rules, and automatically complete calls and payments once conditions are met.

In simple terms, the core of ERC-8257 is a set of on-chain tool registries. This registry is essentially a smart contract where tool developers can register relevant information and access permissions of their tools on-chain, making it publicly available across the network.

However, due to the high cost of directly putting all data on-chain, ERC-8257 allows developers to store more detailed tool information on their maintained servers or domains in the form of JSON files (Manifest), while the on-chain registry only records links pointing to these files. The off-chain file typically includes: tool name, function description, API interface, calling method, pricing information, payment protocols, access rules, etc. The on-chain registry needs to record critical data such as the address of the off-chain file, the file hash, and tool developer information. This design aims to prevent developers from tampering with tool contents afterwards. When AI Agents call tools, they can verify whether the off-chain content matches the information recorded on-chain by checking the file hash.

An important design in ERC-8257 is that access permissions are not in a fixed format but are defined by an independent smart contract. Tool developers can freely define this contract to specify who is qualified to call their tools. For example, developers can check whether the AI Agent holds a certain NFT, holds a certain token, has subscribed, or is on a specific whitelist, etc.

For example, a certain on-chain analysis tool specifies: the cost for regular users to call the regular API is $0.05 per call, while users holding a certain NFT only need to pay $0.01 per call. Additionally, if users subscribe to its services (by making continuous payments through specified tokens or payment protocols), they can access advanced analysis interfaces.

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

However, it is important to note that when access permissions exist in the form of NFTs or tokens, they may enter the marketplace circulation system, thus being subject to supply and demand impacts, resulting in higher value fluctuations or speculative behavior.

Therefore, ERC-8257 does not limit the permission system to a single asset model but opts for openness. Tool or service developers can choose different access mechanisms according to specific needs, for example, introducing non-transferable Soulbound NFTs to avoid value fluctuations caused by trading behaviors, or introducing reputation scoring mechanisms to reduce the impacts of speculative actions.

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

Overall, the ERC-8257 operates roughly as follows:

• Tool developers deploy tool services and write corresponding access permissions, and then submit relevant information to the on-chain registry;
• When AI Agents need to call a certain tool or service, they can scan the on-chain registry, discover tools or services that meet their needs, and further read detailed description files to understand calling rules;
• If the AI Agent does not meet the access conditions, it can try to obtain the corresponding permissions and then initiate the call again;
• Ultimately, AI Agents 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, what ERC-8257 attempts to resolve is not just how to put APIs on-chain, but rather how AI Agents can automatically discover tools, understand access rules, obtain access permissions, and call these tools in a standardized manner, 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 judge their access permissions based on rules;
• The x402 protocol is responsible for payments and settlements during the tool calling process. Once tools are permitted to be called, it supports AI Agents to pay per use or by calling frequency.

However, in addition to the aforementioned concerns that if access permissions exist in the form of NFTs or tokens, there may be value fluctuations and speculation risks, the ERC-8257 standard may also face some potential risk challenges during practical implementation.

For example, although ERC-8257 provides a standardized framework for tool registration and access, there are still differences among different developers when setting access conditions. Although AI Agents can rely on a unified on-chain indexing path to discover tools, during actual calls, they still need to accommodate different permission judgment logics, which brings a certain degree of technical complexity.

Furthermore, in terms of trust mechanisms, current AI Agents verify files during transmission by comparing the hash values recorded on-chain and off-chain tool description files to check if they have been tampered with. However, this mechanism can only solve the issue of data consistency and cannot further guarantee whether the tool's operation logic is correct, whether its interface is reliable, or whether there are potential risks of information leakage during the data processing. Additionally, 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 AI Agents need to rely on external reputation mechanisms for identification.

It is evident that before the ERC-8257 standard is practically applied, it still requires further verification and improvement in aspects such as tool credibility and consistency of permission rules.

Key Point Diagram:

References:

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

[2] ERC-8257: Agent Tool Registry