AI Agent Economic Infrastructure Research Report (Part 2)

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

Chapter 5 OpenClaw: Specialized Research on the Application Ecosystem

5.1 Project Background and Explosive Growth

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

Amid the major trend of AI products evolving from passive tools to active Agents, the change OpenClaw makes is: the AI no longer waits for the user to find it, but proactively helps the user on the user's existing platforms. It resides on the user's computer, simultaneously accessing over 20 channels including WhatsApp, Telegram, Slack, Discord, Signal, iMessage, Lark, etc., and operates email, calendar, browser, file system, and code editor through the MCP protocol. Andrej Karpathy coined a term for this type of system: Claws; locally hosted AI Agents that run in the background loop, capable of autonomous decision-making and task execution. This term quickly became the common term for locally hosted AI Agents in Silicon Valley.

Every major model release headlines Agent capabilities because Agents are the demand multiplier that justifies AI infrastructure investment: one chat consumes a few hundred tokens, while one Agent run with tool calls and multi-step reasoning consumes tens of thousands to hundreds of thousands of tokens.

Although the founder banned discussions about cryptocurrency on Discord. The Crypto community spontaneously built a complete set of on-chain economic infrastructure on top of OpenClaw: token launches, identity registration, payment protocols, social networks, reputation systems, etc. The explosion of OpenClaw allows us, for the first time, to observe the interaction methods between Agents and on-chain infrastructure in a real, large-scale scenario and provides the Crypto community with a host with a real user base to attach economic activities to.

5.2 Technical Architecture Analysis

First Layer: Message Channels — The Identity Problem

OpenClaw simultaneously accesses 20+ platforms. From the Agent's internal perspective, it knows it is the same entity, with unified memory, unified configuration, and a unified SOUL.md. But from an external perspective, how do others know that this Agent on Telegram and that Agent on Discord are the same? Each platform has its own user ID system; platforms do not interconnect and cannot view behavioral records. This is precisely the core problem ERC-8004 attempts to solve.

Second Layer: Gateway — The Security Problem

The Gateway is the brain and scheduling center of OpenClaw: it routes user messages to the correct Agent, loads that Agent's conversation history and available Skills, and defines the permission boundary before the Agent starts thinking (whitelist mechanism: when a message arrives at the Gateway, the system dynamically generates a tool whitelist based on information like the message source channel, user ID, group ID, etc. Only tools on the whitelist are injected into the Agent's context. The Agent simply doesn't see tools outside the whitelist, so it cannot call them).

The benefit of this design is security by default. But its permission control relies entirely on the Gateway as a single point; if compromised or misconfigured, the Agent could obtain permissions it shouldn't have.

Third Layer: Agent Core (ReAct Loop) — The Predictability Problem

The Agent's operating logic is the ReAct (Reasoning + Acting) loop: receive input → think (call LLM) → decide on action → call tool → get result → think again → loop. Engineering optimizations made by OpenClaw include: high-frequency message scheduling (Steer/Collect/Followup/Interrupt four strategies), LLM two-layer fault tolerance (authentication rotation + model degradation), and an optional thinking level mechanism (6 levels).

But the LLM is probabilistic in nature; its output is uncertain. The Agent is a non-deterministic executor, making irreversible actions in a non-deterministic environment.

First is constraint loss due to context compression: security constraints are also part of the context; when the context is lossily compressed, security constraints may be discarded. Second is prompt injection: someone intentionally embeds hidden instructions in content the Agent will process, causing the Agent to treat the content as user commands. The common root of both is: the Agent's behavioral boundary is defined using natural language, and natural language is ambiguous, manipulable, and susceptible to lossy compression.

An example is Meta's Superintelligence Lab alignment lead Summer Yu asking an Agent to "suggest some emails that could be deleted," but the Agent directly deleted hundreds of emails (context window overflow triggered compression, and the key constraint "suggest" was lost).

In this case, what we need is not better prompt engineering but structural security mechanisms: auditable operation logs, programmable permission boundaries, and an economic system for accountability and compensation when things go wrong. These are things smart contracts and on-chain infrastructure happen to be good at.

Fourth Layer: Memory System — The Persistence and Portability Problem

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

Sessions are reset by default at 4 AM daily. The context window is constantly compressed and summarized. When the context approaches the token limit, OpenClaw's approach is to trigger session compression, using the LLM to summarize previous conversation into a shorter version. Before compression, it performs a Memory Flush, giving the Agent one chance to write key information to persistent memory. This essentially bets that the Agent itself knows what information is key. A non-deterministic system judging what is key information is itself uncertain.

All OpenClaw memory is stored on the local file system; it's gone if you change computers; there is no shared memory mechanism when collaborating with other Agents; the 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 once cross-instance, cross-organizational Agent collaboration is involved. Feedback from developers on GitHub: decision records are in chat history but not persisted as artifacts, handover is vague, knowledge transfer is incomplete.

5.3 Structural Problems of the Agent Economy

Context Immobility: The Root of All Problems

• Spatial Lock-in: The Agent's memory and knowledge reside on the machine running it; gone if you change computers.
• Trust Isolation: Agent A claims "the user stated preference X last week," Agent B has no way to verify the truth.
• Unable to Discover: Want to find an Agent "good at DeFi analysis"? No standardized discovery mechanism.
• Value Not Priced: The domain knowledge and user preferences accumulated by the Agent clearly have economic value, but currently no way to price or trade it.
• Default Ephemeral: Context can be compressed, summarized, or lost at session reset at any time.

For context to truly flow, it needs to simultaneously possess five attributes: able to cross trust boundaries, have economic attributes, discoverable without a gatekeeper, retain decision traces, and adapt to consumer needs. Currently, no single protocol provides all five attributes. MCP solves "how AI models call tools." A2A solves "how Agents talk to Agents." x402 solves "how Agents pay." But "how Agents autonomously discover, evaluate, and use contextual data in untrusted environments" has no answer yet.

The Coordination Paradox

An Agent only needs enough context to reason. But cross-organizational coordination requires all historical context.

An Agent thinking "should I book this flight?" needs just the streamlined information from the current session. But when it needs to coordinate with a supply chain Agent, a finance Agent, a calendar Agent (possibly on different platforms, operated by different organizations): what context do they share? How is it verified? Who owns it?

Gartner predicts that by 2027, over 40% of Agentic AI projects will be canceled due to ever-increasing costs, unclear business value, or insufficient risk control. But 70% of developers report the core problem is integration issues with existing systems. The root cause is, Agents are non-deterministic executors, and businesses want deterministic outcomes. An uncertain executor collaborating with uncertain collaborators in an uncertain environment, without a verifiable trust layer, cannot produce reliable output.

Currently, the demand for cross-platform Agent collaboration is very small. Users just want an AI that can help them get things done; they don't care if it can collaborate with other Agents. The coordination paradox is a real technical problem, but whether it evolves into a large-scale commercial problem depends on whether Agent usage evolves from personal tools to multi-Agent collaboration networks.

Combining the above analysis yields an architectural concept:

The bottom layer is where Agents reason: ephemeral, token-bound. OpenClaw, Claude Code, Cursor operate here. Needs fast response, focused on the current task.

The upper layer is where coordination happens: persistent, verifiable, economically priced. Cross-organizational knowledge accumulates here, provenance chains are maintained here, reputation operates here.

The two layers have different needs: Agents need conciseness, organizations need historical records. Agents need speed, audit trails need permanence. Agents operate probabilistically, businesses need deterministic results. Most current architectures try to merge the two layers, which cannot succeed.

So, can we add a modular add-on, deployed horizontally without permission, applicable to all Agent systems—with credible neutrality, persistence, and verifiability? This component provides a controlled interface between the upper and lower layers, allowing context to flow down when needed and commitments to flow up when made. Before execution, parse and inject the relevant context subgraph from a decentralized knowledge graph; after execution, submit the operation as a verifiable transaction on-chain,附带溯源(provenance) and reputation updates. The core assumption of this layer is also that context liquidity has value: If most Agent users don't need cross-platform collaboration (e.g., one person uses only one OpenClaw for everything), then the middle layer has no real demand.

If the middle layer only does context portability, it will likely fail. But if it focuses on use cases with clear economic incentives, like verifiability of economic activities and portability of reputation in multi-party, mutually distrustful scenarios, the probability of success is much higher. IronClaw is also an attempt in the direction of an abstract middle layer—separating the execution environment and credential management into a verifiable security layer. But it is still a solution internal to the Near ecosystem, lacking cross-platform universality.

Crypto's Real Entry Point

Most Agent economy needs can actually be solved with Web2 solutions. Crypto's irreplaceability in the Agent economy exists only in one scenario: when you need cross-organizational, cross-platform, permissionless interoperability, and there is no pre-established trust relationship between participants. 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 share no common platform, no common account system, no pre-existing business relationship. In this scenario, on-chain identity (8004), on-chain payment (x402), and on-chain reputation are indeed more suitable than any centralized solution—because no centralized platform can cover all Agent frameworks simultaneously.

And, an Agent being able to pay doesn't mean it should pay. F500 companies lost $400 million due to Agents repeatedly paying in retry loops. After Agents can pay autonomously, the most valuable thing is the decision infrastructure that helps the Agent judge whether it should pay.

Currently, Crypto is "nice to have" for the Agent economy, unless cross-platform economic interaction between Agents reaches sufficient scale. But when enough Agents are no longer tied to a specific human's bank account (the Agent itself becomes an independent economic entity rather than a human tool), traditional financial rails can no longer cover them, and stablecoins become the best (and arguably the only) way for their large-scale fund transactions. Possible triggers for becoming a must-have:

1. Agents start hiring other Agents en masse: e.g., different vendors' Agent systems need to interoperate in enterprise IT environments (similar to today's enterprise API integration, but more complex).
2. Agents start 24/7 cross-border transactions: an Agent-orchestrated workflow might simultaneously call a US LLM endpoint, a European data provider, and a Southeast Asian compute cluster; it shouldn't need three different payment rails. Stablecoins are global, 7x24. This advantage is more pronounced for Agents' always-on, cross-timezone scenarios than for humans.
3. Micro-payments reach a frequency traditional rails cannot handle: Currently, micro-transactions Agents do on-chain (API calls, data queries, compute resources) average only $0.09 per transaction, while Stripe's fees alone are $0.35 + 2.5%, 4 times more expensive than the transaction itself; when an Agent needs to call an API tens of thousands of times, traditional payment processors cannot underwrite this type of merchant risk and the fee structure becomes a real bottleneck.

Security Threats and the Necessity of On-Chain Infrastructure

The "Siri Paradox" is a key framework for understanding the entire Agent赛道: Siri is safe because it's castrated, OpenClaw is useful because it's dangerous. For AI to truly do things (process emails, book flights, deploy code), it must have broad system permissions. Broad permissions naturally mean a larger attack surface.

The most famous positive case on OpenClaw is: a user asked an Agent to book a restaurant, but OpenTable had no availability; the Agent didn't give up, found AI voice software itself, downloaded and installed it, called the restaurant and successfully booked it. This kind of autonomous problem-solving ability is what people dream of. But the same autonomy means that if judgment fails, consequences spread at machine speed.

Some call Steinberger joining OpenAI the "iPhone moment for AI Agents." But before that, there must be a phase where the security infrastructure is ready. Otherwise, mass adoption means mass losses. If Chopping Block's predicted "AI-generated $100M+ hacks" actually happen, there are two directions: either public panic causes Agent adoption to regress (similar to the Ethereum low after the 2016 DAO incident), or it spawns real Agent security infrastructure (similar to the explosion of the smart contract audit industry after the DAO incident). We lean towards the latter. Because the demand for Agents is real:

• Malicious Agent Identification >> 8004 Reputation System. If every Agent has an on-chain identity and public reputation record, malicious behavior leaves an immutable record. Other Agents can check on-chain reputation before trusting. Of course, the reputation system needs to be mature enough—not a simple score, but a multi-dimensional, time-weighted, anti-sybil trust model.
• Malicious Skills Audit >> Validation Registry. If the code audit results of Skills are recorded in 8004's Validation Registry—audited by independent validators (staked services, zkML validators, TEE oracles)—the effectiveness of typosquatting is greatly reduced. Just check the on-chain verification status before installing a Skill.
• Credential Leakage >> x402's "Payment as Authorization". x402 eliminates the API Key management problem. The Agent doesn't need to store long-term credentials—it directly pays to obtain temporary access rights each time it needs a service. Combined with EIP-712 signature binding (binding service usage rights to the payment address), even if the token is leaked, it cannot be used by others.
• Behavioral Loss of Control >> 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 the Agent performing actions beyond expectations. Smart contracts can define the Agent's behavioral boundaries—e.g., "single transaction not exceeding X amount", "delete operations require multi-signature confirmation". On-chain operation logs are immutable, allowing tracing if problems occur. This is much more reliable than adding "please ask for consent first" in the prompt, because prompt-level constraints can be compressed away, but smart contract-level constraints cannot.

Of course, on-chain infrastructure can only mitigate the consequences of security problems, not prevent them. A smart contract can limit "no more than X amount per transaction," but what if the Agent, after being injected, continuously does bad things within the limit? Ten thousand malicious transactions at $0.09 each is still $900. A real solution for security requires efforts at both the Agent runtime layer (TEE/sandbox) and the on-chain layer (permissions/audit). Relying only on the on-chain layer is not enough.

Chapter 6 Comprehensive Industry Analysis

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

• The window of opportunity for small teams is shorter than ever (large teams using the same tools will catch up faster).
• The value of first-mover advantage at the idea level is higher than ever, because your Agent can iterate faster than any competitor.
• The scarcest resource is not technical ability, but judgment about the right problems.

The Real Competition is Not Within Crypto

Many people are comparing which L1/L2 does Agents better—Base vs Solana vs Ethereum vs Near. But the real competition is between Crypto solutions vs Web2 solutions.

For example, Sapiom raised $15.75M, working on a Web2 route for Agent service access management. In an extreme case, if Sapiom's solution is good enough—Agents get access to all Web2 services through it without needing to touch on-chain payments—then x402 becomes unnecessary. If Stripe's virtual card solution can solve the anti-automation problem through business negotiations (persuading merchants to remove CAPTCHA for specific virtual cards), the second-phase solution can last longer. This is the battlefield currently being contested by Visa, Mastercard, Stripe: controlled agency within authorized scope. The core is virtual card + dedicated payment API. It transforms the trust relationship from "trusting an uncertain AI" to "trusting a payment tool with defined parameters, controlled by the card issuer." Currently most suitable for large-scale application, but when B2B agentic scenarios grow to another order of magnitude, the programmability of authorization information and the information data volume limitations of bank cards will become bottlenecks.

The prerequisite for x402 to win is that its "payment as authorization" model is superior to the "middle-layer proxy management" model in terms of cost, latency, and developer experience. Currently, x402 has an advantage in micro-payment scenarios (as low as $0.001/transaction), but may be inferior to Web2 solutions in enterprise scenarios requiring complex permission management.

Similarly, the prerequisite for 8004 to win is: on-chain identity and reputation are more useful than identity systems managed by centralized platforms (like ClawHub's own review mechanism). Currently, 8004 adoption is not widespread enough; checking on-chain reputation is a worse experience than looking at platform ratings. Meta's acquisition of moltbook also targets this underlying capability of Agent identity verification and directory. Wanting to control the Agent identity layer themselves.

Crypto solutions cannot be satisfied with being theoretically better. They must match or exceed Web2 solutions in developer experience and user experience. Otherwise, they will be like many Crypto products, great decentralized理念 but too troublesome to use, so no one uses them.

Traditional Payment Giants Define the Adoption Timeline

The market will evolve in three stages. In the next 3-5 years, the Stripe/Visa solution will dominate the early market—backward compatibility is unbeatable, Agents can immediately transact with millions of merchants worldwide that already accept credit cards. Beyond 5 years, the pain points of the second stage accumulate to an unbearable level—lack of programmable authorization systems, inability to build sufficient identity information for agentic ID, high micro-transaction fees, slow cross-border settlement—the market naturally shifts to the third stage of Crypto infrastructure.

This means Crypto solutions don't need to beat Stripe today. Rather, they need to完善infrastructure within the next 3-5 years, ready to take the baton when second-stage solutions hit their ceiling. Right now it's an infrastructure construction race, not yet a market share battle. Of course, infrastructure needs to be in place提前, but having infrastructure alone doesn't automatically generate adoption; it requires an application layer爆发to activate it. TCP/IP was invented in the 1970s, but wasn't used massively until the World Wide Web browser appeared in the 1990s. Currently, we can see infrastructure gradually improving, but no one is using it大规模. For example, x402 was a technically available but lacking killer use case protocol for most of 2025. We need more applications to emerge,串联these infrastructures into a usable stack. The爆发of OpenClaw/Moltbook is the first demand engine we see—suddenly there are hundreds of thousands of Agents needing payment, identity, reputation; x402 and 8004 changed from available to being used.

Selling Shovels is More Profitable Than Gold Mining

The entire Base lobster ecosystem validates an ancient investment wisdom: the steadiest money in a gold rush is made by those 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 compute power. Venice sells推理额度and financializes compute power through the VVV/DIEM model. The business models of these infrastructure providers are much more mature and reliable than Agents autonomously making money.

Infrastructure commonly needed by the Agent category—identity, payment, security, coordination, compute resources. No matter which Agent framework wins (OpenClaw, IronClaw, OpenAI's next-gen product), they all need these. The term "Claws" coined by Karpathy captures a trend bigger than OpenClaw—localized, persistent, autonomous AI Agents are a category, and Crypto infrastructure aims to serve the entire Claw category. IronClaw (Near's TEE security version), various enterprise-customized Agent frameworks, OpenAI's upcoming integrated Agent all belong to this category. OpenClaw is the pioneer of this category, but won't be the only one.

Product-Agent Fit Will Replace Product-Market Fit

Multiple platforms (Taobao, Xiaohongshu, Weibo, Xueqiu) have started banning OpenClaw user accounts because Agents bypass these platforms' anti-crawler mechanisms by simulating operations through browsers. Platform operators and Agent users are naturally opposed. The platform's business model is built on human user attention; Agent users consume data but generate no advertising value.

Traditional marketing relies on the attention economy—beautiful images, video ads, limited-time buttons—strategies targeting human impulse buying. Agents are absolutely rational decision proxies, only concerned with whether API return data is clear, parameters are complete. It compares product specifications, historical prices, logistics speed, user reviews, even carbon footprint. There will be no user mind占领. Future moats are not brand (Agents don't recognize brands), not UX (Agents don't use interfaces), but the degree of data structuring, API stability, MCP compatibility, and on-chain verifiable service quality records.

Internet business models might transition to pay-per-crawl, where Agents, as service consumers, no longer use ad-supported free models, but directly pay微小fees for data retrieval: each data query, each API call, each service use requires direct payment of tiny fees and helps Agents access platform data compliantly. This is exactly what x402 solves, obtaining data access rights through direct payment and supporting micro-transactions. And this world already has an early form: Lord of a Few launched 80+ x402 paid endpoints within a week, each costing $0.50 to build, charging a few cents to tens of cents.

Furthermore, when both buyers and sellers are Agents, how will profit pools be redistributed?

Conclusion

We are in a rare window: infrastructure is in place, but the killer application has not yet arrived. History has proven time and again that real transformation doesn't announce itself提前—it only makes everyone realize the old world has ended at some inadvertent moment.

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.