During last week's Hong Kong Web3 Carnival, I chatted with many practitioners, and everyone generally felt that the industry has not really heated up again.

There were plenty of people present and no shortage of topics. AI, RWA, stablecoins, payments... almost every direction had speakers. But beyond the excitement, many Web3 entrepreneurs remain cautious about the market. The secondary market has not fully recovered, and first-round financing is being more selective about projects. The strategy that relied on quickly growing and financing through a new narrative is increasingly difficult to pursue.

Because of this, the topic of AI has become particularly prominent in this year's discussions.

Portal Labs previously wrote in the essay “Is the AI cycle here, should Web3 entrepreneurs shift to AI?”, that most Web3 teams should not hastily switch to AI because it is trending. AI is indeed important, but if the original projects are merely repackaged under an AI shell, they are essentially still chasing a narrative.

Thus, in this article, Portal Labs will continue along this line of thought. Rather than discussing “Should we shift to AI?”, it is more worthwhile to discuss which Chinese Web3 teams are suitable for transitioning to the AI direction, and whether they can leverage their accumulated capabilities to find a truly viable migration path.

Data-Driven Teams: From On-Chain Data to AI-Usable Data

In recent years, many Web3 teams have been working on on-chain data, user behavior data, data indexing, data markets, privacy computing, and data rights verification. They have been handling issues of data collection, cleaning, structuring, authorization, and querying.

For this type of team, transitioning towards AI would be relatively natural.

As AI develops further, its data requirements become more stringent. Especially when AI agents are tasked with providing personalized services, publicly available internet data is clearly insufficient. Take consumer AI assistants as an example: if they want to genuinely assist users in making shopping decisions, they cannot just know "which product is the cheapest online," but also need to understand the users' buying habits. What price range do users usually purchase within? Do they have a preference for certain brands? How often do they repurchase? Do they frequently place orders during promotional periods? Do they care more about price, delivery speed, or after-sales reviews? These factors will all impact recommendation results. To achieve this, AI must, with user authorization, access order histories, browsing histories, transaction records, product favorites, and even after-sales and logistics information from different platforms.

In other words, the more AI agents want to transition from "general responses" to "specific decisions," the more they rely on data that is finer-grained and more contextual.

However, where will the data come from? Do users have authorization? Can the querying process be traced back? Can it be retracted after use? Will there be a benefit-sharing mechanism in the future? These all become real issues. For businesses, it also involves data security, personal information protection, trade secrets, and compliance audits. As AI becomes more integrated into real businesses, data issues become unavoidable.

This also leaves a migration space for Web3 data-driven teams.

Teams that have been focusing on on-chain data, data markets, privacy computing, and data rights verification can try to apply their capabilities to the AI data layer. For example, they can create verifiable data sources, user-authorized data networks, industry data collaboration tools, or provide compliant data querying and auditing capabilities for enterprise AI systems.

What is most worth noting here are the capabilities of data authorization, data verification, and compliant querying.

For Chinese teams, this path is also more aligned with the current environment. The nation has been promoting data factor markets, public data authorization operations, data assetization, and privacy computing applications. If Web3 teams can combine on-chain credentials, authorization records, data querying audits, and privacy protections, they could potentially access the core aspects of enterprise AI, industry models, and data circulation services.

Of course, discussing data is also easily turned into a grand narrative.

If there are no real data sources, no industry clients, and no data processing and compliance capabilities, simply creating a concept of an "AI data market" may not be feasible. The true opportunities for data-driven teams usually originate from specific industries. Finance, retail, healthcare, cultural tourism, education, supply chains — each industry has different boundaries for data usage and payment logic.

Therefore, when data-driven teams migrate towards AI, it is best not to aim for an all-encompassing platform right from the start. A more realistic path is to first select a vertical scenario, solve a specific data querying problem, and then gradually expand to a larger data collaboration network.

Identity and Account Infrastructure Teams: From Wallet Addresses to Agent Identities and Permissions

Many teams in Web3 are working on wallets, DID, account abstraction, permission management, developer tools, and on-chain identities. While many of these directions have not truly entered the mainstream market, these capabilities may become important again in the AI Agent phase.

Take OpenClaw as an example; users might ask it to complete a whole series of continuous tasks. For example, monitoring price changes of a certain product across different platforms, automatically organizing coupon and delivery information, filtering the most suitable purchasing options, and alerting users to place an order when budgets and conditions are met; or asking it to help a small team gather competitive product information, organize social media content, generate draft materials, and then sync them to spreadsheets or task systems.

These tasks may appear to be simply "automation," but they often require many permissions behind the scenes. An agent might need to access the browser, login status, order pages, email notifications, file systems, third-party plugins, and even invoke local scripts and external APIs. If the boundaries for authorization are not precise enough, while a user might only want to assign a specific task to the agent, it may inadvertently access more account data, browser credentials, file contents, and permissions from external services. Consequently, the agent might execute incorrect operations on behalf of the user, invoke tools that should not be called, read data that should not be accessed, and it could also expose sensitive information if there are vulnerabilities in the plugins, scripts, or external services.

Therefore, agents cannot rely solely on a standard login account for management. They require a finer identity, authorization, and auditing mechanism. They need to clarify who they act on behalf of, what data they can read, what tools they can call, how long permissions remain effective, whether they can be retracted, how execution processes are logged, and how issues can be traced back; all of these need to be productized.

For Web3 teams focusing on wallets, DID, account abstraction, and permission management, they can initially approach the agent's account, authorization, and execution records. Specifically, they can start from three types of products.

• The first type is an agent permission wallet, which provides usable permission accounts for agents. Users can set which data the agent can access, which tools it can invoke, what the single-task budget is, and when permissions expire. If the agent needs to perform operations outside its scope, it will require user re-confirmation.
• The second type is an agent behavior record and audit panel. Many enterprises are hesitant to grant AI direct access to internal systems. They need to know what the agent did at each step, which APIs were called, what files were read, whether there was any overreach, and where tasks failed. This type of product can initially serve enterprise AI assistants, automated operational tools, customer service systems, and developer workflows.
• The third type is a developer-focused agent permission SDK. Many AI application teams may develop agents on their own but may not have the capability to handle complex authorization, retraction, budget control, and log retention. Web3 infrastructure teams can encapsulate their past experience in wallet connections, account abstractions, and signature authorizations into developer tools, making it easier for AI applications to integrate fine-grained permission management.

The paying entities in this path are also relatively clear. End users may not pay solely for "agent identities," but enterprises, developer platforms, AI application teams, and automated workflow tools will have real needs concerning security and permissions. Especially in scenarios like finance, cross-border e-commerce, enterprise services, investment research, customer service, and marketing automation, as long as agents begin to interface with accounts, data, and payments, a permission system is hard to be absent.

For Chinese Web3 teams, this direction is also more feasible. Directly creating a general agent platform requires capabilities in modeling, products, distribution, and scenarios; building the permission layer, account layer, and auditing layer for agents is actually closer to the infrastructure business that Web3 teams are familiar with. They can start with plugins, SDKs, enterprise privatized deployments, or services for overseas developers, rather than immediately launching a large platform.

Another point to note is to avoid framing this direction as a grand "Agent economy." Currently, clients are more concerned with specific practical issues rather than grand narratives: Can an agent only access necessary permissions? Can permissions be retracted at any time? Can the execution process leave a trace? Can responsibilities be located if something goes wrong? If the product can first solve these issues, the identity and account teams will have an opportunity to find their real position in the AI migration.

Payment and Wallet Teams: From Crypto Payments to Agent Automated Settlements

Crypto payments, stablecoin settlements, wallet accounts, merchant acquiring, on-chain accounting, and API billing have always been important infrastructure directions within Web3. Although these areas have very clear regulatory boundaries in mainland China, from the global market perspective, payments and settlements remain one of the most realistically demanded directions in Web3.

The emergence of AI Agents may bring new application scenarios for these capabilities.

If an agent is merely answering questions, it does not require a complex payment system. But if an agent starts to automatically call APIs, purchase data, subscribe to tools, execute tasks, complete price comparisons, and pay service fees, payments will extend from “human clicking to pay” to “machine settling according to rules.”

This will raise many new questions, such as how much money can the agent spend? Who authorized it? How is billing calculated each time a service is called? How to settle low-value high-frequency API calls? How to handle payment failures? How to intercept abnormal payments? How to audit accounting records? How to clear between different platforms?

Traditional payment systems can of course cover some aspects of automatic deductions and subscription scenarios, but in high-frequency, low-value, cross-platform, machine-triggered service calls like AI agents, traditional payment systems may seem cumbersome. Account registration, bank card binding, pre-charging, cross-border settlements, merchant access, refunds, and risk controls can complicate what should be a light API call.

This is also why crypto payments are being discussed again. Stablecoins, programmable payments, on-chain accounting, and micropayments can bring service calls and payment settlements closer to being the same action. When an agent calls an API to complete a data request and triggers a small payment, the entire process can be recorded, billed, and audited.

The emergence of protocols like x402 is precisely focused on this issue. According to the introduction in the Coinbase developer documentation, typical use cases for x402 include pay-per-use API, AI agent automatic payment of API access fees, digital content paywalls, and monetization of microservices and tools through micropayments. In simple terms, it wants to solve a very specific problem: when an AI agent or program calls a certain service, can it complete a small payment directly during the request process, rather than first registering an account, binding a credit card, pre-charging, or going through complex manual approvals?

Payment and wallet teams can look at directions including agent payment accounts, budget controls, API micropayments, billing for calls, automatic deductions, interception of anomalies, and accounting audits.

For example, when an AI agent subscribes to a data service for users, it can set a monthly budget; when calling external APIs for enterprises, it can automatically settle based on the number of calls; when executing tasks for developers, it can trigger payments based on task results; during call anomalies, it can automatically pause payments and leave a record.

If such scenarios actually occur, payment will no longer just be an action at the end of a transaction, but will become part of the agent's workflow.

However, Web3 teams in mainland China are not suitable for directly providing crypto payments to domestic users nor for dealing with token issuance, transaction matching, capital pools, yield promises, and unlicensed payment businesses. A more realistic path is to provide technical services, risk control modules, accounting systems, overseas B2B clients, or services for compliant entities in Hong Kong, Singapore, etc.

Therefore, if such teams wish to migrate towards AI, it's best to initially focus on overseas developer tools, data services, AI plugin platforms, API markets, and enterprise automation scenarios. These scenarios inherently require billing for calls and are more accepting of stablecoins or programmable settlement solutions. For instance, AI data services could charge per use, developer tools could charge based on call volume, and enterprise automation processes could settle based on task results.

For payment and wallet teams, the real task is to identify a specific scenario that already has existing calling behaviors, billing needs, and settlement frictions. Once the scenario runs smoothly, account, authorization, accounting, and risk control capabilities have the opportunity to transform into a business.

To Be Continued

If one views AI as an entirely new industry, most Web3 teams would feel unfamiliar. Models, computing power, training data, AI product experiences — these are not the most familiar fields for traditional Web3 teams. But looking from another angle, once AI enters task execution, automated workflows, and the agent phase, the problems it needs to address are actually related to many capabilities that Web3 teams have accumulated over the past few years.

Data solves whether AI can obtain finer-grained and more compliant data; identity and accounts solve whether agents can operate under explicit authorization; payments and wallets solve how to settle and audit after machine service calls. These areas allow Web3 teams to not start from zero in AI, nor do teams need to develop general large models right away or directly compete for AI application entry points, but rather apply the infrastructure capabilities that have already been built up in recent years to address the infrastructure gaps appearing alongside AI agents.

In the next article, Portal Labs will continue to discuss migration paths for two other types of teams, as well as which AI directions may seem hot but are not suitable for most Chinese Web3 teams to enter. Stay tuned.

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