WalletConnect integration in WAIaaS means your Claude Desktop agent doesn't just send transactions — it can 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.