The problem X-Claw solves

The Problem X-Claw Solves

AI agents are getting good at using wallets and making onchain moves.
The problem is not just “can an agent trade?” The real problem is:

How do we let agents trade for us safely?

Without guardrails, users face two risks:

• The agent can take actions the user did not truly want.
• When something goes wrong, it is hard to prove what happened and who approved it.

This trust gap is a major blocker for mainstream adoption of agent-based finance.

How X-Claw Solves It

X-Claw is built around a simple rule:

Agents execute, humans stay in control, and every important action is traceable.

In practice, X-Claw does this by:

• Keeping wallet keys in the local agent runtime.
• Requiring human approval for sensitive actions when policy says so.
• Letting users set policy controls (for example, approval mode and limits).
• Recording a clear action trail across proposal, approval/rejection, and execution status.

What People Can Use It For

• Running an AI trading agent without giving it unlimited power.
• Managing DeFi actions with a “human-in-the-loop” safety layer.
• Supervising multiple agent actions with clearer operational control.
• Reviewing history and decisions when debugging mistakes or resolving disputes.

Why This Matters

Many agent-wallet tools are great at action execution (balance, transfer, swap).
X-Claw focuses on the missing piece: safe autonomy + accountability.

So users do not have to choose between:

• fully manual trading, or
• fully unchecked automation.

X-Claw gives a middle path: automated trading that is easier to trust.

Challenges we ran into

Challenge We Ran Into

One of our hardest bugs was in the approval flow, which is the safety core of X-Claw.

After a user approved a trade, the trade could move very fast from approved to filled or failed.
When that happened, the trade sometimes disappeared from the approvals view, which made it look like approval history was missing.

At the same time, Telegram approval prompts were not always cleaned up correctly. In some cases, message IDs were missing or formatted differently, so cleanup failed and left stale UI state.

Why This Was a Big Problem

Our product promise is safe agent trading with traceability.
If approvals disappear or prompts get out of sync, users lose trust because they cannot clearly see:

• what was approved,
• what executed,
• and what the final result was.

How We Solved It

We fixed this in a few steps:

1. Expanded approval-history logic so trades are still shown after status changes (executing, verifying, filled, failed), not just while pending.
2. Added a dedicated approvals History feed and de-duplication logic so pending rows and history rows do not conflict.
3. Centralized prompt cleanup into runtime commands (approvals clear-prompt / approvals cleanup-spot) instead of scattered cleanup paths.
4. Hardened message-ID extraction to handle both structured JSON output and non-JSON output patterns.
5. Added a fallback: if web cleanup fails (missing_message_id or prompt_not_found), retry cleanup through runtime and reconcile state.
6. Switched from deleting Telegram messages to clearing inline buttons, preserving message history for auditability.

Result

The approval flow became much more reliable and much easier to trust:

• approved trades no longer “disappear” from history,
• Telegram/web approval state stays in sync more often,
• and users get clearer end-to-end traceability from approval to execution outcome.

Use of AI tools and agents

Use of AI Tools and Agents

Our project uses a two layer architecture:

• OpenClaw is the main AI agent.
• X-Claw is the finance skill that OpenClaw calls for wallet, trading, liquidity, and approval actions.

How the system works

1. A user request enters OpenClaw.
2. OpenClaw handles conversation flow and routes finance tasks to X-Claw.
3. X-Claw executes runtime commands for trade, wallet, approvals, and reporting.
4. Results return to OpenClaw and are delivered back to the user.

Approval model

Approvals are policy driven:

• Global Approval ON means new trade proposals are auto approved.
• Global Approval OFF means proposals enter approval pending, unless tokenIn is preapproved.

Policy controls are based on:

• approval_mode for global behavior
• allowed_tokens for token preapproval

Telegram and web approval surfaces

• Telegram

  • Pending approvals show Approve and Deny inline buttons.
  • Callback handling triggers runtime approval decision commands directly.
  • This keeps approval decisions fast inside chat.

• Web app

  • Authorized management on /agents/:id supports approve and reject actions.
  • The same view supports policy controls and approval history.

Why this design matters

This setup combines:

• AI automation for speed
• policy based owner control
• approval flows across Telegram and web
• full lifecycle traceability from proposal to final execution status