WalletConnect in Claude Desktop: Mobile Approval for AI Agent Transactions

WAIaaS integrates WalletConnect into Claude Desktop, enabling AI agents to request mobile approval for high-stakes blockchain transactions. The system uses a 4-tier security model—INSTANT, NOTIFY, DELAY, and APPROVAL—where the APPROVAL tier pauses transactions until the wallet owner approves via their phone. This provides a human-in-the-loop safety net while allowing routine transactions to proceed automatically.

WalletConnect integration in WAIaaS means your Claude Desktop agent doesn't just send transactions — it can pause and ask you to approve them from your phone. If you've been exploring MCP tools that let Claude interact with blockchains, this is the piece that closes the loop: an AI agent that executes onchain actions, governed by policies you set, with a human-in-the-loop safety net when the stakes are high enough to warrant one. Giving an AI agent a wallet is straightforward. Trusting it completely with that wallet is a different question. Most developers building onchain agents eventually hit the same wall: they want the agent to move fast on small, routine transactions, but they want a human checkpoint before anything significant happens. WAIaaS approaches this with a 4-tier security model — INSTANT, NOTIFY, DELAY, and APPROVAL — built directly into its policy engine. The APPROVAL tier is where WalletConnect comes in. When a transaction exceeds your configured threshold, the daemon holds it in a pending state and fires an approval request to the wallet owner's mobile device. You tap approve or reject. The agent waits. Nothing moves without your sign-off. That's not a workaround. That's the intended architecture. Before getting into WalletConnect mechanics, it helps to understand how WAIaaS fits into your Claude Desktop setup. WAIaaS is, among other things, an MCP server exposing 45 tools across wallet, transaction, DeFi, NFT, and x402 categories. From Claude's perspective, it's just another entry in claude desktop config.json . Add this: { "mcpServers": { "waiaas": { "command": "npx", "args": "-y", "@waiaas/mcp" , "env": { "WAIAAS BASE URL": "http://127.0.0.1:3100", "WAIAAS SESSION TOKEN": "wai sess <your-token ", "WAIAAS DATA DIR": "~/.waiaas" } } } } Restart Claude Desktop. Claude now has access to 45 MCP tools including wc-connect , wc-disconnect , wc-status , get-balance , send-token , get-defi-positions , simulate-transaction , and more. The WalletConnect tools are included in that set — they're not an add-on, they're part of the core MCP surface. Understanding where WalletConnect fits requires a quick look at how WAIaaS structures security: Layer 1 — Session auth: The AI agent authenticates with a session token JWT HS256 . This controls what the agent is allowed to request in the first place. Sessions have configurable TTL, max renewals, and absolute lifetimes. Layer 2 — Policy engine + time delay + approval: Every transaction runs through a 7-stage pipeline. Stage 3 is policy evaluation. If the policy engine assigns the APPROVAL tier to a transaction, it goes into a pending state. Stage 4 is the wait stage — the daemon holds the transaction until either the delay expires or the owner approves. This is where WalletConnect operates. Layer 3 — Monitoring + kill switch: Incoming transaction monitoring with real-time notifications, and the ability to disconnect or revoke at any time. WalletConnect is the mechanism that connects Layer 2's approval gate to the wallet owner's mobile device. The owner connects their wallet via WalletConnect, and from that point forward, APPROVAL-tier transactions surface as signing requests on their phone. The APPROVAL tier isn't triggered automatically on every transaction — you configure it through a SPENDING LIMIT policy. Here's what a typical configuration looks like: curl -X POST http://127.0.0.1:3100/v1/policies \ -H "Content-Type: application/json" \ -H "X-Master-Password: my-secret-password" \ -d '{ "walletId": "<wallet-uuid ", "type": "SPENDING LIMIT", "rules": { "instant max usd": 100, "notify max usd": 500, "delay max usd": 2000, "delay seconds": 900, "daily limit usd": 5000 } }' With these rules: The policy engine enforces default-deny on top of this. Transactions to unwhitelisted tokens are blocked regardless of amount, unless you've explicitly configured ALLOWED TOKENS . This means a misconfigured agent can't accidentally drain a wallet into an unknown contract. From Claude's perspective, when it calls send token and the transaction hits the APPROVAL tier, the tool returns a response indicating the transaction is pending owner approval. The transaction ID is available. Claude can poll get transaction to check status, or simply inform the user that approval is needed. On the owner's side, the WalletConnect request arrives on their phone as a standard wallet signing request — the same UX they'd see for any dApp interaction. They review the transaction details and approve or reject. You can also approve directly via the REST API using ownerAuth if you're not using WalletConnect: curl -X POST http://127.0.0.1:3100/v1/transactions/<tx-id /approve \ -H "X-Owner-Signature: <ed25519-or-secp256k1-signature " \ -H "X-Owner-Message: <signed-message " The ownerAuth uses either ed25519 Solana, Sign In With Solana or secp256k1 EVM, Sign In With Ethereum — matching whichever chain the wallet is on. One practical technique when building agent workflows: use the dry-run flag before sending real transactions. This lets Claude or your code simulate a transaction and see what the policy engine would decide — without actually executing anything. curl -X POST http://127.0.0.1:3100/v1/transactions/send \ -H "Content-Type: application/json" \ -H "Authorization: Bearer wai sess <token " \ -d '{ "type": "TRANSFER", "to": "recipient-address", "amount": "0.1", "dryRun": true }' The MCP tool list also includes simulate-transaction for the same purpose. In an agent workflow, you might instruct Claude to always simulate first and report the policy outcome before asking the user whether to proceed. This surfaces APPROVAL requirements before the user is surprised by a pending transaction. If you're running multiple agents — say, a trading agent and a slower, more conservative treasury agent — you can configure separate wallets with separate policies and expose them as separate MCP servers: { "mcpServers": { "waiaas-trading": { "command": "npx", "args": "-y", "@waiaas/mcp" , "env": { "WAIAAS BASE URL": "http://127.0.0.1:3100", "WAIAAS AGENT ID": "019c47d6-51ef-7f43-a76b-d50e875d95f4", "WAIAAS AGENT NAME": "trading-agent", "WAIAAS DATA DIR": "~/.waiaas" } }, "waiaas-solana": { "command": "npx", "args": "-y", "@waiaas/mcp" , "env": { "WAIAAS BASE URL": "http://127.0.0.1:3100", "WAIAAS AGENT ID": "019c4cd2-86e8-758f-a61e-9c560307c788", "WAIAAS AGENT NAME": "solana-wallet", "WAIAAS DATA DIR": "~/.waiaas" } } } } Each wallet gets its own spending policy. The trading wallet might have a higher INSTANT threshold. The treasury wallet might require APPROVAL for anything over $50. WalletConnect connections and approval flows are per-wallet — you're not sharing a single approval channel across all agents. Here's the minimal path to having WalletConnect-gated approval working in Claude Desktop: Step 1 — Install and start WAIaaS: npm install -g @waiaas/cli waiaas init waiaas start waiaas quickset --mode mainnet quickset creates wallets and MCP sessions in one step. It prints the MCP config JSON you'll need for the next step. Step 2 — Add to Claude Desktop config: Paste the output from quickset into: ~/Library/Application Support/Claude/claude desktop config.json Or auto-register all wallets: waiaas mcp setup --all Step 3 — Create a spending limit policy with APPROVAL tier: Use the SPENDING LIMIT policy example above. Set delay max usd to whatever threshold makes sense for your use case. Anything above that will require explicit approval. Step 4 — Connect WalletConnect via Claude: In Claude Desktop, ask: "Connect my wallet via WalletConnect." Claude calls the wc-connect MCP tool. Scan the QR code with your mobile wallet app. Step 5 — Test the flow: Ask Claude to simulate a large transfer using the simulate-transaction tool. Confirm the policy would trigger APPROVAL. Then try a real transaction above your threshold and watch the mobile approval request arrive. The WalletConnect approval flow is one piece of a larger capability surface. With WAIaaS's 45 MCP tools connected, Claude can: The WalletConnect tools wc-connect , wc-disconnect , wc-status are the bridge that keeps you in the loop for the high-stakes subset of those actions. Everything else can run autonomously within the policy guardrails you've defined. The full list of 21 policy types — including DeFi-specific controls like LENDING LTV LIMIT , PERP MAX LEVERAGE , and VENUE WHITELIST — is documented in the OpenAPI reference at http://127.0.0.1:3100/reference once your daemon is running. For teams deploying WAIaaS in production, the Docker Secrets overlay and auto-provision flow handle credential management without storing passwords in environment variables. If you're building agents that need to interact with blockchains and you want a clear approval boundary between "the agent decides" and "I decide," WAIaaS's WalletConnect integration through MCP is worth an afternoon of exploration.