AI Agent Economic Infrastructure Research Report (Part 2)

This article is an in-depth research report produced by OKX Ventures. Due to its length, it will be published in two parts: Part 1 focuses on the macro background, x402 protocol, ERC-8004 and Virtuals Protocol ( click here to jump ); Part 2 will focus on analyzing OpenClaw and overall industry trends.

Chapter 5 OpenClaw: Special Research on Application Ecosystem

5.1 Project Background and Outbreak

In November 2025, Austrian developer Peter Steinberger posted a weekend project on GitHub. Four months later, in March 2026, this project surpassed React to become the most-starred software project in GitHub history—with over 250,000 stars, a number that took React 13 years to reach.

In the broader trend of AI products evolving from passive tools to proactive agents, OpenClaw's approach is to proactively help users on their existing platforms, rather than waiting for them to seek it out. It resides on the user's computer and connects to over 20 channels, including WhatsApp, Telegram, Slack, Discord, Signal, iMessage, and Lark, operating email, calendar, browser, file system, and code editor via the MCP protocol. Andrej Karpathy coined the term "Claws" for this type of system; a local AI agent that runs in the background, autonomously making decisions and executing tasks. This term quickly became the common way to describe locally hosted AI agents in Silicon Valley.

Every major model release highlights Agent capabilities because Agents are the demand multiplier justifying investments in AI infrastructure: a single chat query consumes hundreds of tokens, while an Agent run with tool calls and multi-step inference consumes tens to hundreds of thousands of tokens.

Although the founders prohibited discussion of cryptocurrencies on Discord, the Crypto community spontaneously built a complete on-chain economic infrastructure on top of OpenClaw: token issuance, identity registration, payment protocols, social networks, reputation systems, and more. The emergence of OpenClaw allowed us, for the first time, to observe the interaction between agents and on-chain infrastructure in a real, large-scale scenario and provided the Crypto community with a host with a real user base for attaching economic activities.

5.2 Technical Architecture Analysis

First layer: Communication channels – Identity issues

OpenClaw connects to 20+ platforms simultaneously. From the agent's internal perspective, it knows it's the same entity, with a unified memory, unified configuration, and a unified SOUL.md. But from the outside, how can others know that the agent on Telegram and the agent on Discord are the same? Each platform has its own user ID system, and the two platforms are not interoperable and cannot view behavior records. This is precisely the core problem that ERC-8004 attempts to solve.

Second layer: Gateway – Security issues

The Gateway is the brain and dispatch center of OpenClaw: it routes user messages to the correct Agent, loads the Agent's session history and available skills, and defines permission boundaries before the Agent even begins to think (whitelist mechanism: when a message arrives at the Gateway, the system dynamically generates a tool whitelist based on information such as the message source channel, user ID, and group ID. Only tools on the whitelist are injected into the Agent's context. The Agent cannot see tools outside the whitelist, and therefore cannot invoke them).

The advantage of this design is its proactive security. However, its access control relies entirely on the Gateway as a single point of failure. If compromised or misconfigured, the Agent may gain unauthorized privileges.

The third layer: Agent core (ReAct loop) – predictability issues

The Agent's operational logic is a ReAct (Reasoning + Acting) loop: receive input → think (call LLM) → decide on action → call tools → obtain results → think again → loop. OpenClaw's engineering optimizations include: high-frequency message scheduling (four strategies: Steer/Collect/Followup/Interrupt), LLM two-layer fault tolerance (authentication rotation + model degradation), and an optional hierarchical thinking mechanism (6 levels).

However, LLM is probabilistic in nature and its output is uncertain. Agents are nondeterministic executors, making irreversible actions in nondeterministic environments.

First, there's the loss of constraints due to context compression: security constraints are themselves part of the context, and when the context is lossily compressed, security constraints may be discarded. Second, there's prompt injection: someone intentionally embeds hidden instructions within content that the agent will process, causing the agent to execute the content as if it were a user command. The common root of both is that the boundaries of agent behavior are defined using natural language, which is ambiguous, manipulable, and susceptible to lossy compression.

One example is that Summer Yu, the alignment director of Meta's Super Intelligence Lab, asked the Agent to "suggest some emails that can be deleted," but the Agent directly deleted hundreds of emails (the context window overflow triggered compression, and the key constraint of "suggest" was discarded).

In this context, what we need is not better prompt engineering, but structural security mechanisms: auditable operation logs, programmable permission boundaries, and an economic system that allows for accountability and compensation in case of errors. These are precisely what smart contracts and on-chain infrastructure excel at.

Fourth layer: Memory system – issues of persistence and transferability

OpenClaw implements two types of memory: daily working memory (YYYY-MM-DD.md file) and long-term essential memory (MEMORY.md, key preferences extracted through deduplication and categorization). Retrieval uses a hybrid mode of vector retrieval and BM25.

The session resets by default at 4 AM daily. The context window is continuously compressed and summarized. When the context window approaches the token limit, OpenClaw triggers session compression, using LLM to summarize previous conversations into shorter versions. Before compression, a memory flush is performed, giving the agent a chance to write critical information into persistent memory. This essentially gambles on the agent knowing what information is critical. A non-deterministic system determining what constitutes critical information is inherently uncertain.

OpenClaw stores all its memories on the local file system, meaning they are lost when switching computers; there is no shared memory mechanism when collaborating with other agents; and an agent's knowledge and experience are locked to the machine it runs on. Sub-Agent collaboration is limited to within the same OpenClaw instance; the system is powerless when it comes to agent collaboration across instances or organizations. Developer feedback on GitHub indicates that decision records are in the chat history but not persisted artifacts, leading to unclear handover and incomplete knowledge transfer.

5.3 Structural Problems in Agent Economy

Context not flowing: the root of all problems

• Spatial locking: The agent's memories and knowledge reside on the machine that runs it; switching to another computer will erase them.

• Trust isolation: Agent A claims "the user mentioned preference X last week," but Agent B has no way to verify this claim.

• Undiscoverable: Looking for an agent "skilled in DeFi analytics"? There's no standardized discovery mechanism.

• Value Unpriced: The domain knowledge and user preferences accumulated by agents clearly have economic value, but there is currently no way to price or trade them.

• Default temporary: The context may be compressed, digested, or lost at any time during a session reset.

For context data to truly circulate, it needs to possess five attributes simultaneously: the ability to cross trust boundaries, economic value, discoverability without a gatekeeper, retention of decision-making traces, and adaptability to consumer needs. Currently, no single protocol can provide all five attributes simultaneously. MCP addresses "how AI models call tools." A2A addresses "how agents communicate with each other." x402 addresses "how agents pay." However, the question of "how agents autonomously discover, evaluate, and use context data in untrusted environments" remains unanswered.

Coordination Paradox

An agent only needs sufficient context to reason. But cross-organizational coordination requires all historical context.

An agent deciding "should I book this flight?" only needs a concise summary of the current session's information. But when it needs to coordinate with supply chain agents, financial agents, and calendar agents (potentially on different platforms and operated by different organizations): What context do they share? How is verification performed? Who owns the data?

Gartner predicts that by 2027, over 40% of agentic AI projects will be canceled due to rising costs, unclear business value, or insufficient risk control. However, 70% of developers report that the core issue is integration problems with existing systems. The root cause is that agents are non-deterministic executors, while enterprises require deterministic results. An uncertain executor collaborating with uncertain partners in an uncertain environment, without a verifiable layer of trust, cannot produce reliable outputs.

Currently, the demand for cross-platform agent collaboration is still very small. Users simply want an AI that can do the work for them, regardless of its ability to collaborate with other agents. The coordination paradox is a real technical problem, but whether it will evolve into a large-scale commercial problem depends on whether the way agents are used evolves from personal tools to multi-agent collaborative networks.

Combining the above analyses, we arrive at an architectural concept:

The lower layer is where the agent performs reasoning; it's ephemeral and token-bound. OpenClaw, Claude Code, and Cursor all reside here. It requires rapid response and focus on the current task.

The upper layer is where coordination takes place: it is enduring, verifiable, and economically priced. Cross-organizational knowledge is accumulated here, traceability chains are maintained here, and credibility operates here.

The two layers have different needs: agents require simplicity, while organizations need historical records. Agents need speed, while audit trails need permanence. Agents operate probabilistically, while enterprises need deterministic results. Most current architectures attempt to merge the two layers, but this is unlikely to succeed.

Could we add a modular, permissionless, horizontally deployable component suitable for all agent systems—possessing trusted neutrality, persistence, and verifiability? This component provides a controlled interface between upper and lower layers, allowing context to flow downwards when needed and upwards when commitments are made. Before execution, relevant context subgraphs are parsed and injected from a decentralized knowledge graph; after execution, the operation is submitted on-chain as a verifiable transaction, along with proof and reputation updates. The core assumption of this layer is also that context liquidity is valuable: if most agent users do not need cross-platform collaboration (e.g., one person uses only one OpenClaw for everything), then there is no real need for the middle layer.

If the middleware layer only focuses on context portability, it's highly likely to fail. However, if it focuses on use cases with clear economic incentives, such as the verifiability of economic activities and the transferability of reputation in scenarios where multiple parties distrust each other, the probability of success is much higher. IronClaw is also an attempt to move towards an abstract middleware layer—separating the execution environment and credential management into a verifiable security layer. However, it remains an internal solution within the Near ecosystem and lacks cross-platform versatility.

The real entry point for Crypto

Most of the needs of the agent economy can actually be solved using Web2 solutions. Crypto's irreplaceable role in the agent economy exists only in one scenario: when you need cross-organizational, cross-platform, permissionless interoperability, and the participants do not have a pre-established trust relationship. For example, Agent A (running on OpenClaw, owner is user A) needs to hire Agent B (running on Claude Code, owner is user B) to complete a task. They have no common platform, no common account system, and no pre-existing business relationship. In this scenario, on-chain identity (8004), on-chain payments (x402), and on-chain reputation are indeed more suitable than any centralized solution—because no centralized platform can simultaneously cover all agent frameworks.

Furthermore, just because an agent can pay doesn't mean it should. F500 companies lost $400 million because their agents repeatedly paid in retry loops. Once agents can make payments independently, the most valuable asset is the decision-making infrastructure that helps them determine whether or not they should pay.

Currently, Crypto is "nice to have" for Agent economics, unless cross-platform economic interactions between Agents reach a sufficient scale. However, when enough Agents are no longer linked to a specific human bank account (Agents themselves become independent economic entities rather than human tools), traditional financial mechanisms will no longer cover them. At this point, stablecoins become the best (and perhaps only) way for them to conduct large-scale financial transactions. Three possible triggers for Crypto to become "must have":

1. Agents began to hire other agents on a large scale: for example, agent systems from different vendors in an enterprise IT environment needed to interoperate (similar to today's enterprise API integration, but more complex).

2. Agents enable 24/7 cross-border transactions: A workflow orchestrated by an agent may simultaneously call LLM endpoints in the US, data providers in Europe, and computing clusters in Southeast Asia, without requiring three different payment tracks. Stablecoins are global and available 24/7. This advantage is even more pronounced than for humans in agent-always-on, cross-timezone scenarios.

3. Micropayments are reaching a frequency that traditional payment methods cannot handle: Currently, the average cost of microtransactions (API calls, data queries, computing resources) made by agents on the blockchain is only $0.09 per transaction, while Stripe's transaction fees alone are $0.35 + 2.5%, which is 4 times more expensive than the transaction itself. When an agent needs to make tens of thousands of API calls, traditional payment processors cannot cover the risks of such merchants, and the fee structure will become a real bottleneck.

Security threats and the necessity of on-chain infrastructure

The "Siri paradox" is a key framework for understanding the entire Agent race: Siri is safe because it's been crippled, and OpenClaw is useful because it's dangerous. For AI to actually do anything (process emails, book flights, deploy code), it must have broad system privileges. Broad privileges naturally mean a larger attack surface.

The most famous positive example on OpenClaw is this: a user asked an agent to book a restaurant, but OpenTable was full. Instead of giving up, the agent found AI voice software, downloaded and installed it, and called the restaurant to successfully make the reservation. This ability to solve problems autonomously is something people dream of. However, this same autonomy also means that if a judgment is wrong, the consequences spread at machine speed.

Some have called Steinberger's joining OpenAI the "iPhone moment for AI Agents." But before that, a phase where a secure infrastructure is in place is necessary. Otherwise, large-scale adoption will result in large-scale losses. If Chopping Block's predicted "AI-generated $100M+ hacks" do indeed occur, there are two possible outcomes: either public panic leads to a regression in Agent adoption (similar to the Ethereum slump after the 2016 DAO incident), or it spurs the development of a truly secure Agent infrastructure (similar to the explosion of the smart contract auditing industry after the DAO incident). We lean towards the latter because the need for Agents is real:

• Malicious Agent Identification >> 8004 Reputation System. If each agent has an on-chain identity and a publicly available reputation record, malicious behavior will leave an immutable record. Other agents can check the on-chain reputation before trusting the agent. Of course, the reputation system needs to be sufficiently mature—not just a simple rating, but a multi-dimensional, time-weighted trust model with anti-ranking manipulation mechanisms.

• Malicious Skills audit >> Validation Registry. If the Skills' code audit results are recorded in the Validation Registry (version 8004)—audited by independent validators (staked service, zkML validator, TEE oracle)—the effectiveness of typosquatting is significantly reduced. Check the on-chain validation status before installing the Skill.

• Credential leakage >> x402's "Pay-as-Authorize" mechanism. x402 eliminates API Key management issues. Agents don't need to store long-term credentials—they directly pay for temporary access each time a service is needed. Combined with EIP-712 signature binding (linking service access to the payment address), even if the token is leaked, it cannot be used by others.

• Out-of-control behavior >> On-chain audit logs + programmable permissions. Whether it's an external attacker injecting instructions (prompt injection) or the system itself losing constraints during compression (context loss), the result is that the agent executes actions beyond expectations. Smart contracts can define the boundaries of agent behavior—such as "a single transaction cannot exceed X amount" or "deletion operations require multi-signature confirmation." On-chain operation logs are immutable, and problems can be traced. This is far more reliable than adding "please seek consent first" to the prompt, because prompt-level constraints are lost during compression, but smart contract-level constraints are not.

Of course, on-chain infrastructure can only mitigate the consequences of security problems, not prevent them. Smart contracts can limit a single transaction to "no more than X amount," but what if an agent, after being injected, continues to commit malicious acts within that limit? Even if each malicious transaction of $0.09 is repeated 10,000 times, that's still $900. A true solution to security requires a two-pronged approach: at the agent runtime layer (TEE/sandbox) and at the on-chain layer (permissions/auditing). Focusing solely on the on-chain layer is insufficient.

Chapter Six: Comprehensive Industry Analysis

Traditional technological moats (engineering capabilities, team size, execution efficiency) are being homogenized by AI tools. Anyone with an idea can create a product prototype in a very short time using OpenClaw or Claude Code. This means:

• Small teams have a shorter window of opportunity than ever before (large teams can catch up much faster using the same tools).

• The first-mover advantage is more valuable at the idea level than ever before because your agent can iterate faster than any competitor.

• The scarcest resource is not technical skill, but the ability to judge the right questions.

The real competition in the market isn't within Crypto itself.

Many people are comparing which L1/L2 platform performs better as an agent—Base vs. Solana vs. Ethereum vs. Near. But the real competition lies between Crypto solutions and Web2 solutions.

For example, Sapiom received $15.75 million to manage agent service access for Web2. In an extreme case, if Sapiom's solution is good enough—the agent gains access to all Web2 services through it without touching on-chain payments—then x402 would be unnecessary. Stripe's virtual card solution could sustain its second phase for longer if it could resolve anti-automation issues through commercial negotiations (persuading merchants to remove CAPTCHA for specific virtual cards). This is the battleground currently being fought over by Visa, Mastercard, and Stripe: controlled agents within authorized scope. The core is virtual cards + dedicated payment APIs. This shifts the trust relationship from "trusting an uncertain AI" to "trusting a payment tool with defined parameters controlled by the issuing institution." Currently, it's best suited for large-scale applications, but as B2B agent scenarios grow to another scale, the programmability of authorization information and the data volume limitations of bank cards will become bottlenecks.

The premise for x402's success is that its "payment equals authorization" model outperforms the "middle-tier proxy management" model in terms of cost, latency, and developer experience. Currently, x402 has an advantage in micropayment scenarios (as low as $0.001 per transaction), but it may not be as good as Web2 solutions in enterprise scenarios requiring complex permission management.

Similarly, the premise for 8004 to succeed is that on-chain identity and reputation are more useful than centralized platform-managed identity systems (such as ClawHub's own verification mechanism). Currently, 8004 adoption is not widespread enough, and checking on-chain reputation is not as user-friendly as checking platform ratings. Meta's acquisition of Moltbook was also driven by its focus on the underlying capabilities of Agent authentication and the registry (directory), aiming to control the Agent identity layer.

Crypto solutions cannot be content with being theoretically better. They must catch up with or even surpass Web2 solutions in terms of developer and user experience. Otherwise, they will end up like many crypto products: the decentralized concept is great, but they are too cumbersome to use and no one adopts them.

Traditional payment giants have defined the adoption timeline.

The market will evolve in three phases. In the next 3-5 years, Stripe/Visa will dominate the early market—offering unparalleled backward compatibility, allowing agents to instantly transact with millions of merchants worldwide that already accept credit cards. After 5 years, the pain points of the second phase will accumulate to an unbearable level—a lack of programmable authorization systems, the inability to build sufficiently comprehensive agency IDs, high microtransaction fees, and slow cross-border settlements—naturally shifting the market to the third phase: Crypto infrastructure.

This means that Crypto doesn't need to defeat Stripe today. Instead, it needs to perfect its infrastructure over the next 3-5 years, ready to take over when the second phase of the solution reaches its peak. We're currently in an infrastructure-building race, not yet a market share battle. Of course, infrastructure needs to be in place in advance, but infrastructure alone won't automatically lead to adoption; an application-layer explosion is needed to activate it. TCP/IP was invented in the 1970s, but it wasn't widely used until the advent of web browsers in the 1990s. Currently, we can see the infrastructure gradually improving, but no one is using it on a large scale. For example, x402 will be a technically usable protocol for most of 2025, but lacks a killer use case. We need more applications to emerge, connecting this infrastructure into a usable stack. The explosion of OpenClaw/Moltbook is the first demand engine we've seen—suddenly, hundreds of thousands of agents need payment, identity, and reputation; x402 and 8004 went from being usable to being used.

Selling shovels is more profitable than panning for gold.

The entire Base lobster ecosystem validates an ancient investment wisdom: during a gold rush, the most reliable way to make money is by selling shovels.

Felix earned $75,000. But Clanker earned far more in fees from 64,000 token deployments. ClawRouter sells LLM routing services ($0.003/request). ClawCloud sells agent computing power. Venice sells inference credits and financializes computing power through the VVV/DIEM model. The business models of these infrastructure providers are far more mature and reliable than agents earning money independently.

The common infrastructure required by all agent categories—identity, payment, security, coordination, and computing resources—is essential regardless of which agent framework prevails (OpenClaw, IronClaw, or OpenAI's next-generation product). Karpathy's coinage of the term "Claws" captures a larger trend than OpenClaw—localized, persistent, and autonomous AI agents constitute a category, and cryptocurrency infrastructure aims to serve the entire Claw category. IronClaw (Near's TEE-secured version), various enterprise-customized agent frameworks, and OpenAI's upcoming integrated agent all belong to this category. OpenClaw is a pioneer in this category, but it won't be the only one.

Product-Agent Fit will replace Product-Market Fit

Multiple platforms (Taobao, Xiaohongshu, Weibo, Xueqiu) have begun banning OpenClaw user accounts because the agent bypassed these platforms' anti-scraping mechanisms by simulating browser operations. Platforms and agent users are inherently adversaries. The platform's business model relies on the attention of human users, while agent users consume data but do not generate advertising value.

Traditional marketing relies on the attention economy—exquisite images, video ads, and limited-time offers—strategies targeting impulsive consumer spending. Agents, on the other hand, are absolutely rational decision-makers, focusing solely on the clarity and completeness of API-returned data. They compare product specifications, historical prices, logistics timeliness, user reviews, and even carbon footprint. They don't engage in mindshare. The future competitive advantage won't be brand (Agents don't recognize brands) or UX (Agents don't use interfaces), but rather the degree of data structuring, API stability, MCP compatibility, and verifiable on-chain service quality records.

The internet business model may be shifting towards pay-per-scraping, where agents, as service consumers, will no longer rely on a free model supported by advertising, but will instead pay directly for data retrieval: each data query, each API call, and each service use will require a small direct payment to help the agent legally access platform data. This is precisely the problem that x402 addresses: obtaining data access rights through direct payment and supporting microtransactions. And this early form has already emerged: Lord of a Few launched over 80 paid x402 endpoints within a week, each with a $0.50 build cost and charging a few cents to tens of cents.

Furthermore, when both the buyer and seller are agents, how is the profit pool redistributed?

Conclusion

We are in a rare window of opportunity: the infrastructure is in place, but the killer app has yet to arrive. History has proven time and again that true change doesn't announce itself in advance—it only happens unexpectedly, suddenly making everyone realize that the old world is over.

Partial References

[1] McKinsey & Company, "The Agentic Commerce Opportunity," 2025. https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-agentic-commerce-opportunity

[2] Morgan Stanley Research, "AI Agentic Shoppers: The Next Frontier of E-Commerce," 2025.

[3] Edgar Dunn & Company, "Agentic Commerce: The Future of AI-Driven Retail," 2025.

[4] Dune Analytics — x402 Transactions per Project Dashboard

[5] Artemis Analytics — app.artemisanalytics.com/asset/x402

[6] x402 White Paper — x402.org

[7] EIP-8004 — ethereum-magicians.org

[8] ERC-8183 — ETH Foundation dAI Team, March 2026

[9] Virtuals Protocol Documentation — virtuals.io

[10] SecurityScorecard — OpenClaw Exposure Report, 2026.03

[11] The Block, Phemex, Allium Labs — Various x402 Data Reports

[12] MarketsandMarkets, "Agentic AI in Retail and eCommerce Market Report," 2025.