AI Agents are evolving from passive assistants into active economic participants. This report is structured into six chapters, systematically examining the core infrastructure stack, the explosion of application ecosystems, and the evolving industry landscape of the Agent economy.

At the macro level, it analyzes the market outlook for Agentic Commerce and identifies key infrastructure gaps. At the protocol layer, it provides an in-depth analysis of three complementary protocols: x402, ERC-8004, and Virtuals Protocol. At the application layer, it uses OpenClaw as a case study to explore the real-world deployment path of the Agent economy. Finally, it offers a comprehensive industry assessment across multiple dimensions, including competitive landscape, payment rails, security risks, and business models.

x402 (Payment Layer), jointly launched by Coinbase and Cloudflare, embeds stablecoin micropayments directly into the HTTP protocol layer. As of the end of 2025, it has processed over 100 million transactions, with an annualized payment volume reaching $600 million.

ERC-8004 (Trust Layer), proposed by the Ethereum Foundation’s dAI team in collaboration with MetaMask, Google, and Coinbase, provides AI Agents with three core on-chain registries: identity, reputation, and verification. It went live on the Ethereum mainnet on January 29, 2026.

Virtuals Protocol (Commerce Layer) has built a full-stack Agent commercialization platform, enabling autonomous transactions between Agents via ACP. It has deployed over 18,000 Agents, with aGDP exceeding $479 million.

OpenClaw (Application Layer), developed by Austrian developer Peter Steinberger, surpassed React with over 250,000 GitHub stars in just four months, becoming the fastest-growing open-source project in GitHub history. By natively embedding AI into more than 20 existing messaging platforms, it has catalyzed the crypto community to organically build on-chain economic infrastructure on top of it—making it a key case study for observing real interactions between Agents and on-chain protocols.

Chapter 1: Macro Background

1.1 Market Size Forecast

The Agentic Payment sector is in a phase of rapid expansion, with multiple institutions offering optimistic projections for its market size:

1.2  Infrastructure Gaps

Existing infrastructure is fundamentally hostile to the Agent economy: OAuth requires human interaction, credit card forms rely on manual input, and data silos prevent autonomous access. While Agents have already achieved autonomy at the “capability layer” (thinking and acting independently), they remain constrained at the “economic layer,” locked into infrastructure designed for humans (identity, coordination, and economic activity).

Two evolutionary paths are currently emerging:

• Centralized, compliance-driven path: Communication via A2A, tool integration via MCP, and payments via AP2/ACP (led by OpenAI and Stripe, purely Web2)
• Decentralized, permissionless path: x402 + ERC-8004 / 8183 + ACP (Agent coordination framework)

1.3 Key Timeline

Note: As of March 2026, the average daily transaction volume has significantly declined from its December peak, with infrastructure-related transactions experiencing the largest drop (>80%).

Chapter 2: x402 Protocol – Agent Payment Layer

x402 is an open-source payment protocol that revives the HTTP 402 status code, allowing any HTTP request to natively carry stablecoin payments. This enables AI Agents to perform instant pay-per-use transactions.

It is important not to think of x402 as just another payment protocol. It represents a redesign of the fundamental unit of economic activity: moving from “register → review → authorize → use” to “pay → use.” In essence, x402 = “Swift for agents.”

The current API economy operates under an implicit assumption: a human is involved in the middle. The process to obtain an API key—register → enter email → approval → copy key → paste into code—assumes human participation at every step. This workflow fails in an Agent economy because AI Agents cannot register themselves, fill forms, or manage keys.

x402 addresses this by leveraging the HTTP 402 status code to enable native stablecoin payments. When an Agent receives a 402 response, it directly pays on-chain (e.g., in USDC) and receives a proof-of-payment, enabling seamless pay-per-use interactions.

2.1 Protocol Overview and Workflow

Core Roles

Five-Step Transaction Workflow

1. Request Resource: The client sends a standard HTTP request to the resource server (e.g., GET /api/weather).
2. Return Quote: The server responds with an HTTP 402 status code, including structured payment instructions in the response headers (currency, amount, wallet address, network).
3. Sign Payment: The client constructs and signs a payment authorization using its wallet private key, placing the signed payload in the X-PAYMENT request header and resending the request.
4. Verify & Settle: The server forwards the payment information to a Facilitator for verification. Once confirmed, the Facilitator executes the stablecoin transfer on-chain.
5. Deliver Resource: Upon confirmation, the server returns the requested data/content/computation result to the client.

The entire process—from initiating the request to receiving the resource—takes approximately 2 seconds.

Comparison with Traditional Payment Methods

Key Features: No account registration, no API key, no subscription, and no human intervention required. Payments are as natural as sending an HTTP request—this is why x402 is called the “Internet-native payment layer.”

2.2  Key Metrics

Data Quality Note: According to Artemis analysis, the ratio of Real to Gamed transactions in x402 is close to 1:1 (e.g., on 2026.01.11, Real: 520K vs. Gamed: 518K). The true organic scale should be interpreted with a discount.

Distribution by Blockchain

Classification by Use Case (On-Chain Snapshot as of 2026.01.11)

2.3 Top Project Usage Rankings (as of March 2026)

Data Source: Dune Analytics – x402 Transactions per Project dashboard

2.4 Core Upgrades in V2

Wallet Identity + Reusable Sessions
In V1, every API call required a full on-chain transaction. V2 introduces the Sign-In-With-X (SIWx) mechanism: once an Agent verifies its wallet identity, subsequent calls can reuse the session without on-chain confirmation each time. Essentially, this upgrades pay-per-call to a subscription model, addressing performance bottlenecks in high-frequency scenarios.

Multi-Chain Unification + Traditional Payment Compatibility
V2 standardizes the identification of networks and assets, creating a unified payment format (x402) that works across chains and traditional payment rails. Base, Solana, other L2s, as well as ACH, SEPA, and card networks, are all integrated into the same payment model. This is the most critical upgrade—x402 evolves from a “crypto-only payment protocol” into a neutral payment layer bridging crypto and traditional finance.

Service Auto-Discovery
V2 introduces a Discovery extension, allowing x402 services to expose structured metadata for automatic crawling and indexing by Facilitators. AI Agents can automatically discover services, understand pricing, and initiate payments. This is especially crucial for the Agent economy—Agents no longer need prior knowledge of a service provider’s payment interface and can autonomously discover and pay for services at runtime.

Modular SDK
With a plugin-based architecture, new chains are added as independent packages, reducing integration costs. Cloudflare has proposed a deferred payment scheme, including Circle’s Gateway solution, which is still under development.

2.5 Ecosystem Participants

Foundation and Protocol Layer

2.6 Agent Payment Stack Landscape

Detailed Protocol Comparison

Key Insight: It’s not about who replaces whom, but how they are combined. Google has partnered with Coinbase to release the A2A x402 extension, while AP2 natively integrates x402 as a crypto payment rail. The real competitive risk lies in standards fragmentation.

2.7  Key Risk Signals

• Average daily transaction volume dropped from approximately 731K in Dec 2025 to around 57K in Mar 2026 (-92%). The real transaction volume is roughly $14K/day (per Artemis, during the December peak of $250K/day, 95% was Gamed).
• Ecosystem market capitalization stands at $7 billion (LINK $6B + Virtuals $0.6B), showing a significant divergence between valuation and actual usage.
• Infrastructure-related projects experienced the largest declines in usage: x402secure.com (-80%+), AgentLISA (nearly zero), pay.codenut.ai (significantly contracted).

Three-Layer Cause Analysis

Layer 1: Disappearance of Catalysts
The transaction surge from October to December 2025 was driven by three factors: the meme token craze, multiple project TGEs (Token Generation Events) expectations, and Facilitators competing to boost their Dune rankings.

Layer 2: Fundamental Supply-Demand Mismatch
x402 solves the problem of “AI Agents autonomously paying to call APIs,” yet the vast majority of AI Agents still access services via API keys and subscription models. Truly autonomous Agents with economic decision-making capabilities are nearly nonexistent in the industry, and very few API providers are willing to accept USDC pay-per-use. In short, the road is built, but the cars haven’t been made yet.

Layer 3: Overall Cooling of the Crypto Market

Positive Signal: Stripe’s integration with x402 is a significant development. Stripe co-founder John Collison predicts that the “tsunami of agentic commerce” will arrive in the coming months and years. By simultaneously deploying ACP (Web2 credit card rail) and x402 (Web3 stablecoin rail), Stripe acts as a hedge across both pathways.

x402 has given rise to a batch of new middleware projects that essentially help Agents more easily and autonomously access various services—from AI inference to Web2 APIs—under the “pay-as-authorization” paradigm. A programmable, permissionless, 24/7 crypto payment rail is the natural choice for autonomous Agents. However, this only matters if Agents truly require permissionless operation. If Agents always operate under human authorization (Phase 2: controlled agents), traditional payment rails combined with virtual cards are sufficient. Only when Agents begin conducting economic activity independently of humans (Phase 3: autonomous economy) does permissionless capability become a necessity.

Additionally, credit cards have a chargeback mechanism, allowing consumers to dispute transactions and recover funds—a consumer protection system developed over decades. On-chain payments, however, are final settlement: once paid, the funds are gone with no chargeback. This means that if an Agent misbehaves (e.g., via prompt injection attacks), users can call the bank to recover funds under a credit card system, but with x402, the money is already on-chain and irretrievable. This represents x402’s real disadvantage compared to traditional payments.

Many frictions caused by humans acting as “human middleware” moving between systems are actually trust-establishing mechanisms: fraud prevention, access control, accountability, dispute resolution, and audit documentation. These frictions sustain the operation of commercial systems.

Potential solutions may include:

• On-chain escrow mechanisms: funds are locked in smart contracts and only released after service delivery confirmation.
• Insurance protocols: providing coverage for Agent transactions.
• ERC-8004 reputation systems: reducing the likelihood of transactions with untrusted parties.

However, all of these approaches are currently immature.

2.8 VC Investment Perspective

Promising Investment Directions

• API Service Providers with Real Payment Demand (Sellers): Data analytics, web scraping, oracles, security audits, pay-per-inference, compliance/KYC, etc. Evaluation criterion: They can already make money under traditional models; x402 serves only as an additional distribution channel.
• Dispute Resolution and Payment Guarantee Layers (Gateways): On-chain payments cannot be rolled back or chargebacked, so high-value transactions require dispute resolution mechanisms. Representative projects:
• Circle Gateway – non-custodial pre-deposit + off-chain batch settlement
• Kamiyo – Agent reputation, fund custody, oracle-based judgment, ZKP arbitration
• Dashboard / FinOps Tools: Help enterprises manage multiple Agent expenditures (how much is spent, on what, value assessment, cost-saving strategies). Analogous to cloud computing tools like CloudHealth / Cloudability, with acquisition potential in the $300–500 million range by large tech companies.

Chapter 3: ERC-8004 – Agent Trust Layer

ERC-8004 is a set of on-chain coordination standards that establish a trustless discovery and interaction framework among Agents via three registries: Identity, Reputation, and Validation.

3.1 Standard Overview and Core Distinctions

In traditional interactions, Agent-to-Agent engagement often requires pre-established trust or relies on third-party institutions, restricting interactions within the same ecosystem. In an open environment, the key challenge is: how can Agents discover partners, review historical performance, and verify reliability?

Important Distinction: ERC-8004 is not a token. While it uses ERC-721 NFTs internally to represent Agent identities, the standard itself is about coordination and trust, carries no economic value, and is non-transferable.

3.2 Three Registries

Identity Registry
Built on ERC-721 + URIStorage, each Agent receives an NFT identity linked to an agentURI pointing to a registration file (JSON) containing name, description, service endpoints (A2A/MCP/Web), x402 support status, etc. The URL can be stored on:

• IPFS – decentralized and censorship-resistant
• HTTPS server – simple but centralized
• On-chain encoding – fully decentralized but expensive

Reputation Registry
Provides standard interfaces to publish and retrieve feedback signals, supporting both on-chain scoring and off-chain algorithms. It can attach x402 proofOfPayment as an economic endorsement trust signal. Agents rate each other, but to prevent score manipulation, ERC-8183 assists in proving real job interactions between Agents.

Validation Registry
Introduces TEE (Trusted Execution Environment), PoS staking mechanisms, and ZK (Zero-Knowledge Proofs) to verify and authenticate Agent task outputs:

• TEE: Verifies that tasks are executed in a secure black-box environment, with code and data unobserved or tampered with externally.
• PoS: Validators stake assets to participate in tasks; malicious behavior results in slashed stakes.
• ZK: Verifies the correctness of an Agent’s reasoning process without revealing internal weights.

3.3 Development Milestones

Supporters: ENS, EigenLayer, The Graph, Taiko. Approximately 1,000–2,000 developers have joined.

However, the current limitations of ERC-8004 are acknowledged even by its creator, Crapis: “8004 is essentially a set of registries.” It provides Agents with an identity and a rating mechanism, but it cannot guarantee that an Agent’s behavior is trustworthy. True verification requires:

• Behavior audit: What has the Agent actually done in the past?
• Execution environment proof: Evidence that tasks ran in a TEE.
• Intent verification: Did the Agent actually do what it claimed it would do?

The TEE component of the Validation Registry is still under community discussion and far from mature.

In other words, 8004 is necessary but not sufficient. It solves the question “Who is this Agent?” but not “Can this Agent be trusted?” The latter requires a combination of 8004 + TEE + behavior audit, which no one has fully implemented yet.

There is also an underestimated direction: in the human economy, credit systems are built on balance sheets and credit history—how much you have, how reliably you’ve repaid loans. Agents lack these, but they do have behavioral data: how many tasks they’ve completed, success rates, average response times, complaints received, etc. If this behavioral data can become a financial primitive, then the ERC-8004 reputation system is no longer just positive or negative reviews, but a credit score in the Agent world.

A high-reputation Agent could gain:

• Higher credit limits (pre-authorization of more funds)
• Lower transaction costs (lower risk)
• Priority task allocation (employers choose high-reputation Agents first)

ERC-8004’s Identity and Reputation registries are only the foundational data layer. Value creation lies in who can build Agent credit assessment and financial services on top of this data layer—Agent lending, Agent insurance, Agent credit lines—essentially forming the entire financial services stack.

3.4 Relationship with Other Protocols

3.5 ERC-8183: Ethereum Standardization of ACP

ERC-8183 is the Ethereum open-standard version of the internal ACP protocol used by Virtuals (released on March 10, 2026, currently in Draft stage).

The core primitive is the Job—an on-chain state machine (Open → Funded → Submitted → Completed/Rejected/Expired) where funds are held in a programmable escrow and independently adjudicated by an Evaluator. Once delivery quality is confirmed, the payment is automatically settled. The protocol supports Hooks extensions for features like reputation thresholds, bidding, milestone payments, etc.

Key Design: Each completed Job automatically generates an interaction record that feeds into ERC-8004’s Reputation Registry—analogous to a “Yelp review that requires a completed transaction and includes a third-party adjudicator.” This is the connection point where ERC-8183 and ERC-8004 form a symbiotic loop.

Chapter 4: Virtuals Protocol – Agent Commerce Layer

4.1 Project Overview

Virtuals Protocol is a decentralized, full-stack AI Agent infrastructure that allows anyone to create, tokenize, co-own, and monetize autonomous AI Agents on-chain. The project was originally founded in 2021 as PathDAO (a gaming guild) and pivoted to AI Agents in early 2024. Its main deployment is on Base, with expansions to Ethereum, Solana, and Ronin.

Core Team:

• Jansen Teng – Founder, former BCG consultant, BSc in Biotechnology & Business Management from Imperial College London
• Weekee Tiew – Imperial College Biotechnology BSc + MSc in Management from London Business School, PE/BCG background

Headquartered in Kuala Lumpur, Malaysia, the team comprises approximately 38 members.

Funding History: During the PathDAO phase, a seed round raised $16M, led by DeFiance Capital and Beam.

4.2 Technical Architecture: Four Pillars

Pillar 1: GAME Framework – Internal Decision-Making of a Single Agent

GAME acts as the brain: it equips an Agent with goals, personality, perception abilities, and executable actions, allowing it to autonomously plan “what should I do next” and decompose tasks for internal Workers to execute. All of this happens within the boundary of a single Agent.

Architecture Core: Hierarchical Planning separates “what to think” from “how to act”:

• Task Generator (High-Level Planner / HLP): Generates tasks based on the Agent’s goals and assigns Workers
• Workers (Low-Level Planners / LLP): Each has a specific set of executable Functions
• Functions: Execute API calls, on-chain transactions, data retrieval, etc.

Supported Base Models: Llama 3.1 405B (default), Llama 3.3 70B, DeepSeek R1, DeepSeek V3 — designed to be model-agnostic. With the release of OpenAI/Google Agent frameworks, GAME’s differentiation is now minimal: it is the only Agent framework with native integration of the on-chain economic layer (ACP + VIRTUAL token).

Pillar 2: ACP – the “Commercial Law” Between Agents

Agent Commerce Protocol (ACP) is an on-chain standardized protocol that enables Agents to discover, hire, negotiate, escrow funds, deliver, and settle with each other without human intervention.

ACP Four-Stage State Machine:

Pillar 3: Butler – The User’s Super Gateway

Butler is the consumer-facing gateway of the ACP network—essentially an Agent that orchestrates the ACP protocol, built on top of an LLM. It translates user natural language into on-chain multi-Agent collaborative workflows.

Butler has a two-layer architecture:

• Surface Layer: LLM conversational interface (currently backed by Gemini 3 Pro)
• Underlying Layer: ACP protocol orchestrator, executing the full process: Agent discovery → quote confirmation → Escrow lock → task routing → delivery verification → fund release. Users see a chat interface, but Butler handles contract-level scheduling behind the scenes.

Butler Pro Mode clearly separates planning from execution:

1. Planning Phase →
2. Review Phase (users can optimize the plan) →
3. Execution Phase (autonomously orchestrates the full workflow)

Built-in capabilities include Token Swap, DCA investments, perpetual contracts, and Fund of Funds.

Pillar 4: Launch Platform – Wall Street for Agents

A three-tier launch system covers the full lifecycle of Agent projects, from 0 → 1 → 100:

Titan Launch Projects:

• XMAQUINA ($DEUS): A DAO holding equity in embodied intelligence companies such as Figure AI, with a $60M FDV
• Fabric Foundation ($ROBO): Partnering with OpenMind on the robotics economy

4.3 Agentic GDP（aGDP）Analysis

aGDP (Agentic Gross Domestic Product) is a custom core ecosystem metric defined by Virtuals, measuring the total economic value generated within the ecosystem by all autonomous Agents through services, coordination, and on-chain activities.

aGDP Growth Trajectory

aGDP Quality Issues – Three Warning Signals:

1. Revenue Volatility Exposes Speculative Dependence:
   Daily protocol revenue dropped from $1.02M in Jan 2025 to $35K by the end of Feb (-97%). Revenue mainly comes from Agent Token transaction fees (1%), rather than sustained payments for Agent services.
2. Severe Concentration at the Top:

• Ethy AI: a single Agent contributed $218M aGDP (45.5% of the entire ecosystem)
• Top three Agents combined: $407M (84.9%)
  All three are transaction-execution Agents; their aGDP largely reflects handled transaction volume rather than actual Agent service revenue.
• Luna, as a flagship IP Agent, has a take rate near 100%
• Ethy AI has a take rate of only 0.26%

3. $3B Target Assumptions:
   Scaling from $470M to $3B requires a 6.4× growth. If speculative elements dominate aGDP, this target effectively bets on Agent Token market hype rather than organic growth of the Agent economy.

4.4 Token Economics

$VIRTUAL’s Fourfold Value Capture Mechanism

ACP Tax Structure:
When a user pays 100%, 90% goes to the Agent’s wallet (can be withdrawn or used to hire other Agents, compounding on-chain aGDP), and 10% goes to the Treasury (of which 1% flows into the G.A.M.E Treasury). Treasury revenue is continuously used to buy back Agent Tokens, aligning long-term incentives.

Supply Structure:

• Total supply: 1 billion VIRTUAL, fixed, with no initial inflation
• Current status: fully unlocked and circulating
• Potential issuance: up to 10% per year over the next 3 years, subject to governance approval
• veVIRTUAL: Staking grants governance voting rights + eligibility for Agent Token airdrops

4.5 Ecosystem Data Overview

Benchmark Agent Cases

4.6 Competitive Landscape and Moat

Moat Hierarchy (from Strongest to Weakest):

• Network Effects + Token Flywheel (Strongest):
  Over 18,000 Agents and 650,000+ holders form a two-sided market. Each Agent is paired with VIRTUAL, creating a positive feedback loop. This cannot be replicated by open-source frameworks—LangChain lacks a native economic settlement layer between Agents.
• Standard-Setting Power (Strong):
  The combination of ACP → ERC-8183 (co-released with Ethereum Foundation) + ERC-8004 + x402 competes to establish the “legal foundation” for the AI Agent economy.
• First-Mover Advantage + Brand (Moderate):
  Leading mindshare in AI Agent + crypto space, backed by institutions like Grayscale and Fundstrat.

Technical Capability (Weakest):
GAME’s hierarchical architecture offers design advantages, but it relies on third-party LLMs, lacks proprietary models, and its orchestration layer can be replaced by stronger frameworks.

Chapter 5: OpenClaw – Application Ecosystem Special Study

5.1 Project Background and Breakout

In November 2025, Austrian developer Peter Steinberger published a weekend project on GitHub. By March 2026, just four months later, the project had surpassed React to become the most starred software project in GitHub history—with 250K+ stars, while React took 13 years to reach the same number.

Amid the broader trend of AI products evolving from passive tools to proactive Agents, OpenClaw introduced a key shift: 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 WhatsApp, Telegram, Slack, Discord, Signal, iMessage, Feishu, and over 20 other channels. Through the MCP protocol, it can operate email, calendar, browser, file system, and code editors.

Andrej Karpathy coined the term “Claws” for such systems: locally hosted AI Agents that run in the background, making autonomous decisions and executing tasks. The term quickly became the general way in Silicon Valley to refer to locally hosted AI Agents.

Every mainstream model release now highlights Agent capabilities because Agents act as a demand multiplier validating AI infrastructure investment: a simple chat query consumes hundreds of tokens, whereas an Agent performing multi-step reasoning with tool calls consumes tens of thousands to hundreds of thousands of tokens.

Although the founder banned cryptocurrency discussions on Discord, the Crypto community spontaneously built a full set of on-chain economic infrastructure on top of OpenClaw, including token launches, identity registration, payment protocols, social networks, and reputation systems.

The breakout of OpenClaw provides, for the first time, a real, large-scale environment to observe how Agents interact with on-chain infrastructure, while also giving the Crypto community a host with an actual user base on which to anchor economic activity.

5.2 Technical Architecture Analysis

Layer 1: Messaging Channels – Identity Problem

OpenClaw connects to 20+ platforms. From the Agent’s internal perspective, it knows it is the same Agent, with unified memory, configuration, and SOUL.md. However, from an external perspective, how can others tell that the Agent on Telegram is the same as the one on Discord? Each platform has its own user ID system, and these systems are isolated with no visibility into cross-platform behavior. This is precisely the core problem that ERC-8004 aims to solve.

Layer 2: Gateway – Security Problem

The Gateway acts as OpenClaw’s brain and scheduler: it routes user messages to the correct Agent, loads the Agent’s session history and available Skills, and defines permission boundaries before the Agent begins thinking.

• Whitelist mechanism: When a message arrives at the Gateway, the system dynamically generates a tool whitelist based on the message’s channel, user ID, group ID, etc. Only tools on the whitelist are injected into the Agent’s context. The Agent cannot see or access tools outside the whitelist.

This design pre-emptively enhances security, but all permission control depends on the Gateway as a single point of trust. If compromised or misconfigured, the Agent could gain unauthorized privileges.

Layer 3: Agent Core (ReAct Loop) – Predictability Problem

The Agent’s operation follows the ReAct (Reasoning + Acting) loop:
Receive input → Think (LLM call) → Decide action → Call tool → Get results → Re-think → Loop

OpenClaw implements engineering optimizations such as:

• High-frequency message scheduling with Steer/Collect/Followup/Interrupt strategies
• LLM dual-layer fault tolerance (authentication rotation + model fallback)
• Optional multi-level reasoning mechanism (6 levels)

However, LLMs are inherently probabilistic, and outputs are non-deterministic. Agents execute actions non-deterministically in non-deterministic environments.

• Context compression leads to constraint loss: Security constraints are part of the context. When context is lossy-compressed, constraints can be discarded.
• Prompt injection: Malicious actors embed hidden instructions into content that the Agent processes, tricking it into executing unintended commands.

Both issues arise because Agent behavior boundaries are defined in natural language, which is ambiguous, manipulable, and lossy when compressed.

Example: Meta’s Superintelligence Lab alignment lead Summer Yu instructed an Agent to “suggest emails that can be deleted,” but the Agent ended up deleting hundreds of emails. Compression of the context window caused the key constraint (“suggest”) to be lost.

In such cases, what is needed is not better prompt engineering, but structural safety mechanisms:

• Auditable action logs
• Programmable permission boundaries
• Economic systems that allow accountability and compensation when errors occur

These are precisely the areas where smart contracts and on-chain infrastructure excel.

Layer 4: Memory System – Persistence and Portability Issues

OpenClaw implements two types of memory:

1. Daily working memory (YYYY-MM-DD.md files)
2. Long-term distilled memory (MEMORY.md, key preferences deduplicated and categorized)

Retrieval uses a hybrid of vector search and BM25.

• Session Reset: By default, sessions reset daily at 4:00 AM.
• Context Compression: The context window is continually compressed and summarized. When approaching the token limit, OpenClaw triggers session compression, using the LLM to summarize previous conversations into a shorter version.
• Memory Flush: Before compression, a Memory Flush occurs, giving the Agent a chance to write key information into long-term memory. This relies on the Agent to know what information is important, which is inherently uncertain in a non-deterministic system.

Key limitations:

• All memory exists on the local file system; changing computers causes memory loss.
• 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 the same OpenClaw instance. Cross-instance or cross-organization collaboration is currently impossible.

Developer feedback on GitHub: Decision records exist in chat history but aren’t persisted as artifacts, handovers are ambiguous, and knowledge transfer is incomplete.

5.3 Structural Problems in the Agent Economy

Context Doesn’t Flow: The Root of All Problems

The technical analysis points to one fundamental issue: Context in today’s AI systems doesn’t move. 

Each one optimizes the agent experience within its own walled garden. 

Context immobility shows up five ways:

• Spatial Lock-in: An agent’s memory and knowledge are locked to the machine it

runs on. Switch devices and it’s gone.

• Trust Isolation: Agent A claims “the user preferred X last week.” Agent B has no

way to verify it. No shared source of truth.

• No Discovery Mechanism: Want an agent skilled in DeFi? There’s no standard way to

find one.

• Unpriced Value: Agents learn domain expertise and user preferences—both genuinely valuable. But there’s no way to price either or trade them.
• Temporary by Default: Context gets compressed, summarized, or discarded when sessions reset. Nothing’s designed to persist.

For context to actually flow, it needs all five simultaneously:

— Cross trust boundaries

— Economic value

— Discoverable without intermediaries

— Traceable decision history

— Responsive to user needs

No protocol delivers all five. MCP solves how models call tools. A2A solves how agents talk to each other. x402 solves how agents pay. What’s missing is how agents autonomously discover, evaluate, and use context data across untrusted environments. 

That answer doesn’t exist yet.

Coordination Paradox

An Agent only needs enough context to reason, but cross-organization coordination requires all historical context.

• For example, when an Agent considers “Should I book this flight?” the current session’s compressed information is sufficient.
• But if it needs to coordinate with a supply chain Agent, finance Agent, and calendar Agent (possibly on different platforms and run by different organizations), questions arise:
• Which context is shared?
• How is it verified?
• Who owns it?

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. Yet 70% of developers report that the core problem is integration with existing systems. The root cause: Agents are non-deterministic executors, while enterprises require deterministic outcomes. A non-deterministic executor in an uncertain environment collaborating with uncertain partners cannot produce reliable outputs without a verifiable trust layer.

Currently, cross-platform Agent collaboration demand is minimal. Users just want an AI that helps them get work done—they don’t care if it can coordinate with other Agents. The coordination paradox is a real technical issue, but whether it becomes a large-scale business problem depends on whether Agent usage evolves from personal tools to multi-Agent collaboration networks.

Architecture Concept

• Lower layer: where Agents perform reasoning.
• Characteristics: transient, token-bound, fast, focused on current tasks.
• Examples: OpenClaw, Claude Code, Cursor.
• Upper layer: where coordination occurs.
• Characteristics: persistent, verifiable, economically priced.
• Accumulates cross-organization knowledge, maintains provenance, operates reputation.

These two layers have conflicting requirements:

• Agents need simplicity; organizations need historical records.
• Agents need speed; auditing requires permanence.
• Agents operate probabilistically; enterprises require deterministic results.

Most current architectures attempt to merge these layers, which is unlikely to succeed.

Proposed idea: add a modular, permissionless middleware deployable across all Agent systems.

• Properties: trusted neutrality, persistence, verifiability.
• Provides a controlled interface between layers:
• Downward flow: injects relevant subgraphs from a decentralized knowledge graph before execution.
• Upward flow: submits operations as verifiable on-chain transactions with provenance and reputation updates after execution.

The core assumption is that context flow is valuable:

• If most Agent users never need cross-platform collaboration (e.g., a single OpenClaw handles everything), the middle layer has no real demand.

If the middleware only provides portable context, it will likely fail.

• Success is more likely if it focuses on:
• Verifiability of economic activity in multi-party, untrusted scenarios
• Transferable reputation with clear economic incentives

IronClaw is an attempt toward such an abstract middle layer—separating execution environment and credential management into a verifiable secure layer—but it remains internal to the Near ecosystem, lacking cross-platform generality.

The Real Crypto Entry Point

Most of the demand in the Agent economy can actually be solved with Web2 solutions. Crypto’s irreplaceable value in the Agent economy only exists in one scenario: when you need cross-organization, cross-platform, permissionless interoperability and the participants do not have pre-established trust.

For example:

• Agent A (running on OpenClaw, owned by User Alpha) needs to hire Agent B (running on Claude Code, owned by User Beta) to complete a task.
• They have no shared platform, no shared account system, and no prior business relationship.

In this scenario, on-chain identity (ERC-8004), on-chain payment (x402), and on-chain reputation are more suitable than any centralized solution—because no single centralized platform can cover all Agent frameworks simultaneously.

However, just because an Agent can pay doesn’t mean it should pay. For instance, some F500 companies lost $400 million because Agents repeatedly paid in retry loops. Once Agents can autonomously pay, the most valuable infrastructure is the decision-making framework that tells Agents whether a payment is justified.

Currently, crypto in the Agent economy is “nice to have”, unless cross-platform economic interactions between Agents reach a sufficient scale. When enough Agents are no longer tied to a human bank account (i.e., Agents become independent economic entities rather than human tools), traditional financial rails cannot cover them. At that point, stablecoins become the best (or even the only) solution for large-scale fund transfers.

There are three potential triggers for crypto to become a “must-have”:

1. Agents begin large-scale hiring of other Agents

• For example, different vendor Agent systems in an enterprise IT environment need to interoperate—similar to today’s enterprise API integrations but far more complex.

2. Agents begin 24/7 cross-border transactions

• An Agent-orchestrated workflow might call a US LLM endpoint, a European data provider, and a Southeast Asian compute cluster simultaneously.
• It shouldn’t require three separate payment rails.
• Stablecoins are global and always-on, which is a bigger advantage for Agents than humans in always-on, cross-timezone scenarios.

3. Micro-payments reach a frequency beyond the capacity of traditional rails

• Currently, on-chain microtransactions (API calls, data queries, compute resources) average $0.09 per transaction, while Stripe fees alone are $0.35 + 2.5%, 4× higher than the transaction itself.
• If an Agent needs to call tens of thousands of APIs, traditional payment processors cannot underwrite this merchant risk, and the fee structure becomes a true bottleneck.

Security Threats and the Necessity of On-Chain Infrastructure

The “Siri Paradox” is a key framework for understanding the entire Agent sector: Siri is safe because it’s neutered; OpenClaw is useful because it’s dangerous. For AI to truly take action—handling emails, booking flights, deploying code—it must have broad system permissions. Broad permissions naturally mean a larger attack surface.

A notable positive example on OpenClaw: a user asked an Agent to book a restaurant, but OpenTable had no available slots. The Agent didn’t give up; it found AI voice software, installed it, and called the restaurant to successfully book. This kind of autonomous problem-solving ability is highly desired. But the same autonomy also means that errors propagate at machine speed.

Some have called Steinberger joining OpenAI the “iPhone moment for AI Agents”. But before that, there must be a phase with security infrastructure in place. Otherwise, large-scale adoption equals large-scale losses. Chopping Block predicts “AI-generated $100M+ hacks”—if that happens, there are two paths:

1. Public panic causes a regression in Agent adoption (similar to Ethereum’s downturn after the 2016 DAO hack).
2. It catalyzes a real Agent security infrastructure (similar to the boom of smart contract auditing post-DAO).

We lean toward the latter, because the demand for Agents is real:

• Malicious Agent detection → ERC-8004 Reputation System
• If each 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.
• The reputation system must be mature—multi-dimensional, time-weighted, with anti-manipulation mechanisms, not just simple ratings.
• Malicious Skills auditing → Validation Registry
• If Skills’ code audits are recorded in the ERC-8004 Validation Registry, verified by independent evaluators (staked services, zkML verifiers, TEE oracles), typosquatting risks are greatly reduced.
• Checking the on-chain validation status before installing a Skill suffices.
• Credential leakage → x402 “pay-per-access”
• x402 eliminates API key management problems. Agents don’t need to store long-term credentials—they pay on demand for temporary access.
• Coupled with EIP-712 signature binding (binding service usage rights to the payment address), even if a token leaks, it cannot be used by others.
• Behavioral runaway → On-chain audit logs + programmable permissions
• Whether it’s prompt injection by an attacker or context loss during compression, the result is the Agent performing unexpected operations.
• Smart contracts can define Agent behavior boundaries—e.g., “single transaction ≤ X amount,” or “deletion requires multisig approval.” On-chain logs are immutable and auditable.
• This is far more reliable than embedding “ask for approval first” in a prompt, because prompt-level constraints can be lost during compression, whereas contract-level constraints persist.

Of course, on-chain infrastructure can only mitigate consequences, not prevent attacks. Smart contracts can limit “single transaction ≤ X amount,” but what if an injected Agent continues malicious actions within the limit? For example, 10,000 malicious $0.09 transactions still total $900.

True security requires a dual approach:

1. Agent runtime layer (TEE/sandbox)
2. On-chain layer (permissions/audit)

Relying on the on-chain layer alone is insufficient.

Chapter 6: Industry Comprehensive Analysis

Traditional technical moats—engineering capability, team size, execution efficiency—are being commoditized by AI tools. Anyone with an idea can quickly build a product prototype using OpenClaw or Claude Code. This implies:

• Small teams’ window of opportunity is shorter than ever (and large teams can catch up even faster using the same tools).
• First-mover advantage at the idea level is more valuable than before, because your Agent can iterate faster than any competitor.
• The scarcest resource is judgment about the right problems to solve, not technical capability.

The Real Competition in the Track Isn’t Within Crypto

Many people compare which L1/L2 executes Agents better—Base vs Solana vs Ethereum vs Near. But the true competition is Crypto solutions vs Web2 solutions.

For example, Sapiom raised $15.75M to provide Web2-based Agent service access management. In an extreme scenario, if Sapiom’s solution is good enough—Agents can access all Web2 services through it without touching on-chain payments—then x402 has no reason to exist. If Stripe’s virtual card solution can resolve anti-automation issues through commercial agreements (convincing merchants to remove CAPTCHAs for specific virtual cards), the Phase 2 model could last longer. This is exactly the battlefield Visa, Mastercard, and Stripe are currently fighting over: controlled Agents within the authorized scope. The core is virtual cards + dedicated payment APIs, shifting the trust from “trust an uncertain AI” to “trust a parameterized payment tool controlled by the issuer.” This works best at scale for now, but as B2B agentic scenarios grow to the next level, programmability limits of authorization info and the data constraints of credit cards will become bottlenecks.

For x402 to win, its “pay-as-you-go equals authorization” model must outperform the “middle-layer Agent management” model in cost, latency, and developer experience. Currently, x402 has an edge in micro-payment scenarios (as low as $0.001 per transaction), but in complex enterprise scenarios with sophisticated permission management, Web2 solutions might still be better.

Similarly, for ERC-8004 to win, on-chain identity and reputation must be more useful than centralized identity management (e.g., ClawHub’s own verification mechanism). Adoption of 8004 is still limited; checking on-chain reputation is not as convenient as looking at a platform’s rating. Meta acquiring moltbook also reflects this—acquiring Agent identity verification and directory capabilities to control the Agent identity layer internally.

Crypto solutions cannot rely on being theoretically better. They must match or exceed Web2 solutions in developer and user experience, or they risk becoming another “great decentralization idea that nobody uses because it’s too cumbersome.”

Legacy Payment Giants Define the Adoption Timeline

The market is expected to evolve in three stages. Over the next 3–5 years, Stripe/Visa solutions will dominate the early market—they offer unmatched backward compatibility, allowing Agents to immediately transact with millions of merchants worldwide that already accept credit cards.

Stage 2 emerges as this scales: virtual cards with proprietary payment APIs, giving enterprises limited programmability and basic controls. It works for a time. But beyond five years, structural limits become unbearable: authorization systems that cannot adapt to agent-specific context, insufficient capacity to encode rich agent identity data (reputation, transaction history, credentials), microtransaction fees that kill economics at scale, and cross-border settlement that remains slow. At that point, the market naturally shifts to Crypto infrastructure.

This means Crypto solutions don’t need to beat Stripe today. Instead, they need to perfect the infrastructure over the next 3–5 years, so that when Stage 2 limitations peak, they can take over. Right now, it’s an infrastructure race, not a market-share battle.

Of course, infrastructure must be in place ahead of time, but infrastructure alone does not drive adoption—it requires an application-layer breakout to activate it. TCP/IP was invented in the 1970s, but it wasn’t widely used until the World Wide Web browser appeared in the 1990s.

Currently, we can see infrastructure gradually improving, but nobody is using it at scale yet. For example, x402 in most of 2025 was technically ready but lacked killer use cases. 

We need more applications to emerge and link these infrastructure pieces into a usable stack. The explosive adoption of OpenClaw/Moltbook is the first visible demand engine—suddenly, hundreds of thousands of Agents need payment, identity, and reputation, turning x402 and 8004 from “available” to “actively used.”

Selling Shovels Beats Panning for Gold

The entire Base Lobster ecosystem validates an old investment adage: the most reliable way to profit during a gold rush is to sell shovels.

Felix made $75,000. But Clanker, from 64,000 token deployments, earned far more in fees. ClawRouter sells LLM routing services ($0.003 per request). ClawCloud sells Agent compute power. Venice sells reasoning capacity and financializes compute via the VVV/DIEM model. The business models of these infrastructure providers are far more mature and reliable than Agents making money autonomously.

The infrastructure that all Agent categories need—identity, payments, security, coordination, compute resources—will be required regardless of which Agent framework wins (OpenClaw, IronClaw, or OpenAI’s next-generation products).

The term “Claws” coined by Karpathy captures a trend bigger than OpenClaw itself—localized, persistent, autonomous AI Agents represent an entire category. Crypto infrastructure must serve the whole Claw category. IronClaw (Near’s TEE-secured version), various enterprise-custom Agent frameworks, and OpenAI’s upcoming integrated Agents all belong to this category. OpenClaw is a pioneer, but it will not be the only player.

Product-Agent Fit Will Replace Product-Market Fit

Multiple platforms have begun banning OpenClaw user accounts, because Agents simulate browser operations to bypass anti-scraping mechanisms. The platform operators and Agent users are inherently at odds. Platforms monetize human attention, but Agent users consume data without generating advertising value.

Traditional marketing relies on the attention economy—beautiful images, video ads, limited-time buttons—targeting human impulse. Agents, however, are perfectly rational decision-makers, caring only about whether API returns are clear and parameters are complete. They compare product specs, historical prices, delivery times, user reviews, even carbon footprint. There is no mindshare to capture.

Future moats won’t be built on brand (Agents don’t care about brands), nor on UX (Agents don’t use interfaces), but on data structuring, API stability, MCP compatibility, and on-chain verifiable service quality records.

Internet business models may shift toward pay-per-scrape: Agents as service consumers no longer rely on ad-supported free models but pay directly for data retrieval. Each data query, API call, or service usage requires a small payment and ensures compliant access for the Agent. This is exactly the problem x402 solves—directly paying for data access while supporting microtransactions. Early forms are already emerging: Lord of a Few launched over 80 x402 paid endpoints in one week, each costing $0.50 to build and charging a few cents to tens of cents per call.

Moreover, when both buyers and sellers are Agents, how is the profit pool redistributed?

Conclusion

We are in a rare window of opportunity: the infrastructure is in place, but killer applications have yet to emerge. History has repeatedly shown that true transformation does not announce itself in advance—it only strikes unexpectedly, at a moment when everyone suddenly realizes that the old world is over.

References

[1] McKinsey & Company, “The Agentic Commerce Opportunity,” 2025.

[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

[6] x402 White Pape

[7] EIP-8004

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

[9] Virtuals Protocol Documentation

[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.

The post AI Agent Economic Infrastructure Research Report appeared first on BeInCrypto.

Source link