DEV Community: Wallet Guy

Hardware-Secured Trading Bots: D'CENT Integration for High-Value DeFi Operations

Wallet Guy — Tue, 07 Jul 2026 10:03:57 +0000

Hardware-Secured Trading Bots: D'CENT Integration for High-Value DeFi Operations

Hardware-secured trading bots are no longer a luxury — for high-value DeFi operations, they're the difference between sleeping soundly and watching your treasury drain overnight. If you're running arbitrage systems, MEV strategies, or algorithmic trading across multiple protocols, you already know the signing layer is your biggest attack surface. WAIaaS addresses this directly with D'CENT hardware wallet integration for human-in-the-loop signing, wrapped inside a full-stack wallet infrastructure designed for automated agents.

Why the Signing Layer Is Your Biggest Risk

Most trading bot architectures treat the private key as an operational detail — stuff it in an environment variable, load it at runtime, sign transactions in memory. That works until it doesn't. Compromised servers, leaked .env files, supply chain attacks on npm packages — any of these can drain a hot wallet in seconds. The faster your bot executes, the faster an attacker can too.

At the same time, pure cold storage doesn't work for automated systems. You can't physically approve every Jupiter swap or Drift perp position. What you actually need is a tiered system: most operations run automatically under defined rules, but specific high-value transactions require hardware confirmation. That's the model WAIaaS is built around.

What WAIaaS Provides for Trading Bot Infrastructure

Before getting into the hardware security angle, it's worth understanding what's underneath. WAIaaS is a 15-package monorepo running a daemon process that exposes 39 REST API route modules. Your trading bot talks to this daemon via a session token — the bot never touches private keys directly.

The infrastructure includes:

15 DeFi protocol providers: aave-v3, across, dcent-swap, drift, erc8004, hyperliquid, jito-staking, jupiter-swap, kamino, lido-staking, lifi, pendle, polymarket, xrpl-dex, zerox-swap
7 transaction types: Transfer, TokenTransfer, ContractCall, Approve, Batch, NftTransfer, ContractDeploy
7-stage transaction pipeline: validate → auth → policy → wait → execute → confirm
45 MCP tools for AI agent integration
2 chain types (EVM and Solana) across 18 networks

For a trading bot, the relevant part is that you get a single API surface for Jupiter swaps, Drift perpetuals, Hyperliquid spot and perps, LI.FI bridging, and Across cross-chain — with the same auth model and the same policy engine governing all of them.

D'CENT Integration: Hardware-in-the-Loop for High-Value Ops

The D'CENT integration in WAIaaS is implemented as a signing channel — specifically one of three signing channels (push-relay-signing-channel, telegram-signing-channel, wallet-notification-channel) that route transaction approval requests to external signers.

What this means practically: your bot submits a transaction through the standard API. The transaction hits the 7-stage pipeline. At the policy stage, if the transaction exceeds your APPROVAL tier threshold, the pipeline pauses and routes the signing request to your D'CENT device. You physically confirm on the hardware wallet. The pipeline resumes and executes.

For trading operations, you configure this threshold carefully. You might want:

Small rebalancing trades (< $100) to execute instantly with no friction
Medium-sized swaps ($100–$1,000) to notify you but execute automatically
Large position entries ($1,000–$10,000) to delay 15 minutes, giving you a cancellation window
Anything above $10,000 or unusual contract interactions to require D'CENT hardware confirmation

Configuring the Policy Engine for Trading Operations

The policy engine has 21 policy types. For a trading bot, the core ones you'll configure are SPENDING_LIMIT, CONTRACT_WHITELIST, ALLOWED_TOKENS, PERP_MAX_LEVERAGE, PERP_MAX_POSITION_USD, PERP_ALLOWED_MARKETS, and VENUE_WHITELIST.

Start with a SPENDING_LIMIT that maps to your risk tolerance:

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
    }
  }'

This gives you four tiers: instant execution under $100, notification at $100–$500, 15-minute delay at $500–$2,000, and full APPROVAL (via D'CENT or other signing channel) above $2,000. The delay_seconds: 900 means large trades queue for 15 minutes — enough time to catch anomalous bot behavior before it executes.

The policy system is default-deny. If you don't configure ALLOWED_TOKENS, token transfers are blocked. If you don't configure CONTRACT_WHITELIST, contract calls are blocked. This is intentional — a compromised session token can't suddenly start sending tokens to unknown addresses or calling arbitrary contracts.

For perpetual futures operations on Hyperliquid or Drift, you have dedicated policy types:

{"type": "PERP_MAX_LEVERAGE", "rules": {"max_leverage": 10}}
{"type": "PERP_MAX_POSITION_USD", "rules": {"max_position_usd": 50000}}
{"type": "PERP_ALLOWED_MARKETS", "rules": {"markets": ["BTC-USD", "ETH-USD", "SOL-USD"]}}

These enforce risk limits at the infrastructure level, not the application level. Even if your bot's logic has a bug and tries to open a 50x leveraged position in a small-cap market, the policy engine blocks it before the transaction ever reaches the chain.

Gas Conditional Execution

One of the more useful features for trading bots is gas conditional execution — transactions execute only when gas price meets your configured threshold. For EVM operations, this means your bot can queue a transaction and the pipeline will wait until gas drops below your threshold before executing.

This matters for strategies that aren't time-critical. If you're rebalancing a Aave position or collecting yield, there's no reason to pay peak gas. Queue the transaction, set your gas condition, and let the pipeline handle timing. Your bot doesn't need to implement gas monitoring logic — it's handled at the infrastructure layer.

Executing Multi-Protocol Trading Strategies

Here's what a real trading operation looks like through the API. Your bot spots an arbitrage opportunity: buy on Jupiter, hedge the delta on Drift. Two separate calls, one session token:

# Leg 1: Swap on Jupiter
curl -X POST http://127.0.0.1:3100/v1/actions/jupiter-swap/swap \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer wai_sess_<token>" \
  -d '{
    "inputMint": "So11111111111111111111111111111111111111112",
    "outputMint": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
    "amount": "1000000000"
  }'

Before committing to the trade, your bot can simulate first:

# Dry-run to validate before execution
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 dry-run API lets you simulate transactions before execution. For arb systems where execution failure has a cost (locked capital, partial fills), validating the transaction path before committing is worth the extra round-trip.

If a transaction hits the APPROVAL tier and needs D'CENT confirmation, the approval endpoint is:

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 owner authentication uses ed25519 or secp256k1 signatures — the same cryptographic primitives your hardware wallet produces. D'CENT signs the approval message, you pass the signature to the endpoint, the pipeline resumes.

Three-Layer Security Model

WAIaaS uses three auth methods that map to three distinct principals:

masterAuth (Argon2id): the system operator — creates wallets, manages sessions, sets policies
sessionAuth (JWT HS256): the trading bot — executes transactions within policy bounds
ownerAuth (SIWE/SIWS signatures): the fund owner — approves high-value transactions, emergency kill switch

For a trading operation, your bot only ever holds a session token. That token is scoped to one wallet, operates within the policies you've set, and can be revoked instantly. Session tokens have configurable TTL, maxRenewals, and absoluteLifetime. A compromised session token has bounded damage — it can only do what the policies allow, and only until the token expires.

The owner layer is where D'CENT fits. The fund owner's approval (hardware-signed) is required for APPROVAL-tier transactions. Even if someone gains access to your server and the session token, they cannot move funds that exceed your DELAY threshold without hardware confirmation from the owner.

Quick Start for Trading Bot Builders

Getting a secured trading infrastructure running takes about 10 minutes:

Step 1: Deploy the daemon

docker run -d \
  --name waiaas \
  -p 127.0.0.1:3100:3100 \
  -v waiaas-data:/data \
  -e WAIAAS_AUTO_PROVISION=true \
  ghcr.io/minhoyoo-iotrust/waiaas:latest

docker exec waiaas cat /data/recovery.key

Step 2: Create a trading wallet and session

# Create wallet
curl -X POST http://127.0.0.1:3100/v1/wallets \
  -H "Content-Type: application/json" \
  -H "X-Master-Password: my-secret-password" \
  -d '{"name": "trading-wallet", "chain": "solana", "environment": "mainnet"}'

# Create session for your bot
curl -X POST http://127.0.0.1:3100/v1/sessions \
  -H "Content-Type: application/json" \
  -H "X-Master-Password: my-secret-password" \
  -d '{"walletId": "<wallet-uuid>"}'

Step 3: Set trading policies

Configure SPENDING_LIMIT, CONTRACT_WHITELIST, and ALLOWED_TOKENS before your bot starts operating. Default-deny means nothing works until you explicitly allow it — which is exactly what you want for a production trading system.

Step 4: Connect your bot via SDK

import { WAIaaSClient, WAIaaSError } from '@waiaas/sdk';

const client = new WAIaaSClient({
  baseUrl: process.env['WAIAAS_BASE_URL'] ?? 'http://localhost:3100',
  sessionToken: process.env['WAIAAS_SESSION_TOKEN'],
});

const balance = await client.getBalance();
console.log(`Balance: ${balance.balance} ${balance.symbol} (${balance.chain}/${balance.network})`);

try {
  const tx = await client.sendToken({
    type: 'TRANSFER',
    to: 'recipient-address',
    amount: '0.001',
  });
  console.log(`Transaction submitted: ${tx.id} (status: ${tx.status})`);
} catch (error) {
  if (error instanceof WAIaaSError) {
    console.error(`API Error: [${error.code}] ${error.message}`);
    // Handles: INSUFFICIENT_BALANCE, POLICY_DENIED, TOKEN_EXPIRED
  }
}

Step 5: Explore the API reference

The OpenAPI 3.0 spec is auto-generated and available at /doc. The interactive Scalar API reference UI is at /reference. All 39 route modules are documented there — useful when you're integrating specific DeFi protocol endpoints.

open http://127.0.0.1:3100/reference

Production Hardening

For production deployments handling real capital, use Docker Secrets instead of environment variables:

mkdir -p secrets
echo "your-secure-password" > secrets/master_password.txt
chmod 600 secrets/master_password.txt

docker compose -f docker-compose.yml -f docker-compose.secrets.yml up -d

The secrets overlay (docker-compose.secrets.yml) routes your master password through Docker Secrets rather than environment variables, keeping it out of docker inspect output and process lists.

The daemon runs as a non-root user (UID 1001) and includes healthcheck configuration out of the box. For automated deployments, the entrypoint supports auto-provision mode — useful for ephemeral environments where you don't want to manage password rotation manually.

What's Next

The architecture described here — hardware-confirmed high-value transactions, policy-bounded session tokens, multi-protocol DeFi access through a single API — is the foundation for building trading systems that can actually operate at scale without keeping you up at night. The 683+ test files across the WAIaaS codebase reflect the level of reliability this kind of infrastructure demands.

Explore the full codebase and contribute at GitHub, or check the documentation and deployment guides at waiaas.ai. If you're building something serious on top of this, the 45 MCP tools and OpenClaw plugin are worth looking at for AI agent integration beyond direct API calls.

The API Payment Revolution: Building x402 Infrastructure for Autonomous Machines

Wallet Guy — Mon, 06 Jul 2026 16:28:19 +0000

The API Payment Revolution: Building x402 Infrastructure for Autonomous Machines

AI agents will need to pay for compute, data, and API calls — and right now, almost no infrastructure exists to let them do it autonomously. We talk endlessly about agentic AI, multi-agent systems, and autonomous workflows, but there's a gap nobody likes to admit: agents can't actually pay for things. Not independently. Not without a human holding the credit card somewhere in the loop.

That gap is closing. Here's what the plumbing looks like today.

The Real Problem with "Autonomous" Agents

Spend five minutes with any serious AI agent framework and you'll hit the same wall. The agent can reason, plan, and execute — until it needs to spend money. Then it either stops and asks a human, or it operates inside some pre-funded, centrally managed account that a human topped up before the session started.

That's not autonomous. That's supervised.

The economics of the emerging agent layer are going to look very different from today's SaaS billing. Agents won't pay monthly subscriptions. They'll pay per inference call, per API request, per dataset query. The billing model will look more like a vending machine than a software license — and the machine doing the paying will be the agent itself.

This requires two things working together: a payment protocol that operates at HTTP layer (so agents can pay for API calls inline, without a separate billing integration), and wallet infrastructure that the agent can actually operate. Not wallet infrastructure managed on behalf of the agent. Infrastructure the agent holds and uses directly.

That combination exists today with x402 and WAIaaS. Let's look at how it works.

x402: Payments as HTTP

The x402 HTTP payment protocol is elegant in its simplicity. When an API requires payment, it returns an HTTP 402 ("Payment Required") status with payment terms in the response headers. The client — in this case an AI agent — sees the 402, pays the stated amount using its wallet, attaches a payment receipt to the retry request, and gets the resource.

The entire payment happens inline with the API call. No billing dashboard. No OAuth flow for payment authorization. No human in the loop. The agent reads the 402, executes the payment, and continues.

WAIaaS exposes this as a first-class capability via the x402Fetch method in the TypeScript SDK:

import { WAIaaSClient } from '@waiaas/sdk';

const client = new WAIaaSClient({
  baseUrl: 'http://127.0.0.1:3100',
  sessionToken: process.env.WAIAAS_SESSION_TOKEN,
});

// This fetch handles 402 responses automatically
// If the endpoint charges for access, the agent pays inline
const response = await client.x402Fetch('https://api.example.com/inference-data');

That's it. The agent calls x402Fetch instead of the standard fetch, and WAIaaS handles the 402 negotiation, payment execution, and retry transparently. From the agent's perspective, it made an API call and got data back. The payment was infrastructure.

The MCP layer exposes this same capability as the x402-fetch tool, so agents operating through Claude Desktop or any MCP-compatible host can make paid API calls directly — without custom code.

The Wallet Infrastructure Layer

x402 handles the payment protocol. But the agent still needs a wallet it can actually operate. That's the harder problem.

A wallet an agent can "operate" means several things:

The agent can check its own balance
The agent can sign and submit transactions
The agent can execute DeFi actions (swapping, bridging, staking) without human involvement
The wallet has guardrails so the agent can't do catastrophic things even if it misbehaves or gets compromised

WAIaaS is built specifically for this. It's a self-hosted Wallet-as-a-Service that runs as a daemon — a 15-package monorepo with a REST API, CLI, and MCP server — designed for the case where the "user" is an AI agent rather than a human.

The architecture separates concerns cleanly:

masterAuth (Argon2id): System administrator — creates wallets, manages sessions, sets policies
sessionAuth (JWT HS256): The AI agent — executes transactions within the bounds the admin established
ownerAuth (SIWS/SIWE signatures): The fund owner — approves large transactions, has kill switch access

The agent gets a session token. It uses that token for everything it does. The token operates within whatever policy envelope the admin configured. The owner can intervene at any time via WalletConnect or other signing channels.

What the Agent Can Actually Do

The session token the agent holds is a key to 45 MCP tools and a full REST API. The agent can:

Check balances and portfolio state:

curl http://127.0.0.1:3100/v1/wallet/balance \
  -H "Authorization: Bearer wai_sess_eyJhbGciOiJIUzI1NiJ9..."

Send tokens:

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"
  }'

Execute DeFi operations — including swaps on Jupiter (Solana), lending on Aave v3, perpetual futures on Hyperliquid, prediction market trades on Polymarket, and more across 15 integrated DeFi protocol providers.

curl -X POST http://127.0.0.1:3100/v1/actions/jupiter-swap/swap \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer wai_sess_<token>" \
  -d '{
    "inputMint": "So11111111111111111111111111111111111111112",
    "outputMint": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
    "amount": "1000000000"
  }'

Simulate before executing:

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 dry-run capability matters a lot for autonomous agents. Before committing a transaction, the agent can verify what would happen — simulating outcomes without on-chain consequences. For agents operating in production with real funds, this is the difference between "execute and hope" and "verify then execute."

Every transaction goes through a 7-stage pipeline: validate → auth → policy → wait → execute → confirm. The policy stage is where guardrails live.

The Policy Layer: Autonomy with Guardrails

Here's the tension that makes wallet infrastructure for AI agents genuinely hard: you want the agent to be autonomous, but you don't want it to drain the wallet in one bad decision or one compromised session.

WAIaaS resolves this with a policy engine that enforces constraints at the infrastructure level — not in the agent's code, where they can be bypassed, but in the transaction pipeline itself.

There are 21 policy types organized around 4 security tiers:

INSTANT: Execute immediately, no notification
NOTIFY: Execute immediately, send notification to owner
DELAY: Queue the transaction for N seconds, then execute (cancellable window)
APPROVAL: Require explicit human approval before execution

A spending limit policy wires these tiers to dollar amounts:

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 this policy in place, an agent handling x402 micro-payments (say, $0.01 per API call) operates completely autonomously — those transactions are well under instant_max_usd. A $300 transaction triggers a notification to the owner but still executes. A $1,500 transaction waits 15 minutes, giving the owner a window to cancel if something looks wrong. Anything over $2,000 requires explicit approval.

The policy engine also enforces default-deny on token transfers and contract interactions. If ALLOWED_TOKENS isn't configured, the agent can't transfer any tokens. If CONTRACT_WHITELIST isn't configured, the agent can't call contracts. The default is locked down — you explicitly expand permissions rather than trying to block bad behaviors after the fact.

For DeFi-specific risk management, there are policies like LENDING_LTV_LIMIT (caps loan-to-value ratio in lending protocols), PERP_MAX_LEVERAGE (maximum leverage on perpetual futures positions), and PERP_MAX_POSITION_USD (maximum position size). An agent managing a treasury or yield strategy operates within these bounds automatically — the infrastructure enforces the risk parameters, not the agent's code.

The x402 domain whitelist is particularly relevant here:

{"domains": ["api.example.com", "*.openai.com"]}

The X402_ALLOWED_DOMAINS policy restricts which domains the agent can make x402 payments to. An agent authorized to pay for inference and data APIs can't suddenly start paying arbitrary addresses — only the domains you've explicitly approved.

Getting This Running

The fastest path from zero to a working agent wallet is through the CLI:

npm install -g @waiaas/cli
waiaas init                        # Create data directory + config.toml
waiaas start                       # Start daemon (sets master password on first run)
waiaas quickset --mode mainnet     # Create wallets + MCP sessions in one step

After quickset, you'll have wallet addresses, session tokens, and an MCP configuration you can paste directly into Claude Desktop. The waiaas mcp setup --all command auto-registers everything with Claude.

If you prefer Docker:

docker run -d \
  --name waiaas \
  -p 127.0.0.1:3100:3100 \
  -v waiaas-data:/data \
  -e WAIAAS_AUTO_PROVISION=true \
  ghcr.io/minhoyoo-iotrust/waiaas:latest

docker exec waiaas cat /data/recovery.key

The WAIAAS_AUTO_PROVISION=true flag generates a random master password on first start and writes it to recovery.key. You can harden it later with waiaas set-master once you've confirmed everything is running.

For production deployments, Docker Secrets integration avoids environment variable exposure:

mkdir -p secrets
echo "your-secure-password" > secrets/master_password.txt
chmod 600 secrets/master_password.txt

docker compose -f docker-compose.yml -f docker-compose.secrets.yml up -d

The Agent Economy Isn't Hypothetical

It's worth being direct about where this stands: x402 payments and autonomous agent wallets aren't speculative architecture. They work today. WAIaaS has 45 MCP tools covering wallet operations, token transfers, DeFi positions, NFT management, and x402 payments. It supports 18 networks across EVM and Solana. The TypeScript and Python SDKs exist, are documented, and have working code.

What's still early is the supply side — the number of APIs that return 402 responses and accept x402 payments. That ecosystem is growing. But the agent-side infrastructure, the part that lets an agent receive a 402, execute a payment, and continue — that part is ready.

ERC-8004 trustless agent reputation (exposed via WAIaaS's erc8004-get-reputation and erc8004-get-validation-status MCP tools) adds another dimension: agents that can prove their behavioral track record on-chain. When one agent is evaluating whether to transact with another agent — or when a human owner is deciding how much autonomy to grant — on-chain reputation becomes the trust primitive that makes multi-agent economic interactions possible without requiring human mediation for every handshake.

The picture coming into focus: agents with wallets, operating under policy guardrails, paying for API calls inline via x402, and establishing trust through on-chain reputation. Not science fiction. Infrastructure you can deploy this afternoon.

What's Next

The GitHub repository at https://github.com/minhoyoo-iotrust/WAIaaS has the full codebase, including the Docker Compose setup, CLI, and SDK packages. The OpenAPI spec is auto-generated and served at /doc with an interactive Scalar UI at /reference once your daemon is running — which is the fastest way to explore the full 39-route API surface.

If you're building agent infrastructure and thinking seriously about how autonomous systems participate in economic activity, https://waiaas.ai is worth bookmarking. The agent economy is going to need payment rails that work at machine speed, and the foundation for that is being built in the open right now.

Trustless Trading Bots: ERC-8004 Onchain Reputation for Automated DeFi

Wallet Guy — Mon, 06 Jul 2026 11:08:29 +0000

Trustless Trading Bots: ERC-8004 Onchain Reputation for Automated DeFi

Trustless trading bots that execute DeFi strategies autonomously sound great until you ask the hard question: how does anyone — a protocol, a counterparty, a smart contract — actually verify that your bot is what it claims to be? Reputation in DeFi has always been fragile, off-chain, and easy to fake. ERC-8004 changes that, and WAIaaS ships with native support for it alongside 15 integrated DeFi protocols — so you can build a bot that doesn't just trade, but proves itself onchain.

Why Onchain Agent Reputation Actually Matters

If you've built a DeFi trading bot before, you've dealt with the trust problem from the other direction: you're the one who has to trust the protocols, the oracles, the RPC endpoints. But as automated agents become more capable — executing multi-step strategies across Jupiter swaps, Aave lending positions, Hyperliquid perps, and Lido staking in a single session — the question flips. Protocols, DAOs, and other agents need a way to trust your bot.

ERC-8004 is a standard for onchain agent reputation and validation. Instead of your bot just asserting "I'm authorized," it can present cryptographically verifiable reputation data that lives on-chain. This matters for DeFi specifically because you're often interacting with smart contracts that could gate access, apply different fee tiers, or require proof of trustworthiness before allowing high-value operations. Without something like ERC-8004, your bot is a black box to everyone it interacts with.

WAIaaS has built ERC-8004 support directly into its architecture — both as a DeFi action provider (erc8004 in the protocol list) and as MCP tools (erc8004-get-agent-info, erc8004-get-reputation, erc8004-get-validation-status) that AI agents can call directly. Combined with 14 other protocol integrations and a policy engine that enforces rules before any transaction executes, it's the infrastructure layer for building bots that are both capable and verifiable.

The Protocol Stack Your Bot Actually Needs

Let's be concrete. A serious DeFi trading bot in 2026 isn't just doing spot swaps. It's managing positions across multiple layers: swapping on DEXes, lending/borrowing for leverage, staking idle assets, bridging between chains, and sometimes trading perps. WAIaaS integrates 15 DeFi protocol providers:

EVM side: Aave v3 (lending), Lido (liquid staking), 0x Swap, LI.FI (cross-chain bridging), Across (bridging), Pendle (yield tokenization), Polymarket (prediction markets)

Solana side: Jupiter Swap, Kamino (lending/vaults), Jito (liquid staking), Drift (perpetuals), D'CENT swap, XRPL DEX

Cross-chain/meta: Hyperliquid (perpetuals and spot), ERC-8004 (agent reputation)

Instead of maintaining 15 separate SDKs, authentication flows, and error handling implementations, you make a single API call pattern. Here's what executing a Jupiter swap looks like:

curl -X POST http://127.0.0.1:3100/v1/actions/jupiter-swap/swap \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer wai_sess_<token>" \
  -d '{
    "inputMint": "So11111111111111111111111111111111111111112",
    "outputMint": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
    "amount": "1000000000"
  }'

That's SOL → USDC on Jupiter. The same Authorization header and the same request pattern works across every protocol. Your bot doesn't need to know how Jupiter constructs its versioned transactions under the hood — that complexity lives inside WAIaaS.

ERC-8004: Wiring in Onchain Reputation

Here's where it gets interesting for trustless systems. The erc8004 provider in WAIaaS exposes three MCP tools that your bot can call:

erc8004-get-agent-info — retrieve the onchain identity and metadata for an agent
erc8004-get-reputation — query the reputation score for an agent address
erc8004-get-validation-status — check whether an agent passes validation for a given context

These aren't just read operations for curiosity. In a production system, you'd wire erc8004-get-validation-status into your bot's pre-trade logic. Before your bot interacts with another agent's positions, or before you allow an external agent to trigger actions on your wallet, you check its validation status first.

WAIaaS also exposes this at the policy layer via the REPUTATION_THRESHOLD policy type. You can set a minimum onchain reputation score that any agent must meet before transactions are allowed — enforced by the policy engine before execution, not as an afterthought in application code:

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": "REPUTATION_THRESHOLD",
    "rules": {
      "min_reputation_score": 80
    }
  }'

This is the default-deny philosophy applied to agent trust: unless an interacting agent meets your reputation threshold, the transaction doesn't happen. The policy engine enforces it at stage 3 of the 7-stage transaction pipeline, before execution ever reaches the protocol layer.

The 7-Stage Pipeline: Where Safety Lives

Speaking of the pipeline — understanding it matters for bot builders because it's where all your safety guarantees actually live. Every transaction, whether it's a Jupiter swap or an Aave borrow, goes through these stages:

Validate — schema and parameter validation
Auth — verify the session token
Policy — check all applicable policies (this is where REPUTATION_THRESHOLD, SPENDING_LIMIT, CONTRACT_WHITELIST, etc. all fire)
Wait — enforce time delays if the DELAY tier was triggered
Execute — broadcast to the network
Confirm — wait for confirmation

The policy check at stage 3 is comprehensive. For a DeFi bot, the relevant policy types include:

SPENDING_LIMIT — 4-tier security (INSTANT/NOTIFY/DELAY/APPROVAL) based on USD value
CONTRACT_WHITELIST — only listed contracts can be called (default-deny)
ALLOWED_TOKENS — only listed tokens can be transferred (default-deny)
ALLOWED_NETWORKS — restrict execution to specific chains
PERP_MAX_LEVERAGE — cap leverage on Hyperliquid or Drift positions
PERP_MAX_POSITION_USD — cap total position size
PERP_ALLOWED_MARKETS — whitelist which perp markets the bot can trade
LENDING_LTV_LIMIT — prevent over-leveraged borrows on Aave
LENDING_ASSET_WHITELIST — control which assets can be used as collateral
VENUE_WHITELIST — restrict which trading venues are accessible
ACTION_CATEGORY_LIMIT — cap activity within DeFi action categories

That's 11 policy types directly relevant to DeFi trading, out of 21 total. For a bot managing real funds, you'd typically layer several of these together. Here's a spending limit that creates meaningful safety tiers for an automated strategy:

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
    }
  }'

Transactions under $100 execute immediately. $100-$500 execute but trigger a notification to the owner. $500-$2000 get queued for 15 minutes, cancellable by the owner via WalletConnect. Above $2000, the bot needs explicit human approval before anything moves.

Simulate Before You Execute

One of the most practical features for bot development is the dry-run API. Before you wire up a new strategy to live funds, you can simulate the full transaction — including policy checks — without broadcasting to the network:

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 dryRun: true flag runs the full pipeline except the execute and confirm stages. If your CONTRACT_WHITELIST would block this transaction, you find out in simulation, not after a failed on-chain transaction. If the SPENDING_LIMIT would route it to the DELAY tier instead of INSTANT, simulation tells you that too.

This is table stakes for any serious bot development workflow — you should know exactly what the policy engine will do before you deploy.

Building the Bot: TypeScript SDK

For production bots, the REST API is fine but the TypeScript SDK is cleaner. Here's a simplified example of a bot that checks its wallet state, executes a strategy, and polls for confirmation:

import { WAIaaSClient, WAIaaSError } from '@waiaas/sdk';

const client = new WAIaaSClient({
  baseUrl: process.env['WAIAAS_BASE_URL'] ?? 'http://localhost:3100',
  sessionToken: process.env['WAIAAS_SESSION_TOKEN'],
});

// Check balance before executing
const balance = await client.getBalance();
console.log(`Balance: ${balance.balance} ${balance.symbol} (${balance.chain}/${balance.network})`);

// Execute the strategy
const sendResult = await client.sendToken({
  type: 'TRANSFER',
  to: 'recipient-address',
  amount: '0.001',
});
console.log(`Transaction submitted: ${sendResult.id} (status: ${sendResult.status})`);

// Poll for confirmation
const POLL_TIMEOUT_MS = 60_000;
const startTime = Date.now();
while (Date.now() - startTime < POLL_TIMEOUT_MS) {
  const tx = await client.getTransaction(sendResult.id);
  if (tx.status === 'COMPLETED') {
    console.log(`Confirmed! Hash: ${tx.txHash}`);
    break;
  }
  if (tx.status === 'FAILED') {
    console.error(`Failed: ${tx.error}`);
    break;
  }
  await new Promise(resolve => setTimeout(resolve, 1000));
}

Error handling is worth calling out explicitly — policy denials come back as structured errors, not generic HTTP 4xx responses:

try {
  const tx = await client.sendToken({ to: '...', amount: '1.0' });
} catch (error) {
  if (error instanceof WAIaaSError) {
    console.error(`API Error: [${error.code}] ${error.message}`);
    // error.code examples: INSUFFICIENT_BALANCE, POLICY_DENIED, TOKEN_EXPIRED
  }
}

A POLICY_DENIED error with domain: "POLICY" tells you exactly what stopped the transaction. Your bot can branch on error codes — retry with a smaller amount, alert the operator, or fail gracefully — instead of parsing error message strings.

45 MCP Tools for AI-Native Bots

If you're building an AI agent rather than a traditional algorithmic bot, the MCP integration gives Claude (or any MCP-compatible model) direct access to 45 tools covering wallet operations, transactions, DeFi positions, NFTs, and ERC-8004 reputation queries. The setup is minimal:

waiaas mcp setup --all    # Auto-register all wallets with Claude Desktop

The tools include the full ERC-8004 surface (erc8004-get-agent-info, erc8004-get-reputation, erc8004-get-validation-status), DeFi position queries (get-defi-positions, get-health-factor), and trading actions (send-batch, simulate-transaction, x402-fetch). An AI agent can check its own reputation, verify counterparty agents, and execute multi-protocol strategies through the same tool interface.

Quick Start for DeFi Developers

Here's the minimal path from zero to a running bot with policy guardrails:

1. Start the daemon:

git clone https://github.com/minhoyoo-iotrust/WAIaaS.git
cd WAIaaS
docker compose up -d

2. Create a wallet and session:

curl -X POST http://127.0.0.1:3100/v1/wallets \
  -H "Content-Type: application/json" \
  -H "X-Master-Password: my-secret-password" \
  -d '{"name": "trading-wallet", "chain": "solana", "environment": "mainnet"}'

curl -X POST http://127.0.0.1:3100/v1/sessions \
  -H "Content-Type: application/json" \
  -H "X-Master-Password: my-secret-password" \
  -d '{"walletId": "<wallet-uuid>"}'

3. Apply DeFi-specific policies (PERP_MAX_LEVERAGE, CONTRACT_WHITELIST, SPENDING_LIMIT) using the policy API shown above.

4. Simulate your first action with dryRun: true to verify policy behavior before using live funds.

5. Install the SDK and connect your strategy:

npm install @waiaas/sdk

The OpenAPI spec auto-generated at /doc and interactive Scalar UI at /reference give you the full endpoint reference while you're building.

What's Next

The 15 protocol integrations, 21 policy types, and ERC-8004 reputation tools are all documented in the interactive API reference at http://localhost:3100/reference once you're running. The GitHub repo has the full codebase, including the 683+ test files that cover the pipeline stages and policy engine — useful reading if you want to understand exactly how policy enforcement works before trusting it with real funds.

Start building at github.com/minhoyoo-iotrust/WAIaaS and find protocol documentation, deployment guides, and SDK references at waiaas.ai.

Self-Updating Crypto Infrastructure: Watchtower + GHCR for AI Agent Wallets

Wallet Guy — Sun, 05 Jul 2026 14:51:29 +0000

Self-Updating Crypto Infrastructure: Watchtower + GHCR for AI Agent Wallets

Self-hosted wallet infrastructure for AI agents sounds like a weekend project that ends in tears — until you realize one Docker command is genuinely all it takes to get started. But getting it running is only half the battle. The harder question is: how do you keep it updated without babysitting a server? That's where Watchtower and GitHub Container Registry (GHCR) come in, and it's a combination worth understanding if you care about running your own infrastructure.

Why Self-Hosting Your AI Agent's Wallet Actually Matters

Would you trust a third party with your AI agent's private keys?

That's not a rhetorical scare tactic — it's a genuine architectural question that comes up the moment you start building AI agents that need to move money. When you hand wallet custody to a hosted service, you're also handing over your transaction history, your rate limits, your uptime dependency, and in the worst case, your keys themselves.

The self-hosted philosophy here is familiar to anyone who runs their own email server, Nextcloud instance, or Home Assistant setup: you trade some operational overhead for complete sovereignty. Your keys live on your hardware. Your transaction data doesn't leave your network. You set the rules.

What makes WAIaaS compelling for this crowd specifically is that it isn't just a wallet — it's a full Wallet-as-a-Service daemon that an AI agent can call via REST API or MCP tools. The agent gets a session token. The session token has policies. The policies define what the agent can and cannot do with your funds. All of that runs on your server, behind your firewall, without any third party in the loop.

But let's talk about the part that usually gets skipped in self-hosting guides: keeping the thing updated.

The Update Problem for Self-Hosted Services

Here's how update management usually goes for self-hosted projects:

You deploy version X.
Version X+1 comes out with a security fix.
You find out three weeks later from a forum post.
You SSH in, pull the new image, restart the service.
Repeat forever.

For a homelab running Jellyfin, this is mildly annoying. For infrastructure that AI agents use to sign and broadcast transactions, stale software is a genuine risk. Security patches, bug fixes, and new protocol support all matter here.

WAIaaS publishes its Docker image to GHCR at ghcr.io/minhoyoo-iotrust/waiaas:latest. The :latest tag is the conventional signal that you want the most current stable build. Watchtower is the conventional tool for polling that tag and rolling updates automatically.

Together, they solve the update problem without requiring you to log into your server.

What WAIaaS Actually Runs

Before getting into the update mechanics, it helps to understand what you're deploying.

WAIaaS is a 15-package monorepo that ships as two Docker images: the main daemon and a push-relay service. The daemon is the piece most people care about — it's the REST API server that AI agents talk to.

That API has 39 route modules covering wallets, transactions, DeFi actions, NFTs, sessions, policies, and more. It supports 18 networks across EVM and Solana chain types. It has 15 DeFi protocol integrations including Jupiter, Aave v3, Lido, Jito, Hyperliquid, Polymarket, and others.

The transaction pipeline has 7 stages — validate, auth, policy, wait, execute, confirm — and a policy engine with 21 policy types and 4 security tiers (INSTANT, NOTIFY, DELAY, APPROVAL). Default-deny enforcement means if you haven't explicitly whitelisted a token or contract, the transaction gets blocked.

For AI agent integration, there are 45 MCP tools covering wallet operations, transfers, DeFi positions, NFTs, and x402 payments. The CLI has 20 commands for everything from quickstart to backup create to mcp setup.

This is not a toy. Keeping it updated matters.

Getting It Running: One Docker Command

The fastest path to a running instance:

docker run -d \
  --name waiaas \
  -p 127.0.0.1:3100:3100 \
  -v waiaas-data:/data \
  -e WAIAAS_AUTO_PROVISION=true \
  ghcr.io/minhoyoo-iotrust/waiaas:latest

# Retrieve auto-generated master password
docker exec waiaas cat /data/recovery.key

The WAIAAS_AUTO_PROVISION=true flag tells the entrypoint to generate a master password on first start and write it to /data/recovery.key. You retrieve it once, store it somewhere safe, and the daemon is ready.

The port binding 127.0.0.1:3100:3100 is intentional — it keeps the API localhost-only by default, so you're not accidentally exposing wallet infrastructure to the internet.

For anything beyond a quick test, Docker Compose gives you a cleaner setup:

services:
  daemon:
    image: ghcr.io/minhoyoo-iotrust/waiaas:latest
    container_name: waiaas-daemon
    ports:
      - "127.0.0.1:3100:3100"
    volumes:
      - waiaas-data:/data
    environment:
      - WAIAAS_DATA_DIR=/data
      - WAIAAS_DAEMON_HOSTNAME=0.0.0.0
    env_file:
      - path: .env
        required: false
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3100/health"]
      interval: 30s
      timeout: 5s
      start_period: 10s
      retries: 3

volumes:
  waiaas-data:
    driver: local

A few things worth noting in this compose file:

restart: unless-stopped means the daemon survives reboots.
The healthcheck polls /health every 30 seconds, so you'll know if something goes wrong.
Data lives in a named volume, so docker compose down doesn't wipe your wallets. Only docker compose down -v does.

Production Secrets: Not Just Environment Variables

If you're running this seriously, hardcoded environment variables in compose files aren't the right approach for sensitive values. WAIaaS ships with a Docker Secrets overlay pattern via docker-compose.secrets.yml.

# Create secret files
mkdir -p secrets
echo "your-secure-password" > secrets/master_password.txt
chmod 600 secrets/master_password.txt

# Deploy with secrets overlay
docker compose -f docker-compose.yml -f docker-compose.secrets.yml up -d

Secret files are mounted into the container at runtime rather than baked into environment variables that might show up in docker inspect or process listings. This is the right approach for production deployments, especially on shared hardware.

Adding Watchtower for Automatic Updates

Watchtower is a container that watches your other containers and restarts them when their upstream image is updated. It works by periodically checking the registry for newer digests matching the tag you're tracking.

Adding it to your compose setup is straightforward — here's the concept in a standalone docker run to keep things clear:

docker run -d \
  --name watchtower \
  -v /var/run/docker.sock:/var/run/docker.sock \
  containrrr/watchtower \
  --interval 86400 \
  waiaas-daemon

This tells Watchtower to check once per day (--interval 86400 seconds) and only watch the waiaas-daemon container. If a new image is published to ghcr.io/minhoyoo-iotrust/waiaas:latest, Watchtower pulls it, stops the old container, and starts a new one with the same configuration.

Because the wallet data lives in a named volume (waiaas-data:/data), it persists across container restarts. The new container picks up exactly where the old one left off.

A few practical notes for self-hosters:

Schedule updates during low-traffic windows. If your AI agents are actively trading, a restart in the middle of a transaction pipeline isn't ideal. Watchtower supports cron-style scheduling with --schedule if you want updates to happen at 3am instead of randomly throughout the day.

Consider update notifications. Watchtower can post to Slack, email, or other channels when it performs an update. For infrastructure you care about, knowing when an update happened is useful for debugging if something changes behavior.

Test before enabling auto-update in production. Run a staging instance that auto-updates, verify it works, then roll to production. Named volumes make this easy because staging and production can share nothing except the image.

The CLI Path: More Control, Less Magic

If automatic updates feel like too much magic for your taste, the CLI gives you explicit control:

npm install -g @waiaas/cli
waiaas init
waiaas start
waiaas update

The waiaas update command is one of the 20 CLI commands built into the WAIaaS CLI. It's the manual equivalent of what Watchtower does automatically — pull the latest image, restart the daemon. You run it when you want to, not on a schedule.

This is the right approach if you're running WAIaaS on hardware where unattended restarts could cause problems, or if you want to read changelogs before updating.

Setting Up Your First Wallet and Agent Session

Once the daemon is running, the quickstart flow is three more commands:

waiaas init                    # Create data directory + config.toml
waiaas start                   # Start daemon (sets master password on first run)
waiaas quickset --mode mainnet # Create wallets + MCP sessions in one step

quickset creates wallets and sessions, then prints the MCP configuration JSON you need to paste into Claude Desktop (or whatever AI agent framework you're using). If you want to skip copy-pasting:

waiaas mcp setup --all   # Auto-register all wallets with Claude Desktop

After that, your AI agent has a session token, and you control what it can do via policies. For example, setting a spending limit:

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
    }
  }'

This creates a four-tier policy: under $100 executes immediately, $100-500 sends you a notification, $500-2000 queues for 15 minutes (cancellable), and over $2000 requires your explicit approval. The agent can't override these — they're enforced server-side in the transaction pipeline before any signing happens.

The Self-Hosting Philosophy in Practice

Running your own wallet infrastructure is the crypto equivalent of running your own email server — the comparison gets made a lot because it's accurate. Both give you control over sensitive data. Both require you to think about uptime, updates, and backups. Both are more practical than they used to be.

The backup story matters here too. The CLI includes backup create, backup list, backup inspect, and restore commands. Your wallet data, session configuration, and policies are all in the named volume. Back it up. The waiaas backup create command exists precisely so you don't have to figure out the right tar incantation to grab the right files.

For the privacy-conscious: all of this runs on your hardware, on your network. The transaction data that flows through your WAIaaS instance — which agents are doing what, when, to which addresses — stays local. If you're building agents that handle sensitive financial operations, that's not a minor consideration.

The three-layer security model (session auth → time delay and approval → monitoring and kill switch) works because all three layers run locally. WalletConnect integration lets you approve transactions from your phone. The kill switch is yours to pull, not a hosted service's.

Quick Start Summary

Deploy: docker compose up -d from the cloned repo, or docker run with the image from GHCR
Auto-provision: Set WAIAAS_AUTO_PROVISION=true, retrieve the master password from /data/recovery.key
Add Watchtower: Point it at waiaas-daemon with a daily check interval
Create wallets and sessions: waiaas quickset --mode mainnet
Set policies: Define spending limits and whitelists via the REST API or Admin UI before handing session tokens to agents

The OpenAPI spec and interactive docs are available at http://127.0.0.1:3100/doc and http://127.0.0.1:3100/reference once you're running.

What's Next

The infrastructure side of self-hosting WAIaaS is genuinely approachable — the harder and more interesting questions are around policy design (which of the 21 policy types you need, and how tight to set the tiers) and agent integration (MCP vs. SDK vs. direct REST). Both are worth spending time on before your agents start moving real funds. The GitHub repository has the full source and documentation, and waiaas.ai covers the broader architecture. Start with WAIAAS_AUTO_PROVISION=true on a testnet wallet, run a few transactions through the pipeline, watch the logs — you'll get a feel for how the pieces fit together before anything is at stake.

21 Policy Types for Self-Hosted Crypto Wallets: Complete Risk Management

Wallet Guy — Sat, 04 Jul 2026 14:44:38 +0000

21 Policy Types for Self-Hosted Crypto Wallets: Complete Risk Management

Would you trust a third party with your AI agent's private keys? If you're building autonomous agents that move real money, the question of who controls the wallet matters as much as the policy rules protecting it. WAIaaS is an open-source, self-hosted Wallet-as-a-Service that lets you run your own wallet infrastructure — and back it with a policy engine covering 21 distinct risk controls, all enforced locally on your own server.

Why Risk Management for AI Agents Is Different

Traditional wallet security assumes a human is making every decision. A human checks the recipient address. A human notices when a transaction looks wrong. A human stops before clicking send on a $10,000 transfer at 3 AM.

AI agents don't do any of that.

When you give an autonomous agent a session token, you're handing it the ability to sign and broadcast transactions without any of those human checkpoints. That's the whole point — but it's also the risk. An agent following bad instructions, a compromised session token, or a misconfigured DeFi strategy can drain funds faster than any human operator can react. The policy engine isn't a nice-to-have. It's the layer between "agent does something clever" and "agent does something catastrophic."

The self-hosted angle matters here too. When you run WAIaaS on your own server, your private keys never leave your infrastructure. The policy engine enforcing your rules runs on your machine. No hosted service is making decisions about your transactions, rate-limiting your agent's API calls, or holding your keys in a multi-tenant environment. Your server, your rules, full stop.

The Default-Deny Foundation

Before diving into the 21 policy types, it's worth understanding the foundational principle: default-deny.

If you don't configure an ALLOWED_TOKENS policy, token transfers are blocked. If you don't configure a CONTRACT_WHITELIST, contract calls are blocked. The absence of a permission is itself a denial. This is the opposite of most wallet setups where everything is allowed until you explicitly restrict it.

This matters for agents specifically because agents will try things you didn't anticipate. A default-allow system means your agent can do anything until you catch and block it. A default-deny system means your agent can only do what you've explicitly permitted.

The 4 Security Tiers

Every transaction WAIaaS processes gets assigned to one of four security tiers before execution:

INSTANT — Execute immediately, no notification
NOTIFY — Execute immediately, but send you a notification
DELAY — Queue the transaction for a configurable number of seconds, then execute (you can cancel during this window)
APPROVAL — Block until you explicitly approve via WalletConnect, Telegram, or push notification

The SPENDING_LIMIT policy is what maps transaction amounts to these tiers. Here's a practical example — a policy that lets your agent handle small routine payments instantly, notifies you on medium transactions, delays large ones (giving you a cancellation window), and requires your explicit sign-off on anything significant:

curl -X POST http://localhost:3100/v1/policies \
  -H 'Content-Type: application/json' \
  -H 'X-Master-Password: <password>' \
  -d '{
    "walletId": "<wallet-uuid>",
    "type": "SPENDING_LIMIT",
    "rules": {
      "instant_max_usd": 10,
      "notify_max_usd": 100,
      "delay_max_usd": 1000,
      "delay_seconds": 300,
      "daily_limit_usd": 500,
      "monthly_limit_usd": 5000
    }
  }'

With this config: anything under $10 executes immediately, $10–$100 executes with a notification, $100–$1,000 gets queued for 5 minutes before executing, and anything over $1,000 waits for your manual approval. The daily cap of $500 and monthly cap of $5,000 add an aggregate safety net on top.

All 21 Policy Types

Here's what the full policy library covers:

Transfer Controls

SPENDING_LIMIT — The core 4-tier security policy described above. Maps USD amounts to INSTANT/NOTIFY/DELAY/APPROVAL tiers with daily and monthly aggregate limits.

WHITELIST — Restricts which recipient addresses your agent can send funds to. If an address isn't on the list, the transaction is blocked:

{"allowed_addresses": ["<address1>", "<address2>"]}

ALLOWED_TOKENS — Default-deny whitelist of which tokens your agent can transfer. Your agent can only move tokens explicitly listed here:

{"tokens": [{"address": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v", "symbol": "USDC", "chain": "solana"}]}

RATE_LIMIT — Caps the number of transactions your agent can submit per period:

{"maxTransactions": 10, "period": "hourly"}

TIME_RESTRICTION — Limits when transactions can execute. Useful if your agent should only operate during business hours:

{"allowedHours": {"start": 9, "end": 17}, "timezone": "UTC"}

ALLOWED_NETWORKS — Restricts which chains your agent can transact on:

{"networks": [{"network": "ethereum-mainnet"}, {"network": "solana-mainnet"}]}

Contract Interaction Controls

CONTRACT_WHITELIST — Default-deny whitelist of smart contracts your agent can call. If the contract address isn't listed, the call is blocked:

{"contracts": [{"address": "JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4", "name": "Jupiter", "chain": "solana"}]}

METHOD_WHITELIST — Restricts which function selectors (4-byte method IDs) the agent can call on contracts. Useful when you want to allow a contract but only specific functions on it.

APPROVED_SPENDERS — Default-deny whitelist controlling which addresses your agent can grant token approval to:

{"spenders": [{"address": "0xDEF1...", "name": "Uniswap Router", "maxAmount": "1000000000"}]}

APPROVE_AMOUNT_LIMIT — Sets a cap on approval amounts and can block unlimited approvals (the approve(MAX_UINT256) pattern that's common but risky).

APPROVE_TIER_OVERRIDE — Forces approval transactions into a specific security tier regardless of amount. You might want all approve() calls to require human sign-off even if the amount would normally be INSTANT.

DeFi-Specific Controls

LENDING_LTV_LIMIT — Caps the loan-to-value ratio your agent can take on in lending protocols like Aave. Prevents your agent from over-leveraging borrowed positions.

LENDING_ASSET_WHITELIST — Restricts which assets your agent can supply or borrow in lending protocols.

PERP_MAX_LEVERAGE — Sets the maximum leverage multiplier for perpetual futures positions on protocols like Hyperliquid.

PERP_MAX_POSITION_USD — Caps the total USD size of any single perpetual position.

PERP_ALLOWED_MARKETS — Restricts which perpetual futures markets your agent can trade.

VENUE_WHITELIST — Controls which trading venues or DEXes your agent can route through.

ACTION_CATEGORY_LIMIT — Applies aggregate limits across DeFi action categories (lending, staking, trading, etc.).

Emerging Protocol Controls

X402_ALLOWED_DOMAINS — WAIaaS supports the x402 HTTP payment protocol, where AI agents automatically pay for API calls. This policy whitelists which domains your agent can make automatic payments to:

{"domains": ["api.example.com", "*.openai.com"]}

REPUTATION_THRESHOLD — Sets a minimum ERC-8004 onchain reputation score required for counterparties in agent-to-agent interactions.

ERC8128_ALLOWED_DOMAINS — Restricts which domains your agent can sign HTTP requests for under the ERC-8128 protocol.

Approving a Transaction as the Owner

When a transaction hits the APPROVAL tier, your agent's execution is paused. The transaction waits until you act on it. Once you've reviewed and decided to proceed, approving looks like this:

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 layer uses your own keypair — the same address you used when setting up owner authentication. Nothing about this approval touches a third-party service. The signature verification happens on your server.

Testing Before You Commit

Before you deploy a policy setup to a live agent, you can simulate transactions to see exactly how they'd be handled. The dryRun flag runs the full policy evaluation pipeline without broadcasting 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
  }'

This is how you validate that your SPENDING_LIMIT thresholds work the way you intended, that your WHITELIST covers the right addresses, and that your ALLOWED_TOKENS list includes everything your agent legitimately needs — before any real funds are at risk.

What a Policy Denial Looks Like

When a transaction is blocked by a policy, the API returns a structured error rather than silently failing. Your agent (or your monitoring) gets something like:

{
  "error": {
    "code": "POLICY_DENIED",
    "message": "Transaction denied by SPENDING_LIMIT policy",
    "domain": "POLICY",
    "retryable": false
  }
}

The retryable: false flag tells the agent not to keep hammering the endpoint. The error code tells you exactly which policy triggered the block, so you can audit your configuration.

Getting It Running

The fastest path from zero to a self-hosted WAIaaS instance with policies configured:

Step 1: Start the daemon

git clone https://github.com/minhoyoo-iotrust/WAIaaS.git
cd WAIaaS
docker compose up -d

The Docker image is ghcr.io/minhoyoo-iotrust/waiaas:latest, and it binds to 127.0.0.1:3100 by default — local only, not exposed to the network.

Step 2: Initialize and create a wallet

npm install -g @waiaas/cli
waiaas init
waiaas start

Or use waiaas quickset --mode mainnet to create wallets and sessions in one step.

Step 3: Create your spending policy

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
    }
  }'

Step 4: Add token and contract whitelists

Layer ALLOWED_TOKENS and CONTRACT_WHITELIST on top of your spending limit. Remember: without these, token transfers and contract calls are blocked by default.

Step 5: Create a session for your agent

curl -X POST http://127.0.0.1:3100/v1/sessions \
  -H "Content-Type: application/json" \
  -H "X-Master-Password: my-secret-password" \
  -d '{"walletId": "<wallet-uuid>"}'

Your agent gets a wai_sess_... token scoped to that wallet and governed by every policy you've configured.

The Philosophy Behind Self-Hosting This

Running WAIaaS is philosophically similar to running your own email server. It's more setup than using a hosted service. But you get things a hosted service structurally cannot give you: your private keys live on your hardware, your policy engine enforces rules without calling home, and your agent's transaction history stays on your infrastructure.

The 21 policy types aren't about making things complicated. They're about giving you the specific controls you actually need — whether that's a simple spending cap for a personal agent or a layered DeFi risk framework for something managing real capital. Start with SPENDING_LIMIT and ALLOWED_TOKENS. Add the DeFi controls when you're running lending or futures strategies. The rest are there when you need them.

What's Next

The interactive API reference at http://127.0.0.1:3100/reference documents every policy type with request/response schemas you can try directly in the browser. The admin UI at /admin includes a policy editor for managing policies without writing curl commands. If you're wiring this up to Claude or another MCP-compatible agent, the 45 MCP tools include get-policies so your agent can introspect its own policy configuration at runtime.

Grab the source, open an issue, or star the project on GitHub:

GitHub: https://github.com/minhoyoo-iotrust/WAIaaS
Official site: https://waiaas.ai

WalletConnect in Claude Desktop: Mobile Approval for AI Agent Transactions

Wallet Guy — Sat, 04 Jul 2026 09:03:36 +0000

WalletConnect in Claude Desktop: Mobile Approval for AI Agent Transactions

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.

Why Human Approval Still Matters for Autonomous Agents

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.

WAIaaS as an MCP Server

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.

The Three-Layer Security Model

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.

Setting Up the Spending Limit Policy

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:

Transactions under $100 → INSTANT (execute immediately, no notification)
$100–$500 → NOTIFY (execute, but send you a notification)
$500–$2,000 → DELAY (queue for 900 seconds, cancellable window)
Over $2,000 → APPROVAL (hard stop, requires WalletConnect approval)

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.

What the Agent Sees When a Transaction Needs Approval

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.

Dry-Run Before the Agent Commits

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.

Multi-Wallet Setup: Separate Policies Per Agent

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.

Quick Start: From Zero to Approval Flow

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.

Beyond Approval: What Claude Can Do With 45 MCP Tools

The WalletConnect approval flow is one piece of a larger capability surface. With WAIaaS's 45 MCP tools connected, Claude can:

Check wallet balance and token holdings
Send native tokens or ERC-20/SPL tokens
Execute DeFi actions across 15 integrated protocols (swap on Jupiter, lend on Aave, stake via Lido or Jito, trade perps on Hyperliquid)
Query DeFi positions and health factors
Browse and transfer NFTs (ERC-721, ERC-1155, Metaplex)
Monitor incoming transactions
Make x402 HTTP payments automatically when an API returns a 402 response
Sign messages and build UserOps for Account Abstraction flows

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.

What's Next

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.

GitHub: https://github.com/minhoyoo-iotrust/WAIaaS
Official site: https://waiaas.ai

The Wallet Infrastructure Layer: Why AI Agents Can't Use Traditional Finance

Wallet Guy — Fri, 03 Jul 2026 15:21:57 +0000

The Wallet Infrastructure Layer: Why AI Agents Can't Use Traditional Finance

AI agents will need to pay for compute, data, and API calls — and the infrastructure to let them do that autonomously doesn't exist in traditional finance. Banks require humans. Custodied accounts require human approval loops. Credit cards require a person on the other end. The moment you ask an AI agent to handle money independently, you run into a wall that the existing financial system was never designed to climb over.

The Real Problem

Think about what an AI agent actually needs to participate in an economy. It needs to hold funds. It needs to send payments without waiting for a human to click "approve." It needs to interact with DeFi protocols, pay API providers, and manage multiple chains — all while staying within the limits its operator set.

Traditional finance infrastructure is built around a core assumption: a human is always in the loop. Every transaction gets reviewed. Every account is tied to a legal identity. Every authorization requires a signature from a person who can be held accountable. That's sensible design for human users. For autonomous agents, it's a complete mismatch.

The stakes are real. As AI agents are increasingly asked to do economically meaningful work — managing portfolios, executing trades, paying for API access, distributing funds — the infrastructure layer they run on determines how much autonomy they actually have. Give them a custodied wallet managed by a human operator, and you've just created a bottleneck. Every transaction becomes a support ticket. Every edge case stops the agent cold.

What agents need is wallet infrastructure designed from the start for autonomous operation: programmable spending controls, multiple security tiers, and the ability to execute transactions without a human in the critical path for routine operations.

What "Autonomous Wallet Infrastructure" Actually Means

WAIaaS (Wallet-as-a-Service for AI agents) is an open-source, self-hosted system built specifically for this problem. It exists today. You can run it with Docker in under five minutes. The architecture is worth understanding because it reflects a genuinely different set of assumptions about who (or what) is holding the wallet.

The core separation is this: the owner of the funds is a human. The operator of the wallet is an AI agent. WAIaaS keeps these roles clearly distinct through three authentication layers.

masterAuth (Argon2id) is the system administrator — the human who creates wallets, configures policies, and manages sessions. ownerAuth (SIWS/SIWE) is the fund owner — a human who can approve high-value transactions or invoke a kill switch if something goes wrong. sessionAuth (JWT HS256) is what the AI agent uses — a scoped token that grants the agent the ability to execute transactions within pre-approved limits.

This three-layer design means an agent can run independently for routine operations, while humans retain hard controls over anything beyond defined thresholds.

The Policy Engine: Where Rules Replace Humans

The reason autonomous operation is safe in WAIaaS is the policy engine. It has 21 policy types and four security tiers. Before a transaction executes, it runs through a 7-stage pipeline that includes validation, authentication, policy evaluation, and confirmation.

The four tiers are:

INSTANT — Execute immediately, no notification
NOTIFY — Execute immediately, send the owner a notification
DELAY — Queue for a configurable number of seconds, then execute (cancellable)
APPROVAL — Require explicit human approval via WalletConnect, Telegram, or push notification

A SPENDING_LIMIT policy ties transaction size to these tiers automatically:

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 this config, an agent paying a $12 API invoice executes immediately. A $300 transfer sends a notification but still goes through. A $1,500 transaction queues for 15 minutes, giving the owner time to cancel if something looks wrong. Anything over $2,000 requires explicit human approval. The agent doesn't stop — it just escalates correctly based on stakes.

Beyond spending limits, you can lock down which tokens an agent can move (ALLOWED_TOKENS), which contracts it can call (CONTRACT_WHITELIST), which networks it can operate on (ALLOWED_NETWORKS), and even which trading venues it can use (VENUE_WHITELIST). The policy system enforces default-deny on these dimensions: if ALLOWED_TOKENS is configured and a token isn't on the list, the transaction is blocked, period.

For DeFi operations specifically, there are policies for maximum leverage on perpetual futures (PERP_MAX_LEVERAGE), loan-to-value limits for lending protocols (LENDING_LTV_LIMIT), and position size caps (PERP_MAX_POSITION_USD). An agent running a trading strategy genuinely can't exceed the risk parameters its operator set — not through a bug, not through a misunderstanding.

x402: Machines That Pay for What They Use

One of the most forward-looking pieces of WAIaaS is its support for the x402 HTTP payment protocol. The idea is straightforward: when an AI agent makes an HTTP request to a paid API, the server returns a 402 Payment Required response. The agent automatically handles the payment and retries the request. No human approval. No credit card. No invoice cycle.

WAIaaS exposes this through both the REST API and the TypeScript SDK:

import { WAIaaSClient } from '@waiaas/sdk';

const client = new WAIaaSClient({
  baseUrl: 'http://127.0.0.1:3100',
  sessionToken: process.env.WAIAAS_SESSION_TOKEN,
});

// This automatically handles 402 Payment Required responses
const response = await client.x402Fetch('https://api.example.com/data');

The agent calls x402Fetch instead of a plain HTTP fetch. If the server charges for access, the payment happens in the background. The X402_ALLOWED_DOMAINS policy type controls which endpoints the agent is permitted to pay automatically — so an agent can't be redirected into paying arbitrary addresses.

This is what autonomous economic participation looks like in practice. An agent that needs data pays for data. An agent that needs compute pays for compute. The whole cycle happens without a human approving each transaction, but within a policy envelope that keeps it safe.

Connecting an Agent: The MCP Path

The most common way to connect a capable AI agent like Claude to WAIaaS today is through the Model Context Protocol. WAIaaS provides 45 MCP tools covering wallet operations, transactions, DeFi, NFTs, and x402 payments.

Setup is a single CLI command:

waiaas mcp setup --all    # Auto-register all wallets with Claude Desktop

Or you can configure it manually in claude_desktop_config.json:

{
  "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"
      }
    }
  }
}

After that, Claude can check balances, send tokens, query DeFi positions across 15 integrated protocols, trade on Hyperliquid, swap on Jupiter, and pay x402-gated APIs — all through natural language. The agent doesn't need to know the underlying mechanics. It just calls tools.

If you're running multiple specialized agents — a trading agent, a data-fetching agent, a treasury management agent — you can give each one its own MCP server entry pointing at a different session token with different policy constraints. One agent can't touch the funds or the policy envelope of another.

The DeFi Layer: 15 Protocols, One Interface

For agents that need to do more than move money around, WAIaaS integrates 15 DeFi protocol providers: Aave v3, Across, D'CENT Swap, Drift, ERC-8004, Hyperliquid, Jito staking, Jupiter Swap, Kamino, Lido staking, LI.FI, Pendle, Polymarket, XRPL DEX, and 0x Swap.

An agent executing a Jupiter swap on Solana looks like this:

curl -X POST http://127.0.0.1:3100/v1/actions/jupiter-swap/swap \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer wai_sess_<token>" \
  -d '{
    "inputMint": "So11111111111111111111111111111111111111112",
    "outputMint": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
    "amount": "1000000000"
  }'

That's an agent swapping SOL for USDC. The transaction runs through the full 7-stage pipeline — validated, policy-checked, executed, confirmed. If the agent's policy doesn't permit this token pair, the request fails with a clear POLICY_DENIED error rather than silently doing something unintended:

{
  "error": {
    "code": "POLICY_DENIED",
    "message": "Transaction denied by SPENDING_LIMIT policy",
    "domain": "POLICY",
    "retryable": false
  }
}

Agents operating in financial markets also need to know what's about to happen before it happens. WAIaaS has a dry-run mode that simulates a transaction without executing it:

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
  }'

An agent can check whether a transaction would pass policy, estimate gas, and verify the outcome before committing. For autonomous systems operating at speed, that's a meaningful safety check.

Getting Running in Five Minutes

If you want to see this working today rather than just reading about it, the path is short:

Step 1: Start the daemon

git clone https://github.com/minhoyoo-iotrust/WAIaaS.git
cd WAIaaS
docker compose up -d

Step 2: Initialize with auto-provision

npm install -g @waiaas/cli
waiaas init --auto-provision
waiaas start

Step 3: Create wallets and sessions

waiaas quickset --mode mainnet

Step 4: Connect to Claude Desktop

waiaas mcp setup --all

Step 5: Set your policies

Use the Admin Web UI at /admin or the REST API to configure spending limits, token whitelists, and network restrictions before putting real funds in.

The Docker image is ghcr.io/minhoyoo-iotrust/waiaas:latest, bound to 127.0.0.1:3100 by default. For production deployments, there's a secrets overlay via docker-compose.secrets.yml that keeps credentials out of environment variables and in Docker Secrets instead.

The Infrastructure Question Is Already Here

It's tempting to frame autonomous agent finance as a future problem — something to solve when AI systems become capable enough to need it. But the infrastructure question is already here. AI agents are being deployed into workflows that involve real money today. The question isn't whether agents will need wallet infrastructure. It's whether that infrastructure will be purpose-built for autonomous operation, or whether builders will keep improvising around tools designed for humans.

The gap between "an agent that can talk about finance" and "an agent that can autonomously manage funds within defined constraints" is exactly the gap that purpose-built wallet infrastructure fills. The policy engine, the three-tier authentication model, x402 support, and the 15 DeFi protocol integrations exist because those requirements are real, not theoretical.

If you're building systems where AI agents need to handle money — even small amounts, even for simple API payments — it's worth understanding what the infrastructure layer actually needs to look like.

What's Next

The best starting point is the GitHub repository, where you'll find the full codebase, Docker setup instructions, and the CLI quickstart: https://github.com/minhoyoo-iotrust/WAIaaS. For a broader overview of what WAIaaS supports and the roadmap, the official site at https://waiaas.ai has the current documentation. The interactive API reference is available at /reference once you have a daemon running — it's the fastest way to understand what's actually available before writing any code.

Lock Down Your DeFi Bot: VENUE_WHITELIST Policy for 15-Protocol Trading

Wallet Guy — Fri, 03 Jul 2026 09:38:50 +0000

Lock Down Your DeFi Bot: VENUE_WHITELIST Policy for 15-Protocol Trading

DeFi trading bots live and die by two things: execution speed and risk controls. You've spent weeks tuning your arbitrage logic, backtesting entry conditions, and optimizing gas — but if your bot's wallet can call any contract on any protocol it wants, one compromised session token or a single logic bug is all it takes to drain everything. The VENUE_WHITELIST policy in WAIaaS gives your bot exactly the protocols it needs and nothing more.

Why Protocol Whitelisting Matters for Automated Trading

When you're running an automated strategy, the attack surface isn't just external threats — it's your own code. A malformed output from a price oracle, an unexpected edge case in your routing logic, a dependency that starts returning bad data: any of these can produce a transaction your bot didn't intend to send. Without hard constraints on which protocols your bot can interact with, a bug becomes a catastrophic loss event.

Beyond bugs, there's the session model to think about. WAIaaS issues session tokens (wai_sess_...) that your bot uses for all wallet operations. If that token leaks — through logs, environment variable exposure, or a compromised deployment — you want the blast radius to be exactly zero outside your approved venue list. Policy enforcement happens server-side in the daemon's transaction pipeline, before any transaction hits the chain. Your bot can't bypass it, and neither can an attacker holding a stolen session token.

What You're Working With

WAIaaS integrates 15 DeFi protocol providers: aave-v3, across, dcent-swap, drift, erc8004, hyperliquid, jito-staking, jupiter-swap, kamino, lido-staking, lifi, pendle, polymarket, xrpl-dex, and zerox-swap. That's a broad surface area for a trading bot to operate across — perpetual futures on Hyperliquid, spot swaps on Jupiter, cross-chain bridges via LI.FI and Across, lending positions on Aave and Kamino, prediction markets on Polymarket.

The wallet infrastructure is built around a 7-stage transaction pipeline: validate → auth → policy → wait → execute → confirm. The policy stage is where VENUE_WHITELIST lives. Every DeFi action your bot attempts gets checked against the policy before it moves to execution. This isn't an application-layer check you can accidentally skip — it's baked into the pipeline.

The policy engine has 21 policy types total, and VENUE_WHITELIST is specifically designed for this use case: restricting which trading venues and DeFi protocols a wallet session can interact with.

Setting Up VENUE_WHITELIST for Your Strategy

Let's say you're running a SOL/USDC arbitrage strategy that operates across Jupiter (Solana DEX) and hedges exposure using perpetual futures on Drift. You want your bot to have access to exactly those two protocols — nothing else.

First, create your wallet and a session for the bot:

# Create the trading wallet
curl -X POST http://127.0.0.1:3100/v1/wallets \
  -H "Content-Type: application/json" \
  -H "X-Master-Password: my-secret-password" \
  -d '{"name": "arb-bot-wallet", "chain": "solana", "environment": "mainnet"}'

# Create a session token for the bot process
curl -X POST http://127.0.0.1:3100/v1/sessions \
  -H "Content-Type: application/json" \
  -H "X-Master-Password: my-secret-password" \
  -d '{"walletId": "<wallet-uuid>"}'

Now lock down the venue list with a VENUE_WHITELIST policy:

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": "VENUE_WHITELIST",
    "rules": {
      "venues": ["jupiter-swap", "drift"]
    }
  }'

That's it. Your bot's session token can now execute Jupiter swaps and Drift perp operations. Any attempt to call aave-v3, lifi, hyperliquid, or any other provider will be rejected at the policy stage with a POLICY_DENIED error before it ever touches a signing key.

Layering Policies for a Full Risk Stack

VENUE_WHITELIST answers where your bot can trade. You probably also want to control how much it can trade and what tokens it can move. The policy engine is additive — stack multiple policies on the same wallet.

Add a spending limit to cap the damage from any single runaway transaction:

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": 500,
      "notify_max_usd": 2000,
      "delay_max_usd": 10000,
      "delay_seconds": 300,
      "daily_limit_usd": 50000
    }
  }'

The 4-tier security model assigns each transaction to INSTANT (execute immediately), NOTIFY (execute + alert you), DELAY (queue for 5 minutes, cancellable), or APPROVAL (requires your explicit sign-off via WalletConnect or Telegram). For an automated bot, you want most normal-sized trades hitting INSTANT, with larger position adjustments triggering a notification so you know they're happening, and anything anomalously large getting queued for you to review.

Add a token whitelist to prevent the bot from interacting with unknown tokens:

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": "ALLOWED_TOKENS",
    "rules": {
      "tokens": [
        {
          "address": "So11111111111111111111111111111111111111112",
          "symbol": "SOL",
          "chain": "solana"
        },
        {
          "address": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
          "symbol": "USDC",
          "chain": "solana"
        }
      ]
    }
  }'

ALLOWED_TOKENS is default-deny: if the token isn't on the list, the transaction is blocked. Your bot physically cannot be tricked into buying a honeypot token or moving an asset you didn't pre-approve.

For perpetuals trading on Drift, you can also cap leverage and restrict which markets the bot can open positions in:

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": "PERP_MAX_LEVERAGE",
    "rules": {
      "max_leverage": 5
    }
  }'

And if you want to go further, PERP_ALLOWED_MARKETS lets you restrict which perpetual markets the bot can trade. No accidental position opened on an illiquid altcoin market because of a bug in your market selection logic.

Executing Trades from Your Bot

Once policies are in place, your bot uses the session token for all operations. Here's what a Jupiter swap looks like from code:

import { WAIaaSClient } from '@waiaas/sdk';

const client = new WAIaaSClient({
  baseUrl: process.env['WAIAAS_BASE_URL'] ?? 'http://localhost:3100',
  sessionToken: process.env['WAIAAS_SESSION_TOKEN'],
});

// This will be blocked if jupiter-swap isn't in VENUE_WHITELIST
const swapResult = await client.executeAction('jupiter-swap', 'swap', {
  inputMint: 'So11111111111111111111111111111111111111112',
  outputMint: 'EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v',
  amount: '1000000000',
});

Or directly via the REST API:

curl -X POST http://127.0.0.1:3100/v1/actions/jupiter-swap/swap \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer wai_sess_<token>" \
  -d '{
    "inputMint": "So11111111111111111111111111111111111111112",
    "outputMint": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
    "amount": "1000000000"
  }'

If your bot tries to call a venue that's not on the whitelist, it gets back a clean error response:

{
  "error": {
    "code": "POLICY_DENIED",
    "message": "Transaction denied by VENUE_WHITELIST policy",
    "domain": "POLICY",
    "retryable": false
  }
}

Your bot can catch that error and log it as an anomaly — an attempted call to an unauthorized venue is worth knowing about, whether it came from a bug or something worse.

Gas Conditional Execution

One more tool worth knowing about for trading automation: gas conditional execution. WAIaaS supports executing transactions only when gas price meets a threshold you define. For EVM-based strategies, this means your bot doesn't waste gas on trades that become unprofitable because of network congestion — the transaction simply waits until gas comes down to your acceptable range, then executes automatically.

This is handled in the transaction pipeline before the execute stage, so the policy and signing infrastructure still applies. You're not bypassing any of the security controls to get gas optimization.

Dry-Run Before You Deploy

Before you go live with a new strategy, use the dry-run API to simulate transactions through the full pipeline — including policy checks — without actually executing them:

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
  }'

Use this to verify your policy stack is configured correctly before connecting your bot to production capital. A dry-run that comes back with POLICY_DENIED is much better than discovering the misconfiguration after a live trade goes wrong.

Quick Start: Trading Bot with VENUE_WHITELIST

Here's the minimal path from zero to a locked-down trading wallet:

Step 1: Install the CLI and start the daemon

npm install -g @waiaas/cli
waiaas init
waiaas start

Step 2: Create a wallet and session for your bot

curl -X POST http://127.0.0.1:3100/v1/wallets \
  -H "Content-Type: application/json" \
  -H "X-Master-Password: my-secret-password" \
  -d '{"name": "trading-bot", "chain": "solana", "environment": "mainnet"}'

curl -X POST http://127.0.0.1:3100/v1/sessions \
  -H "Content-Type: application/json" \
  -H "X-Master-Password: my-secret-password" \
  -d '{"walletId": "<wallet-uuid>"}'

Step 3: Apply your policy stack

Apply VENUE_WHITELIST, SPENDING_LIMIT, ALLOWED_TOKENS, and any perp-specific policies using the examples above. Order doesn't matter — all active policies are evaluated for every transaction.

Step 4: Verify with a dry-run

Use "dryRun": true to confirm your policy configuration is correct before funding the wallet.

Step 5: Deploy your bot with the session token

WAIAAS_SESSION_TOKEN=wai_sess_<your-token> WAIAAS_BASE_URL=http://127.0.0.1:3100 node your-bot.js

What's Next

WAIaaS is open-source and self-hosted — the code is at https://github.com/minhoyoo-iotrust/WAIaaS and the full documentation is at https://waiaas.ai. The full list of 21 policy types, all 15 DeFi protocol providers, and the OpenAPI reference at /reference are good places to start if you're designing a more complex strategy. For production deployments, the Docker setup with Docker Secrets support gives you a clean way to keep your master password out of environment variables entirely.

683 Test Files Later: How We Validate AI Agent Wallet Infrastructure

Wallet Guy — Thu, 02 Jul 2026 09:38:24 +0000

683 Test Files Later: How We Validate AI Agent Wallet Infrastructure

Your AI agent can browse the web, write code, and manage files — but can it actually touch money? That's the gap WAIaaS was built to close: a self-hosted, open-source Wallet-as-a-Service that gives your AI agent a real blockchain wallet, a policy engine, and a transaction pipeline it can use autonomously. And before any of that ships to production, it has to pass more than 683 test files.

Why Test Coverage Matters for Wallet Infrastructure

When your agent sends an email, a bug means a bad email. When your agent sends 0.1 ETH to the wrong address, a bug means lost funds. The stakes are categorically different.

This isn't about chasing a coverage number. It's about the fact that wallet infrastructure for AI agents sits at the intersection of two unforgiving domains: financial transactions (irreversible, high-stakes) and autonomous software (runs without human review). If you're building an agent on top of a wallet layer, you need to know that layer has been beaten up extensively before you trust it with real assets.

Here's a practical look at what WAIaaS actually tests, and more importantly, what that means for you as a developer building on top of it.

The Architecture Under Test

WAIaaS is a 15-package monorepo. Each package has its own test suite, and together they cover every layer of the system an AI agent will touch.

actions, adapters, admin, cli, core, daemon, desktop-spike,
e2e-tests, mcp, openclaw-plugin, push-relay, sdk, shared, skills, wallet-sdk

That's 683+ test files spread across packages that include:

The transaction pipeline — a 7-stage pipeline covering validate, auth, policy, wait, execute, and confirm
The policy engine — 21 policy types and 4 security tiers
45 MCP tools — every tool your Claude or LangChain agent will call
15 DeFi protocol integrations — including Jupiter, Aave v3, Hyperliquid, and more
39 REST API route modules — every endpoint the SDK talks to

When you call client.sendToken() from the TypeScript SDK, you're exercising code that has been tested at the unit level, the integration level, and the pipeline level. Let's walk through each of those layers.

Layer 1: The Transaction Pipeline

Every transaction an AI agent submits goes through a 7-stage pipeline:

stage1-validate — schema validation and chain-specific checks
stage2-auth — session token verification
stage3-policy — policy engine evaluation against all active policies
stage4-wait — handles DELAY and APPROVAL tier transactions
stage5-execute — signs and broadcasts to the network
stage6-confirm — monitors for on-chain confirmation

This pipeline is what stands between your agent's intent and an actual blockchain transaction. The test suite covers every stage, including the unhappy paths: what happens when a policy blocks a transaction, what happens when a DELAY times out, what happens when broadcast fails and needs to be retried.

From your agent's perspective, this pipeline is transparent. You submit a transaction and get back a status. But knowing it's there — and tested — is what lets you trust the output.

Here's a basic send from the TypeScript SDK:

import { WAIaaSClient, WAIaaSError } from '@waiaas/sdk';

const client = new WAIaaSClient({
  baseUrl: process.env['WAIAAS_BASE_URL'] ?? 'http://localhost:3100',
  sessionToken: process.env['WAIAAS_SESSION_TOKEN'],
});

// Step 1: Check wallet balance
const balance = await client.getBalance();
console.log(`Balance: ${balance.balance} ${balance.symbol} (${balance.chain}/${balance.network})`);

// Step 2: Send tokens
const sendResult = await client.sendToken({
  type: 'TRANSFER',
  to: 'recipient-address',
  amount: '0.001',
});
console.log(`Transaction submitted: ${sendResult.id} (status: ${sendResult.status})`);

// Step 3: Poll for confirmation
const POLL_TIMEOUT_MS = 60_000;
const startTime = Date.now();
while (Date.now() - startTime < POLL_TIMEOUT_MS) {
  const tx = await client.getTransaction(sendResult.id);
  if (tx.status === 'COMPLETED') {
    console.log(`Transaction confirmed! Hash: ${tx.txHash}`);
    break;
  }
  if (tx.status === 'FAILED') {
    console.error(`Transaction failed: ${tx.error}`);
    break;
  }
  await new Promise(resolve => setTimeout(resolve, 1000));
}

The pattern is simple because the pipeline complexity is encapsulated. Your agent doesn't need to know about stage3-policy or stage4-wait. It just polls for COMPLETED.

Layer 2: The Policy Engine

The policy engine is probably the most critical thing to get right, and it's the part of WAIaaS with the most test surface area.

21 policy types. 4 security tiers. Default-deny enforcement. A single misconfigured policy could either block legitimate agent transactions or, worse, allow a transaction that should have required human approval.

The 4 tiers tell you exactly what will happen to a transaction:

INSTANT   — Execute immediately, no notification
NOTIFY    — Execute immediately, send notification
DELAY     — Queue for delay_seconds, then execute (cancellable)
APPROVAL  — Require human approval via WalletConnect/Telegram/Push

Testing this correctly means verifying every boundary condition. An instant_max_usd of $10 means a $10.00 transaction is INSTANT and a $10.01 transaction is NOTIFY. Those boundary tests exist in the suite.

Here's what a spending limit policy looks like when you create it via the REST API:

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
    }
  }'

And if a transaction is blocked, the error response is structured and actionable:

{
  "error": {
    "code": "POLICY_DENIED",
    "message": "Transaction denied by SPENDING_LIMIT policy",
    "domain": "POLICY",
    "retryable": false
  }
}

Your agent can catch this, log it, and surface it to a human rather than silently failing. The test suite covers both the policy evaluation logic and the error response format, so you can build reliable error handling on top of a stable contract.

Layer 3: The MCP Tools

If you're building on Claude or another MCP-compatible framework, your agent interacts with WAIaaS through 45 MCP tools. Every one of those tools is a tested surface.

The tool list covers the full range of what an autonomous agent might need:

Wallet operations: get-balance, get-address, get-assets, get-wallet-info
Transactions: send-token, send-batch, sign-transaction, simulate-transaction
DeFi: action-provider, get-defi-positions, get-health-factor
NFTs: get-nft-metadata, list-nfts, transfer-nft
Protocol-specific: hyperliquid, polymarket, x402-fetch
Security/auth: erc8004-get-reputation, wc-connect, list-sessions

Setting up MCP with Claude Desktop takes one command:

waiaas mcp setup --all    # Auto-register all wallets with Claude Desktop

Or you can configure it manually in claude_desktop_config.json:

{
  "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"
      }
    }
  }
}

After that, Claude can call get_balance, send_token, or execute_action the same way it calls any other tool — but now the infrastructure behind those calls has been validated by 683+ test files.

Layer 4: The DeFi Protocol Integrations

15 DeFi protocol providers are integrated in WAIaaS:

aave-v3, across, dcent-swap, drift, erc8004, hyperliquid,
jito-staking, jupiter-swap, kamino, lido-staking, lifi,
pendle, polymarket, xrpl-dex, zerox-swap

Each provider has its own action logic. Testing these means mocking RPC calls, simulating swap quotes, and verifying that the action payload built for Jupiter looks correct before it ever hits mainnet.

There's also a dry-run capability built into the transaction pipeline. Before your agent executes a DeFi action for real, it can simulate it:

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
  }'

This is a first-class feature of the API, not a workaround. You can build agents that dry-run before executing and only proceed if the simulation succeeds.

Quick Start: Running It Yourself

You don't need to take our word for the test coverage. You can clone the repo and run the suite locally. But if you want to get an agent connected first:

Step 1 — Install the CLI and start the daemon

npm install -g @waiaas/cli
waiaas init
waiaas start

Step 2 — Create wallets and sessions in one command

waiaas quickset --mode mainnet

Step 3 — Connect to Claude Desktop

waiaas mcp setup --all

Step 4 — Or use the TypeScript SDK directly

npm install @waiaas/sdk

import { WAIaaSClient } from '@waiaas/sdk';

const client = new WAIaaSClient({
  baseUrl: 'http://127.0.0.1:3100',
  sessionToken: process.env.WAIAAS_SESSION_TOKEN,
});

const balance = await client.getBalance();
console.log(`${balance.balance} ${balance.symbol}`);

Step 5 — Set a policy before going to mainnet

Use the policy API to configure a spending limit before you let your agent run autonomously. Even a simple SPENDING_LIMIT with a $10 instant max gives you a meaningful safety net.

What 683 Test Files Actually Tells You

A number like 683 test files is only meaningful in context. Here's the context:

The transaction pipeline has stages that are individually tested — including the gas condition stage that holds transactions until gas price meets a threshold
The policy engine covers all 21 policy types and their boundary conditions
The 3 auth methods (masterAuth with Argon2id, ownerAuth with SIWS/SIWE, sessionAuth with JWT HS256) are each tested independently
The 45 MCP tools are tested against the same transaction and policy infrastructure
The OpenAPI 3.0 spec is auto-generated and available at /doc, with an interactive reference UI at /reference — so the API you're coding against is validated against the implementation

None of this means bugs don't exist. It means the team has invested in the kind of validation infrastructure that gives you a reasonable basis for trust when you're building financial tooling for autonomous agents.

What's Next

If you want to go deeper on how the policy engine works in practice — especially the default-deny behavior and how to configure policies for different agent risk profiles — that's worth its own read. The security model has three distinct layers (session auth, time delay and approval, monitoring and kill switch) that work together in ways that aren't obvious from the policy API alone.

The best next step is to get a local instance running and connect it to your agent. The CLI makes that fast, and the MCP integration means you can be talking to a real wallet from Claude Desktop in under ten minutes.

GitHub: https://github.com/minhoyoo-iotrust/WAIaaS
Official site: https://waiaas.ai

Mobile-First Transaction Approvals: Push Relay + Telegram for Trading Bot Security

Wallet Guy — Wed, 01 Jul 2026 10:18:39 +0000

Mobile-First Transaction Approvals: Push Relay + Telegram for Trading Bot Security

Trading bots move fast, but a rogue session or compromised API key can drain your wallet faster. If you're running automated trading strategies — arb bots, MEV searchers, algorithmic DeFi — you already know that speed and security are usually at war with each other. Lock things down too hard and you kill your latency. Leave too much open and one bad transaction wipes the account. WAIaaS's push relay and Telegram signing channels give you a third path: let the bot run freely within tight policy guardrails, and get a mobile ping the moment something needs a human eye.

The Real Risk in Automated Trading

Most trading bot setups have an uncomfortable secret: the bot has effectively unlimited signing power. The session token sitting in your .env file can send anything, to anyone, for any amount. You're trusting that your code has no bugs, your key management is perfect, and nobody has access to that token but you.

That's a lot of trust.

The problem compounds at scale. When you're running Jupiter swaps, Drift perps, and LI.FI bridges from the same wallet, a single misconfigured trade or an exploit in one of those protocol integrations becomes a total-loss event. The industry answer has been "just don't keep much in the hot wallet" — but that's not a solution when your strategy requires capital on hand to execute.

WAIaaS approaches this differently. Rather than treating the wallet as a raw signer, it wraps every transaction in a 7-stage pipeline — validate, auth, policy check, wait, execute, confirm — and gives you fine-grained control over which transactions go through automatically, which trigger a notification, which get delayed, and which require you to pull out your phone and approve.

Four Security Tiers, Not Two

The typical "hot wallet vs. cold wallet" framing is too blunt for trading. WAIaaS uses 4 security tiers that map onto how traders actually think about risk:

INSTANT — Execute immediately, no notification. Your bot's routine rebalancing trades under a dollar threshold don't need to wake you up.

NOTIFY — Execute immediately, but send you a push or Telegram message so you know it happened. Good for medium-size trades you want visibility on without creating friction.

DELAY — Queue the transaction for a configurable number of seconds, then execute automatically unless you cancel. This is your circuit breaker for larger trades.

APPROVAL — Full stop. The transaction does not execute until you approve it via WalletConnect, Telegram, or push notification. Required for anything above your risk threshold.

These tiers aren't manually assigned per transaction. They're derived automatically from your policy configuration. Set up a SPENDING_LIMIT policy once, and every transaction your bot submits gets routed to the right tier based on its USD value:

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 this config: trades under $100 execute instantly (your bot doesn't feel a thing), trades between $100-$500 execute but you get a notification, trades between $500-$2,000 are queued for 15 minutes (you can cancel if something looks wrong), and anything over $2,000 requires explicit approval. The daily cap at $5,000 means a runaway bot can't blow past your intended exposure even if it tries.

Three Signing Channels for Mobile Approval

When a transaction hits the APPROVAL tier, WAIaaS needs to reach you. There are 3 signing channels available: a push relay channel, a Telegram signing channel, and a wallet notification channel.

The push relay is WAIaaS's own notification infrastructure — a separate Docker image (push-relay) that handles delivery to mobile devices. The Telegram channel works through bot integration, which many traders already have set up for price alerts. The wallet notification channel ties into WalletConnect, letting you approve transactions from your hardware wallet's mobile app.

From a trading bot perspective, this is significant. Your bot is running autonomously on a server, but you retain a physical approval step for high-value transactions without any manual process changes on the bot side. The bot submits the transaction normally; WAIaaS intercepts it at the policy stage, sends it to whichever signing channel you've configured, and waits for your response.

Locking Down the Attack Surface with Policies

For a trading bot, you want more than just spending limits. WAIaaS has 21 policy types — here are the ones most relevant to automated trading:

CONTRACT_WHITELIST — Your bot should only be touching the protocols you've specifically authorized. If someone compromises your session token and tries to interact with an unknown contract, this blocks it:

{"contracts": [{"address": "JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4", "name": "Jupiter", "chain": "solana"}]}

ALLOWED_TOKENS — Default-deny on tokens. Your arb bot that's supposed to trade SOL/USDC shouldn't be able to send random SPL tokens even if a bug tries to:

{"tokens": [{"address": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v", "symbol": "USDC", "chain": "solana"}]}

APPROVED_SPENDERS — If your strategy involves token approvals (EVM DeFi), this whitelist ensures approvals only go to known protocol contracts. Combined with APPROVE_AMOUNT_LIMIT, you can block unlimited approvals entirely.

PERP_MAX_LEVERAGE and PERP_MAX_POSITION_USD — If you're running Drift perpetual strategies, these policies enforce position size limits directly at the wallet layer, independent of whatever your trading logic says. A bug that calculates 100x leverage instead of 10x gets blocked before it touches the chain.

RATE_LIMIT — Maximum transactions per period. If your bot suddenly starts firing 50 transactions in a minute when it normally does 5, that's a signal something went wrong:

{"maxTransactions": 10, "period": "hourly"}

ALLOWED_NETWORKS — Restrict your bot to only the chains it's supposed to operate on. An Ethereum bot shouldn't be able to accidentally send to Solana and vice versa.

Gas Conditional Execution

One underrated feature for trading bots: gas conditional execution. Your bot only sends the transaction when gas price meets a threshold you define. This is handled at the pipeline stage level — the transaction waits in the queue until gas conditions are satisfied rather than your bot needing to poll and resubmit.

For arb strategies where your profit margin is thin, this is not a nice-to-have. A trade that pencils out at 20 gwei becomes a loss at 80 gwei. Rather than building gas oracle logic into your bot, you lean on WAIaaS's pipeline to handle the condition check.

Multi-Protocol Access in One API Call

The protocol coverage matters for traders running cross-venue strategies. WAIaaS integrates 15 DeFi protocol providers: aave-v3, across, dcent-swap, drift, erc8004, hyperliquid, jito-staking, jupiter-swap, kamino, lido-staking, lifi, pendle, polymarket, xrpl-dex, and zerox-swap.

That's Jupiter for Solana spot, Drift for Solana perps, Hyperliquid for perp futures and spot, LI.FI and Across for cross-chain bridging, Aave for EVM lending, Kamino for Solana lending, and Polymarket for prediction markets — all through the same session token, same API server, same policy engine.

A Jupiter swap from your bot looks like this:

curl -X POST http://127.0.0.1:3100/v1/actions/jupiter-swap/swap \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer wai_sess_<token>" \
  -d '{
    "inputMint": "So11111111111111111111111111111111111111112",
    "outputMint": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
    "amount": "1000000000"
  }'

The same session token that executes that swap can open a Drift position, bridge proceeds via LI.FI, or stake idle SOL on Jito. The policy engine applies uniformly across all of them — you don't need to maintain separate risk logic for each protocol integration.

Dry Run Before You Send

For strategies that are hard to backtest perfectly, the dry-run API is useful. You can simulate a transaction before committing:

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 same request with "dryRun": true runs through the full pipeline — policy checks, validation, everything — without touching the chain. You get back exactly what would happen if you ran it live. For a new strategy going into production, this lets you validate that your transaction construction is correct and that your policies won't block it unexpectedly, before any real capital moves.

Quick Start: Bot with Mobile Approvals

Here's the minimal path to a trading bot setup with push approvals for large trades:

Step 1 — Get WAIaaS running:

git clone https://github.com/minhoyoo-iotrust/WAIaaS.git
cd WAIaaS
docker compose up -d

The daemon starts on 127.0.0.1:3100. Default port binding is 127.0.0.1:3100:3100.

Step 2 — Create a trading wallet and session:

# Create the wallet
curl -X POST http://127.0.0.1:3100/v1/wallets \
  -H "Content-Type: application/json" \
  -H "X-Master-Password: my-secret-password" \
  -d '{"name": "trading-wallet", "chain": "solana", "environment": "mainnet"}'

# Create a session for your bot
curl -X POST http://127.0.0.1:3100/v1/sessions \
  -H "Content-Type: application/json" \
  -H "X-Master-Password: my-secret-password" \
  -d '{"walletId": "<wallet-uuid>"}'

Step 3 — Set your spending policy:

Use the SPENDING_LIMIT curl call from earlier. Tune instant_max_usd, delay_max_usd, and delay_seconds to match your strategy's typical trade sizes. Start conservative — you can always loosen it.

Step 4 — Add protocol and token restrictions:

Apply CONTRACT_WHITELIST and ALLOWED_TOKENS policies for the specific protocols and tokens your strategy touches. Default-deny means anything not on the list is blocked, which is exactly what you want for a live trading bot.

Step 5 — Configure your notification channel:

Run waiaas notification setup from the CLI to connect your preferred signing channel. Once configured, APPROVAL-tier transactions will route to your mobile device rather than blocking indefinitely.

Your bot uses the session token for all trading operations. Large trades get queued and ping your phone. Everything else executes at the latency your strategy needs.

Approving from Mobile

When a transaction hits the APPROVAL tier, you receive a mobile notification with the transaction details. The approval flow ties into WAIConnect — you review what the bot is trying to do (amount, recipient, protocol), and tap approve or reject. The transaction then either executes or is cancelled.

This keeps the human-in-the-loop step lightweight. You're not re-entering keys or going through a multi-step flow — you're reviewing a specific transaction that your bot flagged itself as large enough to warrant oversight, and making a binary decision. The ownerAuth layer handles the cryptographic verification:

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>"

Under the hood that's what your mobile approval is doing — generating a signature over the transaction ID that WAIaaS verifies before proceeding.

What's Next

The policy system has considerably more depth than what's covered here — DeFi-specific policies like LENDING_LTV_LIMIT, PERP_MAX_LEVERAGE, and VENUE_WHITELIST let you encode your risk parameters directly into the wallet layer rather than relying solely on your bot's logic. The full OpenAPI reference is available at http://127.0.0.1:3100/reference once your daemon is running, with interactive docs you can use to explore the 39 REST API route modules before writing a line of code.

For the full codebase and deployment configs, head to https://github.com/minhoyoo-iotrust/WAIaaS. Documentation and further resources are at https://waiaas.ai.

Self-Documenting AI Agents: OpenAPI 3.0 Spec Generation for MCP Tools

Wallet Guy — Wed, 24 Jun 2026 15:37:47 +0000

Self-Documenting AI Agents: OpenAPI 3.0 Spec Generation for MCP Tools

MCP developers building onchain AI agents often hit the same wall: your Claude agent can reason brilliantly, but it has no idea what tools are actually available, what parameters they expect, or how to authenticate. WAIaaS solves this by combining 45 MCP tools with a live OpenAPI 3.0 spec — so your agent always has accurate, machine-readable documentation for every wallet, transaction, and DeFi action it can take.

Why This Actually Matters

When you wire an AI agent to onchain infrastructure, documentation isn't a nice-to-have — it's load-bearing. If your agent guesses at parameter names, misunderstands authentication requirements, or doesn't know which networks are supported, it makes mistakes with real money. The combination of MCP tooling and a live OpenAPI spec means two things: Claude gets structured tool definitions through the MCP protocol, and any HTTP client (including other agents, scripts, or dashboards you build) can discover the full API surface automatically. Both layers stay in sync because they're generated from the same codebase.

One Line in Your Config

Let's start with the fastest path. Add this to your claude_desktop_config.json:

{
  "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"
      }
    }
  }
}

That's it. Restart Claude Desktop and your agent now has access to 45 MCP tools covering wallet management, token transfers, DeFi actions, NFT operations, and x402 HTTP payment — all authenticated, all policy-governed, all with typed parameters that Claude can introspect before calling them.

The MCP server package is @waiaas/mcp on npm, transport is stdio, and tools are served with full schema definitions so Claude understands input shapes without guessing.

What the 45 Tools Actually Cover

The tool list isn't just send-token and check-balance. Here's the full scope across categories:

Wallet & balance: get-wallet-info, get-address, get-balance, get-assets, get-nonce, connect-info

Transactions: send-token, send-batch, sign-transaction, sign-message, simulate-transaction, get-transaction, list-transactions, list-incoming-transactions, get-incoming-summary

DeFi: action-provider, get-defi-positions, get-health-factor, approve-token, list-offchain-actions

Account Abstraction: build-userop, sign-userop, encode-calldata, call-contract

NFT: get-nft-metadata, list-nfts, transfer-nft

Protocols: hyperliquid, polymarket, resolve-asset, get-tokens, get-provider-status

Sessions & auth: list-sessions, list-credentials, get-policies

ERC standards: erc8004-get-agent-info, erc8004-get-reputation, erc8004-get-validation-status, erc8128-sign-request, erc8128-verify-signature

WalletConnect: wc-connect, wc-disconnect, wc-status

Utility: get-rpc-proxy-url, x402-fetch, get-transaction (with full hash resolution)

When Claude sees simulate-transaction in the tool list, it knows it can dry-run before executing. When it sees get-health-factor, it understands DeFi lending positions are trackable. The schema-first design means Claude reasons about what's possible before committing to an action.

The OpenAPI Layer: For Everything Else

The MCP interface handles Claude. But you probably also have scripts, dashboards, or other agents that talk to WAIaaS over HTTP. That's where the OpenAPI 3.0 spec comes in.

WAIaaS auto-generates a live OpenAPI spec at /doc and serves an interactive Scalar API reference at /reference. Both stay current with the actual implementation — 39 REST API route modules feeding a single spec.

# Download the OpenAPI 3.0 spec
curl http://127.0.0.1:3100/doc -o openapi.json

# View the interactive reference in your browser
open http://127.0.0.1:3100/reference

The interactive UI at /reference is useful during development: you can see every endpoint, its authentication requirement, request schema, and response shape without reading source code. When you're building a policy configuration or debugging a DeFi action response, this is significantly faster than grepping through documentation.

The spec is also what you'd feed to another agent or code generator. If you're building a second AI agent that orchestrates WAIaaS over REST rather than MCP, point it at /doc and it has a complete, accurate description of the API surface.

Authentication Is Part of the Schema

One thing that trips up developers building multi-agent systems: WAIaaS uses three distinct authentication methods, and the OpenAPI spec documents which endpoints require which.

# masterAuth — create wallets, manage sessions, set policies
-H "X-Master-Password: my-secret-password"

# sessionAuth — AI agent operations (transactions, balance, DeFi)
-H "Authorization: Bearer wai_sess_eyJhbGciOiJIUzI1NiJ9..."

# ownerAuth — human approval for high-value transactions
-H "X-Owner-Signature: <ed25519-or-secp256k1-signature>"
-H "X-Owner-Message: <signed-message>"

In the MCP context, the session token you put in WAIAAS_SESSION_TOKEN handles all agent-facing operations. The session was created by a human operator using masterAuth — the agent never sees the master password. This separation is intentional: the agent has a scoped credential with policy limits, not root access to the wallet system.

Setting Up a Multi-Wallet MCP Configuration

For more sophisticated setups — say, a trading agent and a separate Solana wallet agent — you can run multiple named MCP servers pointing at the same WAIaaS daemon:

{
  "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 MCP server instance has its own session token scoped to a specific wallet. Claude sees both as separate tool namespaces and can reason about which wallet to use for which operation — all documented through the MCP tool schemas.

What Claude Can Actually Do After This

Here's what the interaction looks like in practice once MCP is connected:

User: "Check my wallet balance"
→ Claude calls get_balance tool → returns balance

User: "Swap 0.1 SOL for USDC on Jupiter"
→ Claude calls execute_action tool with jupiter-swap provider

User: "Show my DeFi positions across all protocols"
→ Claude calls get_defi_positions tool → returns lending/staking positions

The Jupiter swap call hits one of 15 integrated DeFi protocol providers — including Aave v3, Across, Drift, Hyperliquid, Jito staking, Jupiter swap, Kamino, Lido staking, LI.FI, Pendle, Polymarket, XRPL DEX, and 0x swap, among others. Claude doesn't need to know the protocol-specific parameters because the tool schema defines them.

Before any transaction executes, the 7-stage pipeline processes it: validate → auth → policy → wait → execute → confirm. If a policy blocks it, Claude gets back a structured error:

{
  "error": {
    "code": "POLICY_DENIED",
    "message": "Transaction denied by SPENDING_LIMIT policy",
    "domain": "POLICY",
    "retryable": false
  }
}

That error code is something Claude can reason about — it knows the transaction was blocked by a spending limit, not a network error, and can explain that to the user or suggest alternatives.

Quick Start: From Zero to MCP Tools in 5 Steps

Step 1: Install the CLI and initialize

npm install -g @waiaas/cli
waiaas init
waiaas start

Step 2: Create wallets and sessions in one command

waiaas quickset --mode mainnet

This creates wallets and MCP sessions. The output includes the MCP config JSON.

Step 3: Register with Claude Desktop automatically

waiaas mcp setup --all

Step 4: Verify the OpenAPI spec is live

curl http://127.0.0.1:3100/doc -o openapi.json
# Then open http://127.0.0.1:3100/reference in your browser

Step 5: Set a spending policy so the agent has safe limits

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
    }
  }'

Restart Claude Desktop and ask it to check your balance.

The Self-Documenting Part

The reason this system is "self-documenting" isn't marketing language — it's a practical property. The 45 MCP tools and the 39 REST API route modules both derive their schemas from the same source. When WAIaaS adds a new capability, the OpenAPI spec at /doc updates automatically, the interactive reference at /reference reflects it, and the MCP tool definitions that Claude receives are current.

For developers building on top of WAIaaS — whether you're writing an agent orchestration layer, a monitoring dashboard, or a second AI system that talks to WAIaaS over HTTP — you always have an accurate map of the territory. You don't maintain separate documentation, you don't discover parameter mismatches at runtime, and you don't need to read source code to understand what's available.

That's the core value proposition for MCP developers specifically: you get 45 typed, schema-defined tools that Claude can introspect, plus a live HTTP API that any other client can discover — all from a single self-hosted daemon you control.

What's Next

If you want to explore the policy engine in depth — setting spending limits, token whitelists, and DeFi-specific controls like maximum leverage — the 21 policy types give you fine-grained control over what your agent can and can't do autonomously. The Docker deployment path is also worth looking at if you're running this in a persistent server environment rather than locally.

The full codebase, including the MCP package and all 15 DeFi protocol providers, is at https://github.com/minhoyoo-iotrust/WAIaaS. More documentation and the official site are at https://waiaas.ai.

Building the Financial Rails for Machine-to-Machine Commerce

Wallet Guy — Wed, 24 Jun 2026 09:53:56 +0000

Building the Financial Rails for Machine-to-Machine Commerce

AI agents will need to pay for compute, data, and API calls — and right now, almost nothing in the infrastructure stack is built to handle that. We talk endlessly about autonomous agents that book travel, execute trades, and negotiate contracts, but when the conversation turns to how they pay, the answer is usually a hand-wave. Humans still hold the keys, approve every transaction, and act as financial intermediaries for systems that are supposed to operate independently. That's not autonomy. That's a chatbot with extra steps.

The Missing Layer

Think about what a truly autonomous AI agent needs to participate in economic activity. It needs to hold funds. It needs to authorize payments without waking a human up at 3 AM. It needs spending guardrails so it can't accidentally drain a treasury on a bad swap. It needs to handle multiple chains because the internet doesn't run on one blockchain. And it needs to do all of this without a centralized custodian that becomes a single point of failure — or control.

None of the standard wallet tooling was designed for this. Browser extension wallets need a human to click "confirm." Custodial APIs introduce a trust assumption that defeats the purpose of autonomous operation. Raw key management libraries give you signing primitives but nothing resembling a policy engine or an approval workflow.

The financial rails for machine-to-machine commerce aren't missing because the problem is unsolved. They're missing because the industry has been building for human users. Agents are a different actor class entirely, and they need infrastructure built specifically for them.

What Agent-Native Wallet Infrastructure Looks Like

WAIaaS — Wallet-as-a-Service for AI agents — is an open-source, self-hosted daemon that exists specifically to close this gap. It's running today. You can deploy it in under five minutes with Docker. Here's what makes it different from gluing together a keystore and a REST API yourself.

The Architecture: Three Auth Layers for Three Actor Classes

The fundamental insight in WAIaaS's design is that who is touching the wallet matters enormously. There are three distinct actors with three distinct trust levels:

The system administrator sets up wallets, creates sessions, and defines policies. They authenticate with a master password hashed using Argon2id. They should almost never be involved in day-to-day operations.

The AI agent runs transactions, checks balances, executes DeFi actions. It authenticates with a session JWT (wai_sess_...). Sessions have configurable TTL, max renewals, and absolute lifetime. The agent gets exactly the access you scope to it — no more.

The fund owner — the human who actually owns the money — can approve transactions, connect via WalletConnect, and activate a kill switch if something goes wrong. They authenticate with a cryptographic signature (SIWS or SIWE), not a password.

This isn't three passwords for the same interface. It's three genuinely different security principals with different capabilities and different threat models.

The Policy Engine: Rules That Run Without Human Intervention

The reason you can let an agent operate autonomously is that you've already told the system what it's allowed to do. WAIaaS ships a policy engine with 21 policy types and 4 security tiers: INSTANT, NOTIFY, DELAY, and APPROVAL.

The tiers work like this: small transactions execute immediately. Medium transactions execute and notify you. Large transactions queue for a time delay (during which you can cancel). Very large transactions require explicit human approval. You define the dollar thresholds.

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 this policy in place, an agent paying a $12 API bill executes immediately. An agent trying to move $3,000 in one shot waits 15 minutes and you get a notification. An agent trying to do something truly unusual hits an approval gate.

The default is deny. If you haven't configured ALLOWED_TOKENS or CONTRACT_WHITELIST, transactions are blocked. This is the right default for autonomous systems. You opt into access; you don't opt out of it.

Beyond spending limits, the full policy set covers: token whitelists, contract whitelists, rate limits, time restrictions, allowed networks, approved spenders, approval amount limits, DeFi-specific controls like LTV limits and max perpetual leverage, and even ERC-8004 onchain reputation thresholds. The policy engine isn't an afterthought — it's the thing that makes autonomous operation safe enough to actually deploy.

x402: The Payment Protocol Agents Were Waiting For

The most interesting capability for machine-to-machine commerce specifically is x402 HTTP payment protocol support. x402 extends HTTP with a 402 Payment Required status — when an API returns a 402, the client automatically pays and retries. No human interaction. No pre-negotiated API keys. Just an agent that pays for what it uses.

import { WAIaaSClient } from '@waiaas/sdk';

const client = new WAIaaSClient({
  baseUrl: 'http://127.0.0.1:3100',
  sessionToken: process.env.WAIAAS_SESSION_TOKEN,
});

// This fetch automatically handles 402 Payment Required responses
const response = await client.x402Fetch('https://api.example.com/premium-data');

From the agent's perspective, it's just an HTTP call. The wallet handles the 402 negotiation transparently. This is what actual machine-to-machine micropayments look like in practice — not a whitepaper concept, but a working implementation you can wire into an agent loop today.

You can lock down which domains an agent is allowed to pay automatically using the X402_ALLOWED_DOMAINS policy, so an agent can't be tricked into paying arbitrary endpoints.

7-Stage Transaction Pipeline

Every transaction — whether it's a simple token transfer, a DeFi action, or an NFT transfer — runs through a 7-stage pipeline: validate, auth, policy, wait, execute, confirm. The "wait" stage is where time-delay policies live. The "policy" stage is where spending limits and whitelists fire. The architecture means every transaction goes through the same safety checks regardless of how it was initiated.

There's also a dry-run mode for simulating transactions before execution:

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
  }'

A well-built agent doesn't fire transactions blindly. It simulates first, checks the result, then executes. The infrastructure needs to support that workflow, and WAIaaS does.

Multi-Chain From Day One

Agent commerce doesn't happen on one chain. WAIaaS supports 2 chain types (EVM and Solana) across 18 networks. The same session token works whether the agent is moving USDC on Ethereum, swapping on Jupiter, or staking SOL via Jito. The wallet abstraction handles chain-specific details — nonces, fee structures, address formats — so agent code stays clean.

15 DeFi protocol providers are integrated out of the box: Aave v3, Across, D'CENT Swap, Drift, ERC-8004, Hyperliquid, Jito Staking, Jupiter Swap, Kamino, Lido Staking, LI.FI, Pendle, Polymarket, XRPL DEX, and 0x Swap. An agent that needs to rebalance a portfolio, bridge funds cross-chain, enter a yield position, or trade perpetuals can do all of it through the same interface, subject to the same policy engine.

curl -X POST http://127.0.0.1:3100/v1/actions/jupiter-swap/swap \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer wai_sess_<token>" \
  -d '{
    "inputMint": "So11111111111111111111111111111111111111112",
    "outputMint": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
    "amount": "1000000000"
  }'

MCP Integration: Agents That Think and Spend

If you're building on the Model Context Protocol — connecting Claude, GPT-4, or another LLM to tools via MCP — WAIaaS ships 45 MCP tools covering wallet operations, transactions, DeFi positions, NFTs, and x402 payments. Setup is one command:

waiaas mcp setup --all

After that, the AI model can check balances, execute swaps, monitor incoming transactions, and pay for API calls as naturally as it calls any other tool. The MCP layer doesn't bypass the policy engine — every tool call still runs through the same 7-stage pipeline. The agent gets capability; you keep control.

Getting It Running

The fastest path from zero to a working agent wallet:

Step 1: Deploy with Docker

git clone https://github.com/minhoyoo-iotrust/WAIaaS.git
cd WAIaaS
docker compose up -d

The Docker image is ghcr.io/minhoyoo-iotrust/waiaas:latest, binding to 127.0.0.1:3100 by default. For production, use the secrets overlay (docker-compose.secrets.yml) to inject credentials via Docker Secrets rather than environment variables.

Step 2: Create a wallet and session

# Create wallet
curl -X POST http://127.0.0.1:3100/v1/wallets \
  -H "Content-Type: application/json" \
  -H "X-Master-Password: my-secret-password" \
  -d '{"name": "trading-wallet", "chain": "solana", "environment": "mainnet"}'

# Create agent session
curl -X POST http://127.0.0.1:3100/v1/sessions \
  -H "Content-Type: application/json" \
  -H "X-Master-Password: my-secret-password" \
  -d '{"walletId": "<wallet-uuid>"}'

Step 3: Set spending policies before funding

Configure at minimum a SPENDING_LIMIT and ALLOWED_TOKENS policy before you put real funds in. Default-deny means nothing moves without explicit permission.

Step 4: Wire the session token into your agent

import { WAIaaSClient } from '@waiaas/sdk';

const client = new WAIaaSClient({
  baseUrl: process.env.WAIAAS_BASE_URL,
  sessionToken: process.env.WAIAAS_SESSION_TOKEN,
});

const balance = await client.getBalance();

Or use the CLI shortcut that handles steps 2-4 in one shot:

waiaas quickset --mode mainnet

Step 5: Connect the interactive API docs

open http://127.0.0.1:3100/reference

The OpenAPI 3.0 spec is auto-generated from the codebase and served at /doc. The interactive Scalar UI at /reference lets you explore all 39 REST API route modules and test calls directly — useful when you're building out agent logic and want to see exactly what each endpoint returns.

What This Means for the Agent Economy

The question of how AI agents pay for things isn't theoretical anymore. The x402 protocol gives APIs a standard way to charge programmatic clients. ERC-4337 Account Abstraction makes gasless transactions and smart account logic practical. ERC-8004 provides a framework for onchain agent reputation. The pieces are assembling.

What's been missing is the infrastructure layer that connects agent logic to these payment primitives with appropriate security controls in between. An agent that can spend without guardrails is a liability. An agent that requires human approval for every transaction isn't autonomous. The right answer is a programmable policy engine that enforces rules at the infrastructure level — so that when the agent acts within its mandate, it acts freely, and when it tries to exceed that mandate, the system stops it.

That's what WAIaaS is built to provide. Not a vision of future infrastructure, but running code you can deploy today.

What's Next

The GitHub repository has the full source, Docker setup, and SDK documentation. The official site covers architecture and integration guides. If you're building agents that need economic agency — the ability to pay for APIs, execute trades, manage positions, or participate in on-chain protocols — the financial rails are ready when you are.