Original Author: Shirley Li, Researcher at Web3Caff Research

How to easily grasp the market hotspots, technological trends, ecological developments, and governance situations occurring in the new generation of the financial technology (FinTech) industry...? The "Market Pulse Analysis" column launched by Web3Caff Research will deeply explore and filter the current hot events occurring on the front lines, and conduct value interpretation, commentary, and principle analysis. Looking at the essence through the phenomenon, instantly follow us to quickly capture the frontline market trends.

Compared to human users, the biggest advantage of AI Agents lies in their ideal condition of having a stronger autonomous execution capability: they can complete tasks on their own, carry out operations independently, and proactively call external tools without continuous human intervention. However, in the actual process of AI Agents calling tools (such as trading platform APIs, data analysis tools, or oracles), they still face some challenges.

Firstly, 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 connect to the required tools without human intervention, and the specific payment methods of different platforms also vary, lacking standardized processes. This can create some confusion in the process of AI Agents calling tools.

Secondly, in traditional internet contexts, calling an API typically requires developers to register an account, obtain an API Key, and conduct authorization verification according to specific rules. This process was originally designed for human participants, but for AI Agents to automatically complete registration, obtain credentials, and call tools, there is still a lack of publicly available standardized implementation solutions.

Although the x402 protocol currently supports AI Agents to automatically complete payments, it is primarily applicable to "pay-as-you-go" open interfaces and struggles to address more complex permission scenarios, such as when only subscribed users can access services, or users holding certain credentials can enjoy discounts.

To fill this gap, OpenSea recently attempted to launch the ERC-8257 standard draft, dedicated to establishing an open, permissionless on-chain tool directory for AI Agents, allowing them to discover tools independently, 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 and make 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 protocol, access rules, etc. The on-chain registry needs to record critical data such as the address of the off-chain file, file hash value, and tool developer information. This design aims to prevent developers from altering tool content without authorization later. When AI Agents call tools, they can verify the off-chain content against the on-chain registered information by checking the file hash value.

In ERC-8257, there is also a crucial design: access permissions are not fixed formats but are defined through independent smart contracts. Tool developers can freely define this contract to stipulate 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 has subscribed, whether it is on a certain whitelist, etc.

For instance, a certain on-chain analysis tool stipulates that ordinary users pay $0.05 per call for ordinary APIs, while users holding a certain NFT only need to pay $0.01 per call. Additionally, if users subscribe to its services (continuously paying through specified Tokens or payment protocols), they can also gain access to high-level 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 permissions, it can obtain these conditions on-chain or in the market (such as buying NFTs or completing subscriptions) and then reapply for the call.

However, it is essential to note that when access permissions exist as assets like NFTs or Tokens, they may enter the market circulation system, leading to significant value fluctuations or speculative behaviors influenced by supply and demand dynamics.

Thus, ERC-8257 does not limit the permission system to a single asset model but opts to maintain 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 systems that are non-asset-based to mitigate the impacts of speculative activities.

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

From an overall process perspective, ERC-8257 operates roughly as follows:

• Tool developers deploy tool services and write corresponding access permissions, 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 to discover tools or services that meet their needs and can further read detailed description files to understand the calling rules;
• If the AI Agent does not meet the access conditions, it can attempt to obtain the corresponding permissions and initiate the call again;
• Ultimately, AI Agents can autonomously complete the entire process of tool discovery, permission verification, payment, and calling without human participation.

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

Overall, what ERC-8257 attempts to solve is not merely the issue of how to put APIs on-chain, but 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 the design objectives, ERC-8257 will complement the x402 protocol:

• ERC-8257 is expected to allow AI Agents to discover tools globally and determine on their own whether they have access permissions based on rules;
• The x402 protocol is responsible for payment and settlement during the tool calling process. Once the tool is authorized for calling, it supports AI Agents to pay per call or based on calling frequency.

However, aside from what was mentioned earlier, if access permissions exist as assets such as NFTs or Tokens, this could introduce value fluctuations and speculative risks. The ERC-8257 standard will still face some potential risk challenges during its actual implementation.

For instance, although ERC-8257 provides a standardized tool registration and access framework, different developers may still have variations in setting access conditions. While AI Agents can rely on a unified on-chain indexing path at the tool discovery level, in the actual calling process, compatibility with different permission judgment logics is still necessary, which introduces a certain level of technical complexity.

Moreover, in terms of trust mechanisms, currently, AI Agents verify whether the file has been tampered with during transmission by comparing the hash values recorded on-chain and the off-chain tool description files. However, this mechanism can only address the issue of data consistency and does not further 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, since tool services are typically deployed on off-chain infrastructure, their long-term availability and stability still depend on the operational capabilities of developers, meaning AI Agents would still need to utilize external reputation mechanisms for identification.

Thus, it can be seen that before the ERC-8257 standard is practically applied, its reliability regarding tool credibility, consistency of permission rules, etc., still requires further validation and enhancement.

Key Point Structure Diagram:

References:

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

[2] ERC-8257: Agent Tool Registry

Disclaimer

This report is authored by Web3Caff Research, and the information contained is for reference only, not constituting any predictions or investment advice, proposals, or offers. Investors should not rely on this information to buy or sell any securities, cryptocurrencies, or to adopt any investment strategies. The terms and opinions expressed in this report aim to help understand industry trends and promote the responsible development of the FinTech field, including Web3, blockchain, AI, payments, etc., and should not be interpreted as explicit legal opinions or the views of Web3Caff Research. The opinions in this report reflect the personal views of the author as of the stated date and are not related to the position of Web3Caff Research and may change with subsequent circumstances. The information and views contained in this report are derived from proprietary and non-proprietary sources that Web3Caff Research believes to be reliable, but may not encompass all data and do not guarantee accuracy. Thus, Web3Caff Research does not provide any form of guarantee regarding accuracy and reliability and does not bear responsibility for any errors or omissions arising in any other way (including any liabilities caused by negligence to any party). This report may contain "forward-looking" information, which may include predictions and forecasts; this article does not constitute any guarantees regarding any predictions. Whether to rely on the information contained in this report is entirely at the discretion of the reader. This report is for reference only and does not constitute investment advice, proposals, or offers for the purchase or sale of any securities, cryptocurrencies, or the adoption of any investment strategies, and please strictly comply with the relevant laws and regulations of your country or region.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。