ChainClaw: A Layered Agent Framework for Reliable On-Chain Execution

The paper, authored by Jiacheng Wei, Zhaoxin Fan, Xin Wen, Yuqin Lan, Dongrun Li, Wenjun Wu, Faguo Wu, and Xiao Zhang (Beihang University, Beijing Advanced Innovation Center for Future Blockchain and Privacy Computing, and Zhongguancun Laboratory), proposes ChainClaw, a blockchain-native agent framework built on top of OpenClaw. The central thesis is that general-purpose large language model (LLM) agents, while successful at conventional tool-augmented tasks, are fundamentally unsuited to blockchain environments due to three structural gaps: Reactivity, Irreversibility, and Observability.

The abstract states: "General-purpose large language model agents have achieved strong performance on tool-augmented tasks, yet they rely on assumptions break down in blockchain environments. On-chain execution is stateful, adversarial, and economically irreversible, exposing three fundamental gaps: Reactivity, Irreversibility, and Observability. ChainClaw addresses all three gaps through a layered architecture comprising an event-driven orchestration layer, a simulation-based safety intelligence layer, and an on-chain monitoring runtime layer, unified by a cross-layer memory subsystem."

The authors argue that conventional agent frameworks treat tool calls as recoverable actions [19, 27], working well for tasks such as information retrieval, file manipulation, and software automation where failures are often correctable after execution. Blockchain breaks this assumption:

"However, blockchain environments expose a fundamentally different execution setting. An on-chain agent does not merely call external tools; it interacts with a stateful, adversarial, and economically sensitive runtime [1, 2, 42]. Once a transaction is signed and broadcast, it may consume gas, alter global state, grant token permissions, or transfer assets in ways that cannot be undone [12, 17, 29]. Moreover, the correctness of an on-chain action depends on live external state, which are not contained in the agent's internal context [33, 40]."

This yields three specific gaps, each tied to a broken implicit assumption of general-purpose frameworks like OpenClaw:

1. Reactivity gap: the assumption that interaction is primarily session-driven is broken by asynchronous on-chain events and delayed transaction outcomes.

2. Irreversibility gap: the assumption that execution is recoverable is broken by irreversible state-changing transactions.

3. Observability gap: the assumption that the agent context contains sufficient task state is broken by live and external blockchain state.

ChainClaw "builds on OpenClaw and reorganizes components into five cooperating layers (orchestration, intelligence, runtime, a cross-cutting memory layer, and chain network), so every action is grounded in live chain state and screened before it touches an irreversible ledger. The flow is described as follows: The orchestration layer accepts two kinds of input: a user request flows through the Gateway, Session, and Planner pipeline, whereas on-chain events are read from live chain state via Chain Read and routed through Event Ingestion into the same Planner. Drawing on RAG-retrieved knowledge and the chain state from Chain Read, the Planner passes the task to the Reasoner. The resulting action first undergoes Simulation, ChainClaw's core safeguard, which tests it before execution and returns control to the Reasoner on failure, then proceeds to the Action Guard and Explainer; if not blocked, it advances to Execution, tracked by the Tx Monitor, and is written through the unified Chain Interface with signing protected by the Key Vault."

A key new module is the Consistency module, which aligns the Planner's output with on-chain state. The memory layer persists identity, observation, knowledge, and ledger records throughout.

The orchestration layer closes the Reactivity gap with a dual-trigger execution model over heterogeneous inputs. ChainClaw processes two input classes: user-driven requests through the Gateway and Session, and chain-driven signals derived from continuously updated live chain state. The live chain state has four categories: Network-level state (global execution context), Wallet-level state (balances, available assets), Protocol-level state (smart contract status, authorization relations), and Execution-level state (transaction lifecycle: pending, confirmed, failed).

The Event Ingestion pipeline comprises the "Event Normalizer (heterogeneous logs into a unified representation), the Dedup Gate (removing duplicates from multi-node propagation), and the Risk Scheduler (priority by urgency and impact), plus a threshold-based circuit breaker that buffers excess events and reintroduces them once load stabilizes."

The Planner is paired with a Consistency module that "reads the on-chain state and retrieves the task's execution trace (transaction previews, guard decisions, execution outcomes, monitoring results), then validates it structurally (schema, step ordering, field completeness, task status) and semantically (cross-module conflicts), issuing one verdict that lets it proceed or triggers replan, retry, or termination."

The Reasoner is restricted to inference only, with no access to private keys or signing, and so cannot trigger state-changing actions directly. Its candidate actions then enter the Simulation module, ChainClaw's core pre-execution safeguard: because blockchain execution is irreversible, simulation is mandatory before any commitment, and an unsafe outcome returns control to the Reasoner for replanning.

The Simulation module operates in three stages: Intake and classification aggregates the relevant context (chain state, prior analysis, and the candidate operation) and labels the action as passive (observation-level) or state-changing (execution-level); "Risk assessment and escalation scores the action against behavioral heuristics (anomalous transaction patterns, cross-chain activity, abnormal frequency), yielding a conservative score that can only increase under further signals; and Certification and reporting verifies data completeness and emits a structured report that flags incomplete chain data and summarizes risk levels, triggered rules, and side effects."

The Action Guard filters residual unsafe behaviors before any state-changing operation via three components:

• Intent screen: applies hard rule-based filters on the simulation output, removing malicious or disallowed actions via deterministic constraints.

• Risk arbitrate: runs an LLM-based second pass over the coarse risk label... it reweighs the address's historical behavior, market conditions, and consistency between intent and chain state to catch ambiguous cases hard rules miss.

• Verdict generation: emits an interpretable decision (why an action is blocked, which factors triggered it, and possible next steps).

The Explainer is the pipeline's final user-facing stage producing human-readable reports pre-commitment. In Blocked mode it reports the decision and rationale, stating which check failed (for instance, unsafe asset movement or abnormal approval). In Cleared mode, it renders a transaction preview that describes, in natural language, what the operation will do, its expected output, and its estimated gas cost, with purely informational requests terminating here without signing.

The Transaction Monitor tracks the transaction lifecycle in real time over three stages: Polling (records submission timestamp, sets timeout, periodically queries the node), Settlement tracking (waits for receipt inclusion and accumulates confirmations until a safety threshold), and Resolution (labels the transaction confirmed on sufficient confirmations or failed on revert/timeout). It streams intermediate updates to the interface, exposing transaction hashes and statuses (pending, confirmed, failed).

The Chain Interface abstracts heterogeneity across blockchains with two stages: commit applies the state transition by permanently recording the transaction on-chain, and broadcast and await submits it to the network and tracks propagation until execution feedback is observed. The Key Vault isolates private-key management from reasoning and execution with authorization checks and cryptographic signing that keeps keys encapsulated, never exposing key material to external modules.

The memory subsystem supports four core capabilities: "(i) persistence, storing execution records durably for recovery after restarts; (ii) cross-session memory, preserving interaction context across sessions; (iii) semantic retrieval, enabling similarity-based access to past experiences beyond key-based lookup; and (iv) compression and decay, periodically summarizing older records to bound growth while retaining essential information."

Benchmark tasks (T1–T7) span four categories:

• Read tasks: T1 (retrieve ETH balance of an address), T2 (retrieve ERC-20 allowance granted to a spender)

• Single-step execution: T3 (transfer 10 USDC), T4 (approve 100 USDC to a contract)

• Multi-step execution: T5 (approve-then-swap workflow when allowance is insufficient)

• Security/anomaly tasks: T6 (adversarial instruction attempting to drain assets, which a correct agent must refuse), T7 (a passively triggered on-chain event requiring appropriate reaction)

Evaluation metrics (each normalized to [0,1]):

• Completion (#CP): the fraction of required steps an agent carries through, computed as completed steps divided by total steps.

• Correctness (#CR): how closely the produced output or constructed operation matches the expected result: field-level F1 for read tasks, and transaction-parameter or operation correctness for execution tasks.

• Safety (#SF): the agent's ability to block illegal operations, computed as 1 − (unblocked illegal operations)/(potential illegal operations), defined over T3–T7.

• Robustness (#RB): stable execution under anomalous or asynchronous conditions, defined over T5 and T7.

• Efficiency (#EF): compares actual usage against a per-task threshold, covering gas, step count, and number of transactions, applied to T3–T5 and T7.

Baselines: ReAct, LangChain, and OpenClaw. Read tasks are executed against live Ethereum mainnet through an Alchemy JSON-RPC endpoint, with contract metadata resolved via the Etherscan API. For state-changing tasks (T3–T7), the pipeline runs through to transaction preview without broadcasting, so gas is estimated rather than realized and Safety is judged at the pre-signing stage. All systems share a single backbone, moonshot-v1-8k, queried with temperature 0.3 and a maximum of 1024 output tokens.

"ChainClaw achieves 1.00 on every metric, while the baselines match it only on read queries and degrade on state-changing and event-driven tasks; since all share the moonshot-v1-8k backbone and decoding settings, the differences reflect architecture, not model capability."

Key findings:

• On reads (T1–T2): all systems complete the queries (#CP=1.00) but the baselines stay at #CR=0.67 against ChainClaw's 1.00.

• On transaction construction (T3–T4): ReAct collapses (#CP=0.29, #SF=0.00), and OpenClaw, despite #CP=0.86, drops to #CR=0.25 on T3 with only partial safety.

• On the adversarial drain (T6): OpenClaw fails to block it (#SF=0.00) while ChainClaw refuses it (#SF=1.00).

• On the passive event (T7): all baselines plateau at 0.67/0.67/1.00/0.67/0.67, and ChainClaw reaches 1.00 on both.

Qualitative case studies show that "For insufficient allowance, ChainClaw reads live state, repairs the plan into approve-then-swap, and completes execution, while OpenClaw fails. For malicious transfer, ChainClaw simulates and blocks the action before signing, while OpenClaw proceeds unsafely—demonstrating gains in Observability, Reactivity, and Irreversibility."

A user study with 12 participants rated an OpenClaw-style baseline and ChainClaw across 3 scenarios on five seven-point Likert dimensions and a forced preference choice. Results: ChainClaw wins on every dimension, with the largest gains on Safety (6.31 vs. 4.18) and Controllability (6.17 vs. 4.51), the dimensions most tied to pre-execution risk, and clear margins on Trust (5.96 vs. 4.35) and Usefulness (6.08 vs. 4.72). ChainClaw also shows lower variance (std 0.55–0.68 vs. 0.91–1.06) indicating broad agreement, and 72.2% prefer it overall.

Reactivity ablations: "Removing event ingestion causes the passively triggered task to collapse (T7 #CP=0.17, #CR=0.00), while session-only handling recovers only partially (T7 #CP=0.70, #RB=0.55). Without simulation feedback, robustness drops on multi-step and drain tasks (#RB=0.55 on T5 and 0.58 on T6), and one-shot reasoning similarly degrades T5 (0.90/0.84/0.90/0.62/0.78)."

Irreversibility ablations: "Removing simulation lowers correctness and safety on state-changing tasks (T3 #CR=0.72, #SF=0.70; T6 #SF=0.65), and simplified simulation only partially recovers safety (T6 #SF=0.80). Removing the action guard preserves completion but severely reduces safety, especially on the malicious drain where T6 #SF falls to 0.00. A rules-only guard also remains insufficient (T6 #SF=0.60)."

Observability ablations: "Removing on-chain read hurts both read tasks (T1 #CP=0.50, #CR=0.33) and state-dependent execution (T6 #CR=0.72); weaker reads still cap correctness, e.g., stable read gives T1 #CR=0.78 and partial read gives T2 #CP=0.60. Removing the transaction monitor mainly affects robustness, reducing #RB to 0.45 on T5 and 0.55 on T7, while receipt-only monitoring remains low (T5 #RB=0.50)."

The paper lists three contributions: (1) identifying the Reactivity, Irreversibility, and Observability gaps motivating a dedicated on-chain agent architecture; (2) proposing ChainClaw with its event-driven orchestration layer, simulation-based safety intelligence layer, and on-chain monitoring runtime layer unified by cross-layer memory, which collectively close all three identified gaps; and (3) designing a benchmark covering seven tasks across four categories and five evaluation dimensions, on which ChainClaw consistently outperforms representative baselines on safety and task completion.

The conclusion reiterates the central message: "We presented ChainClaw, an on-chain agent framework that closes the Reactivity, Irreversibility, and Observability gaps left by general-purpose runtimes, through an event-driven orchestration layer, a simulation-based safety intelligence layer, and an on-chain monitoring runtime layer, unified by a cross-layer memory. The results indicate that reliable blockchain-native agency requires a dedicated architecture rather than a stronger model."

Improvements to AI agent systems:

• Add event-driven orchestration so agents can be triggered not only by user prompts but also by external asynchronous state changes (e.g., transaction lifecycle events, protocol emissions, network updates), with a normalizer, deduplication gate, risk-based scheduler, and circuit breaker for event floods.

• Add a consistency module that continuously validates the agent’s plan against live external state and prior execution traces, and issues explicit verdicts: proceed, replan, retry, or terminate.

• Enforce a hard separation between reasoning and action: the reasoner has no access to signing keys or irreversible execution paths, and can only propose actions.

• Make simulation mandatory before any irreversible action. The simulation should classify actions as passive vs. state-changing, score risk using conservative heuristics (anomalous patterns, cross-chain moves, abnormal frequency), and produce a structured certification report that flags incomplete data.

• Add a two-stage action guard: deterministic hard-rule screening for malicious/disallowed actions, followed by an LLM-based second pass that reweighs historical behavior, market conditions, and intent-vs-state consistency; emit an interpretable verdict explaining why an action is blocked or allowed.

• Add a human-readable pre-commitment explainer that describes the planned operation, expected effects, side effects, risk level, triggered rules, and estimated cost in natural language before anything is signed.

• Add a runtime monitoring layer that tracks asynchronous execution through polling, settlement tracking, and resolution stages, streaming intermediate status updates back to the agent so it can react to pending/confirmed/failed outcomes.

• Unify all state through cross-layer memory that persists identity, observations, knowledge, and execution records, supports cross-session recall, semantic retrieval of past experiences, and periodic compression/decay to bound memory growth.

• Abstract blockchain heterogeneity behind a unified chain interface with a key vault that encapsulates private keys and never exposes key material to reasoning or execution modules.

What the improved AI system can do:

• It can operate correctly in blockchain and other high-stakes environments where actions are stateful, adversarial, and economically irreversible, not just in recoverable tool-calling settings.

• It can respond to live on-chain events — e.g., a triggered approval or incoming transfer — without waiting for a new user prompt, and prioritize/deduplicate events under load.

• It can repair multi-step plans based on live state: for example, when a swap fails because of insufficient allowance, it reads on-chain allowance, changes the plan to approve-then-swap, and only then executes.

• It can refuse malicious or unauthorized asset movements before signing: given an adversarial instruction to drain assets, it simulates the action, blocks it via the action guard, and explains the refusal.

• It can show high safety and controllability on irreversible operations: every state-changing action is simulated, risk-scored, filtered by hard rules, arbitrated by an LLM, explained, and only then committed.

• It can track transactions through their full lifecycle and remain robust to pending, reverted, or timed-out outcomes, adapting next steps based on settlement confirmation rather than assuming immediate success.

• It can maintain consistent performance across read tasks, single-step transfers, approvals, multi-step workflows, security attacks, and asynchronous event-driven tasks.