This article is an in-depth research report 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; the second part will focus on an analysis of OpenClaw and overall industry trends.

Chapter Five OpenClaw: Special Research on Application Ecology

5.1 Project Background and Outburst

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 software project with the most Stars in GitHub history—over 250,000 Stars. React took 13 years to reach the same number.

In the overarching trend of AI products evolving from passive tools to active agents, OpenClaw’s transformation is that AI no longer waits for users to find it but actively helps users on platforms they already use. It resides on the user’s computer and connects to over 20 channels such as WhatsApp, Telegram, Slack, Discord, Signal, iMessage, Feishu, etc., operating email, calendars, browsers, file systems, and code editors through the MCP protocol. Andrej Karpathy coined a term for such systems: Claws; local AI agents that run in the background, can make autonomous decisions, and execute tasks. This term quickly became the common term in Silicon Valley for locally hosted AI agents.

Every major model release highlights agent capabilities because agents are a multiplier for justifying investments in AI infrastructure: a single chat query may consume hundreds of tokens, while an agent running with tool calls and multi-step reasoning can consume tens of thousands to hundreds of thousands of tokens.

Although the founders banned discussions about cryptocurrencies on Discord, the crypto community spontaneously built an entire suite 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 to observe the interaction between agents and on-chain infrastructure in a real, large-scale scenario for the first time, offering the crypto community a host with a real user base to attach economic activities.

5.2 Technical Architecture Analysis

Layer One: Message Channels—Identity Issues

OpenClaw connects to over 20 platforms; from the agent’s internal perspective, it understands itself as the same entity with a unified memory, configuration, and SOUL.md. However, from an external perspective, how do others know that this agent on Telegram is the same as that agent on Discord? Each platform has its own user ID system, which is not interoperable, and behavior records cannot be viewed across platforms. This is the core issue that ERC-8004 attempts to solve.

Layer Two: Gateway—Security Issues

The Gateway is the brain's scheduling center of OpenClaw: routing user messages to the correct agent, loading that agent’s session history and available skills, and delineating permission boundaries (whitelisting mechanism: when a message arrives at the Gateway, the system dynamically generates a tool whitelist based on the message’s source channel, user ID, group ID, and other information. Only tools on the whitelist will be injected into the agent's context. The agent cannot see tools outside the whitelist and thus cannot call them).

This design prioritizes security, but its permission control entirely relies on the Gateway as a single point of failure. If compromised or misconfigured, the agent may gain unauthorized permissions.

Layer Three: Agent Core (ReAct Loop)—Predictability Issues

The agent's operational logic is the ReAct (Reasoning + Acting) loop: receive input → think (invoke LLM) → decide action → invoke tools → get results → rethink → loop. The engineering optimizations implemented by OpenClaw include: high-frequency message scheduling (four strategies: Steer/Collect/Followup/Interrupt), LLM dual-layer fault tolerance (authentication rotation + model degradation), and an optional thinking tier system (six levels).

However, the LLM is probabilistic by nature, and the outputs are uncertain. Agents are non-deterministic executors, making irreversible actions in uncertain environments.

First, there is the loss of constraints due to context compression: security constraints are part of the context itself, and when the context is damaged or compressed, these constraints may be discarded. Secondly, there is prompt injection: someone intentionally embeds hidden instructions in the content the agent will process, causing the agent to treat the content as a command from the user to execute. The common root of both issues is that the boundaries of an agent's behavior are defined using natural language, which is ambiguous, manipulable, and capable of harmful compression.

An example is when Meta’s superintelligence alignment director Summer Yu requested the agent to "suggest some emails to delete," but the agent directly deleted hundreds of emails (context window overflow triggered compression, and the crucial constraint of "suggest" was lost).

In such cases, what we need is not better prompt engineering but rather structural security mechanisms: auditable operation logs, programmable permission boundaries, and an economic system that allows for accountability and compensation when errors occur. These are precisely the domains where smart contracts and on-chain infrastructure excel.

Layer Four: Memory System—Persistence and Portability Issues

OpenClaw implements two types of memory: daily working memory (YYYY-MM-DD.md file) and long-term distilled memory (MEMORY.md, key preferences extracted through deduplication and categorization). The retrieval uses a mixed model of vector search + BM25.

Sessions are reset daily at 4 AM by default. The context window is continuously compressed and summarized. When the context approaches the token limit, OpenClaw triggers session compression, summarizing previous conversations into a shorter version using LLM. Before compression, a Memory Flush is executed once, giving the agent an opportunity to write key information into persistent memory. This is essentially betting that the agent knows which information is key. A non-deterministic system judging key information is inherently uncertain.

All memories in OpenClaw exist in the local file system; switching computers would result in loss; there is no shared memory mechanism when collaborating with other agents; the knowledge and experience of the agent are locked to the machine it runs on. Sub-agent collaboration is limited to within the same OpenClaw instance; once it involves cross-instance or cross-organization agent collaboration, the system cannot handle it. Feedback from developers on GitHub: decision records are in chat history but lack persistent artifacts, transitions are fuzzy, and knowledge transfer is incomplete.

5.3 Structural Issues in Agent Economics

Context Does Not Flow: The Root of All Issues

• Spatial Locking: The agent's memory and knowledge exist on the machine it runs on; switching computers results in loss.
• Trust Isolation: Agent A claims "the user preferred X last week," but Agent B has no way to verify the truth of this claim.
• Discovery Challenges: Want to find an agent "good at DeFi analysis"? There is no standardized discovery mechanism.
• Value Undervalued: The domain knowledge and user preferences accumulated by the agent clearly have economic value, yet there is currently no clear pricing or trading mechanism.
• Default Temporality: Context can be compressed and summarized at any time or lost during session resets.

For context to flow effectively, it needs to simultaneously possess five attributes: able to cross trust boundaries, have economic properties, be discoverable without gatekeepers, retain decision traces, and adapt to consumer needs. Currently, there is no single protocol that offers all five attributes at once. MCP resolves “how AI models invoke tools.” A2A resolves “how agents communicate with each other.” x402 resolves “how agents make payments.” But “how agents autonomously discover, evaluate, and utilize context data in untrustworthy environments” still lacks an answer.

The Coordination Paradox

Agents only need enough context to reason. But cross-organizational coordination requires all historical context.

An agent thinking “should I book this flight?” only needs a summary of the current session. But when it needs to coordinate with supply chain agents, finance agents, or calendar agents (possibly operating on different platforms and by different organizations): what context do they share? How is verification handled? Who owns the context?

Gartner predicts that by 2027, more than 40% of agentic AI projects will be canceled due to rising costs, ambiguous commercial 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, and enterprises require deterministic outcomes. A non-deterministic executor collaborating in an uncertain environment with uncertain partners, without a verifiable layer of trust, cannot yield reliable outputs.

Currently, the demand for cross-platform agent collaboration is still very small. Users only want an AI that can help them do work, without caring whether it can collaborate with other agents. The coordination paradox is a real technical issue, but whether it will evolve into a large-scale commercial issue depends on whether the use of agents evolves from personal tools to a multi-agent collaborative network.

Combining the above analysis leads to an architectural concept:

The underlying layer is where agents perform reasoning, transient and token-bound. OpenClaw, Claude Code, Cursor all operate here. It requires quick responses, focusing on the current task.

The upper layer is where coordination occurs: persistent, verifiable, and economically priced. Cross-organizational knowledge accumulates here, provenance chains are maintained, and reputations operate here.

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

Is it possible to add a modular additional component that can be deployed laterally without permission, applicable to all agent systems—that has trustworthy neutrality, permanence, and verifiability? This component provides a controlled interface between the upper and lower layers, allowing context to flow downwards when needed and upwards when commitments are made. Before execution, it parses from a decentralized knowledge graph and injects relevant context subgraphs; after execution, it submits the operation as a verifiable transaction to the chain, with provenance and reputation updates. The core assumption of this layer is also that context fluidity has value: if most agent users do not need cross-platform collaboration (e.g., one person uses one OpenClaw for everything), then there is no real demand for a middle layer.

If the middle layer only focuses on context portability, it is likely to fail. However, if it concentrates on the verifiability of economic activities and reputation transferability in multi-party non-trust scenarios, which are driven by clear economic incentives, the probability of success is much higher. IronClaw is also an attempt to head towards an abstract middle layer—separating the execution environment and credential management into a verifiable security layer. However, it is still a solution within the Near ecosystem, lacking cross-platform universality.

The True Point of Entry for Crypto

Most of the demand in the agent economy can actually be addressed by Web2 solutions. The irreplaceability of crypto in the agent economy exists in only one scenario: when you need cross-organizational, cross-platform, permissionless interoperability, and there are no pre-established trust relationships 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 have no common platform, no shared account system, and no prior business relationship. In this scenario, on-chain identity (8004), on-chain payments (x402), and on-chain reputation are indeed better suited than any centralized solution—because no centralized platform can simultaneously cover all agent frameworks.

Additionally, just because an agent can pay does not mean it should. A Fortune 500 company lost $400 million because agents repeated payments during a retry loop. After agents can autonomously pay, the most valuable aspect will be the decision-making infrastructure that helps the agent determine whether to make the payment.

Currently, crypto for the agent economy is “nice to have,” unless cross-platform economic interactions between agents reach a sufficient scale, but when enough agents are no longer tied to a particular human's bank account (agents themselves become independent economic entities rather than human tools), traditional financial rails will not be able to cover them, making stablecoins the best (if not the only) way for large-scale financial transactions. Three possible triggers for it becoming a must-have:

1. Agents begin to hire other agents at scale: for instance, differing vendor agent systems within a corporate IT environment need interoperability (similar to today’s enterprise API integration, but more complex).
2. Agents begin 24/7 cross-border transactions: a workflow orchestrated by an agent may simultaneously invoke LLM endpoints in the U.S., data providers in Europe, and computing clusters in Southeast Asia, without needing three different payment rails. Stablecoins are global, available 24/7. This advantage stands out more in always-on, cross-timezone scenarios compared to humans.
3. Micropayments reach a frequency that traditional rails cannot sustain: currently, the average micropayments made by agents on-chain (API calls, data queries, computational resources) are only $0.09 per transaction, while Stripe’s transaction fees alone are $0.35 + 2.5%, which is four times more expensive than the transaction itself; when an agent needs to make tens of thousands of API calls, traditional payment processors cannot underwrite such merchant risks and their fee structures will become serious bottlenecks.

Security Threats and the Necessity of On-chain Infrastructure

The “Siri Paradox” is a key framework for understanding the entire agent track: Siri is safe because it is stripped down; OpenClaw is useful because it is risky. For AI to truly take action (e.g., handle emails, book flights, deploy code), it must possess extensive system permissions. Extensive permissions naturally imply a larger attack surface.

The most famous positive case on OpenClaw is when a user asked the agent to book a restaurant, but OpenTable had no availability. Rather than giving up, the agent found AI voice software by itself, downloaded it, and successfully called the restaurant to make a reservation. This ability to solve problems autonomously is what people dream of. But such autonomy also means that if a mistake is made, the consequences can spread at machine speed.

Some have called Steinberger’s joining OpenAI the “iPhone moment for AI agents.” But before that, there needs to be a phase of readiness in security infrastructure. Otherwise, large-scale usage could lead to large-scale losses. If the predicted “AI-generated $100M+ hacks” occur, there are two potential paths: either public panic leads to a regression in agent adoption (similar to the post-2016 DAO event slump in Ethereum), or it sparks the emergence of truly secure agent infrastructure (similar to the explosion of the smart contract auditing industry after the DAO incident). We lean towards the latter, as the demand for agents is real:

• Malicious agent identification >> 8004 reputation system. If every agent has on-chain identity and public reputation records, malicious behavior would leave unalterable records. Other agents can check on-chain reputation before establishing trust. Of course, the reputation system needs to be mature enough—not a simple score but a multidimensional, time-weighted trust model with a mechanism against manipulation.
• Malicious skills auditing >> Validation Registry. If the code audit results of skills are recorded in the 8004’s Validation Registry—audited by independent verifiers (staked services, zkML verifiers, TEE oracles)—typosquatting would be greatly reduced. Checking on-chain validation status before installing a skill would suffice.
• Credential leakage >> x402's “payment is authorization.” x402 eliminates API key management issues. Agents do not need to store long-term credentials—each time a service is needed, they directly pay for temporary access rights. Coupled with EIP-712 signature binding (tying service usage rights to payment addresses), even if tokens are leaked, others cannot use them.
• Behavioral loss of control >> on-chain audit logs + programmable permissions. Whether due to external attackers injecting directives (prompt injection) or the system itself losing constraints during compression (context loss), the result is that the agent executed actions beyond expectations. Smart contracts can define the boundaries of the agent's behavior—such as “single transactions do not exceed amount X,” or “deletion operations require multi-signature confirmation.” On-chain operation logs are immutable, allowing for traceability when issues arise. This is far more reliable than adding “please seek consent first” in a prompt, as prompt-level constraints can be lost during compression, but smart contract-level constraints cannot.

Of course, on-chain infrastructure can only mitigate the consequences of security problems, not prevent them. Smart contracts can limit “single transactions not exceeding amount X,” but what about an agent continuing to cause harm within limits after being injected? Ten thousand malicious transactions at $0.09 each still amount to $900. The true resolution of security requires tackling it at both the agent runtime layer (TEE/sandbox) and on-chain layer (permissions/audit). Solely working on the on-chain layer is insufficient.

Chapter Six Industry Comprehensive Analysis

Traditional technical moats (engineering capabilities, team size, execution efficiency) are being homogenized by AI tools. Anyone with an idea can quickly prototype a product through OpenClaw or Claude Code. This means:

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

The True Competition of the Track Is Not Within Crypto

Many are comparing which L1/L2 is better at building agents—Base vs Solana vs Ethereum vs Near. But the real competition lies between crypto solutions and Web2 solutions.

For instance, Sapiom raised $15.75M to create a Web2 route for agent service access management. In extreme cases, if Sapiom’s solution is good enough—agents could obtain access to all Web2 services through it without engaging with on-chain payments—there would be no reason for x402 to exist. If Stripe’s virtual card solution can solve anti-automation issues through business negotiations (persuading merchants to disable CAPTCHA for specific virtual cards), then the second phase of their solution could last longer. This is precisely the battleground where Visa, Mastercard, and Stripe are competing: controlled proxies within authorization limits. The core is the virtual card + dedicated payment API. Shifting the trust relationship from “trusting an uncertain AI” to “trusting a parameter-determined payment tool controlled by the issuing organization.” Currently, this model is best suited for mass application, but as B2B agentic scenarios grow to another scale, the programmability of authorization information and the data volume limitations of card information will become bottlenecks.

The condition under which x402 can win is that its “payment is authorization” model surpasses the “middle-layer agent management” model in cost, latency, and developer experience. Currently, x402 has advantages in micropayment scenarios (as low as $0.001 per transaction), but it may not outperform Web2 solutions in corporate scenarios requiring complex permission management.

Similarly, the condition under which 8004 can succeed is that on-chain identities and reputations are more useful than identity systems managed by centralized platforms (such as ClawHub’s own auditing mechanism). Currently, the adoption of 8004 is not widespread, and the experience of checking on-chain reputation is not better than viewing platform ratings. Meta’s acquisition of moltbook was also focused on the foundational capability of agent verification and registration (directory). They want to control the agent identity layer.

Crypto solutions cannot be satisfied with being theoretically better; they must catch up with or even exceed Web2 solutions in developer and user experience. Otherwise, they will end up like many crypto products that have a great decentralized ideology but are too complicated to use.

Traditional Payment Giants Define the Adoption Timeline

The market will evolve along three stages. In the next 3-5 years, Stripe/Visa solutions will dominate the early market—unbeatable backward compatibility allows agents to transact with millions of merchants that accept credit cards. Beyond 5 years, the pain points of the second stage will accumulate to an unbearable level—lack of programming capabilities in authorization systems, inability to build sufficient identity information for agentic IDs, high micropayment fees, and slow cross-border settlements—the market will naturally turn towards the crypto infrastructure of the third stage.

This means that crypto solutions do not need to defeat Stripe today; they need to perfect their infrastructure in the next 3-5 years and catch the baton when the second-stage solutions peak. Now is the race for infrastructure building, not for market share. Of course, the infrastructure needs to be in place ahead of time, but merely having infrastructure does not automatically generate adoption; there needs to be an application-layer explosion to activate it. TCP/IP was invented in the 1970s, but it wasn’t until the appearance of web browsers in the 1990s that it was widely used. Currently, we see infrastructure gradually improving, but no one is using it on a large scale. For example, x402 was technically available in the first half of 2025 but lacked killer use cases. We need more applications to emerge to connect these infrastructures into a usable stack. The explosion of OpenClaw/Moltbook is the first demand engine we see—suddenly hundreds of thousands of agents need payment, identity, and reputation, making x402 and 8004 go from available to utilized.

Selling Shovels Is More Profitable Than Gold Mining

The entire Base lobster ecosystem validates an old investment wisdom: the most stable way to make money during a gold rush is to sell shovels.

Felix earned $75,000. However, Clanker earned far more in fees from deploying 64,000 tokens. ClawRouter sells LLM routing services ($0.003 per request). ClawCloud sells agent computing power. Venice sells reasoning quotas and financializes computing power through VVV/DIEM models. The business models of these infrastructure providers are much more mature and reliable than agents making independent profits.

The infrastructure necessary across all agent categories includes identity, payments, security, coordination, and computing resources. Whichever agent framework prevails (OpenClaw, IronClaw, or the next generation products from OpenAI), they will all need these. The term “Claws” created by Karpathy captures a trend larger than OpenClaw—a localized, persistent, and autonomous AI agent is a category; the crypto infrastructure must serve the entire Claw category. IronClaw (the TEE security version of Near), various enterprise-customized agent frameworks, and the integrated agents that OpenAI will launch all belong to this category. OpenClaw is a pioneer in this category, but it will not 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 agents bypassed these platforms' anti-scraping mechanisms through browser simulation. Platform providers and agent users are inherently opposing. The commercial model of the platforms is built on the attention of human users, while agent users consume data without generating advertising value.

Traditional marketing relies on the attention economy—beautiful images, video ads, limited-time buttons—strategies aimed at human impulsive consumption. Agents are absolutely rational decision-makers, focused only on whether API-returned data is clear, whether parameters are complete. They compare product specs, historical prices, logistics efficiency, user reviews, and even carbon footprints. There will be no conquest of user mindset. The future moat is not brand (agents do not recognize brands), nor UX (agents do not use interfaces), but the degree of data structuring, API stability, MCP compatibility, and the on-chain verifiable quality of service records.

The internet’s business model is likely to shift towards pay-for-scraping, where agents act as service consumers, no longer relying on the ad-supported free model, but directly paying for data retrieval: each data query, each API call, and each service usage will require direct payment of small fees while helping agents comply with platform data access needs. This is precisely the issue x402 addresses, obtaining data access rights through direct payments and supporting micropayments. Moreover, this world has already seen early forms: Lord of a Few launched over 80 x402 paid endpoints within a week, each with a build cost of $0.50, charging a few cents to dozens of cents.

Furthermore, when both buyers and sellers are agents, how will the profit pool be redistributed?

Conclusion

We are in a rare window period: the infrastructure is in place, but killer applications have yet to arrive. History has repeatedly proven that true transformations do not announce themselves in advance—they only reveal that the old world is over in some unexpected moment.

Partial References

[1] McKinsey & Company, "The Agentic Commerce Opportunity," 2025. https://www.mckinsey.com/cabilities/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.

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