DEV Community: Wallet Guy

Build Gasless AI Trading Bots with ERC-4337 Account Abstraction

Wallet Guy — Thu, 23 Jul 2026 08:48:57 +0000

Build Gasless AI Trading Bots with ERC-4337 Account Abstraction

Gasless AI trading bots are finally practical — but only if you're not spending half your development time wiring up 13 different protocol SDKs. Jupiter, Aave, Lido, Drift, Hyperliquid, Across — every DeFi protocol has its own integration story, its own auth model, its own quirks. If you're building a trading bot or automated yield strategy, that integration tax quietly becomes the actual project.

Why This Integration Tax Kills DeFi Bots

Here's the reality of building a multi-protocol DeFi bot in 2026: you pick a strategy — say, borrow on Aave, bridge to Solana via Across, deploy liquidity on Kamino — and suddenly you're maintaining separate SDKs for each leg. When Aave pushes a contract upgrade, you patch one library. When Jupiter changes its routing API, you patch another. Before you know it, 60% of your codebase is protocol glue code, not strategy logic.

The stakes are real. A bot that goes offline during a market move because a dependency broke isn't just annoying — it's a P&L event. Developers building serious automated strategies need one stable interface that handles the protocol-level complexity so they can focus on the logic that actually generates returns.

ERC-4337 Account Abstraction makes gasless transactions possible in theory. What makes them practical in production is having a system that combines AA with policy enforcement, multi-protocol access, and security controls that don't require you to rebuild from scratch.

What WAIaaS Actually Gives You

WAIaaS is an open-source, self-hosted Wallet-as-a-Service for AI agents. The relevant part for DeFi developers: it exposes 15 integrated DeFi protocol providers through a single REST API, with ERC-4337 Account Abstraction, a 7-stage transaction pipeline, and a policy engine with 21 policy types baked in.

The 15 protocols are: aave-v3, across, dcent-swap, drift, erc8004, hyperliquid, jito-staking, jupiter-swap, kamino, lido-staking, lifi, pendle, polymarket, xrpl-dex, and zerox-swap.

That covers the major DeFi categories you actually care about:

Swaps: Jupiter (Solana), 0x, LI.FI, D'CENT
Lending: Aave v3, Kamino
Liquid staking: Lido (EVM), Jito (Solana)
Cross-chain bridging: LI.FI, Across
Perpetuals and spot: Hyperliquid, Drift
Prediction markets: Polymarket
Fixed yield: Pendle

Two chain types — EVM and Solana — across 18 networks. One API surface.

On the account abstraction side, WAIaaS provides ERC-4337 support with smart accounts, gasless transactions, and a UserOp build/sign API. That means your bot can execute transactions without holding ETH for gas on every chain it operates on — the sponsor handles it.

The Three-Auth Model You Need to Understand

Before diving into code, the auth model matters for how you architect your bot.

WAIaaS uses three authentication layers:

# masterAuth — system administrator (wallet creation, session management, policies)
-H "X-Master-Password: my-secret-password"

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

# ownerAuth — fund owner (transaction approval, kill switch recovery)
-H "X-Owner-Signature: <ed25519-or-secp256k1-signature>"
-H "X-Owner-Message: <signed-message>"

For a trading bot, the pattern is: your system admin creates wallets and sessions with masterAuth, the bot itself runs with sessionAuth (a JWT scoped to a specific wallet), and you as the fund owner retain ownerAuth for approving large transactions or recovering control. The bot never touches your master password.

Auth methods under the hood: masterAuth uses Argon2id, ownerAuth uses SIWS/SIWE (Sign-In with Solana/Ethereum), and sessionAuth uses JWT HS256. Per-session TTL, maxRenewals, and absoluteLifetime are all configurable.

Setting Up Your Trading Bot Wallet

Start with Docker — it's the fastest path to a running instance:

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

The daemon binds to 127.0.0.1:3100 by default. Create a wallet 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-wallet", "chain": "solana", "environment": "mainnet"}'

Then create a session token for the 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>"}'

That session token (wai_sess_...) is what your bot uses for every subsequent call. Scope it tight — the policy engine is what enforces the actual limits.

Policy Engine: Your Bot's Risk Manager

This is the part that separates production-grade bots from scripts. WAIaaS has a policy engine with 21 policy types and 4 security tiers: INSTANT, NOTIFY, DELAY, and APPROVAL.

The default is deny. Transactions are blocked unless explicitly allowed. This is the right default for autonomous agents moving real funds.

Here's a practical policy setup for a trading bot:

# Spending limit with 4-tier security
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
    }
  }'

Tier assignment logic: amount <= instant_max → execute immediately. <= notify_max → execute and notify you. <= delay_max → queue for 900 seconds (cancellable). > delay_max → requires human approval via WalletConnect, Telegram, or push notification.

For a bot that trades across protocols, you also want contract and token whitelists — these are default-deny independently:

The CONTRACT_WHITELIST policy blocks calls to any contract not explicitly listed. The ALLOWED_TOKENS policy blocks transfers of any token not on the list. The APPROVED_SPENDERS policy controls which addresses can be approved to spend from the wallet. For perpetuals, PERP_MAX_LEVERAGE, PERP_MAX_POSITION_USD, and PERP_ALLOWED_MARKETS let you enforce risk limits at the infrastructure layer rather than in your bot code.

DeFi-specific policies worth knowing: LENDING_LTV_LIMIT caps loan-to-value ratios on Aave/Kamino positions, LENDING_ASSET_WHITELIST restricts which assets can be used as collateral or borrowed, and VENUE_WHITELIST controls which trading venues the bot can route through.

Multi-Protocol Execution: The Actual API Calls

Here's what unified protocol access looks like in practice. All of these use the same session token pattern.

Swap on Jupiter (Solana):

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. The routing, slippage handling, and transaction construction happen inside the provider — your bot just sends the intent.

Check balance before acting:

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

Simulate before executing (critical for bots):

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 flag runs the transaction through the full 7-stage pipeline — validate, auth, policy check, wait, execute, confirm — but stops before broadcast. You get the policy decision, the simulated outcome, and any errors before any funds move. For automated strategies, always dry-run before live execution on new code paths.

Gas conditional execution is another pipeline feature worth knowing: transactions can be configured to execute only when gas price meets a threshold. That's stage4-wait in the pipeline — your bot queues the transaction and the pipeline holds it until conditions are met.

Building the Bot in TypeScript

The TypeScript SDK gives you typed access to the same API surface:

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 trading
const balance = await client.getBalance();
console.log(`Balance: ${balance.balance} ${balance.symbol} (${balance.chain}/${balance.network})`);

// Execute a transfer — DeFi action calls follow the same pattern
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 being explicit about. Policy denials come back as structured errors:

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 code detail tells you exactly which policy fired — SPENDING_LIMIT, CONTRACT_WHITELIST, PERP_MAX_LEVERAGE, etc. That's actionable. Your bot can log it, alert you, and back off — rather than silently failing or throwing an opaque RPC error.

MCP Integration for AI-Driven Strategies

If your bot uses an LLM for decision-making (Claude, GPT-4, or any MCP-compatible agent), WAIaaS exposes 45 MCP tools that map directly to wallet, transaction, DeFi, NFT, and x402 operations.

Quick setup:

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

The Claude Desktop config:

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

You can run multiple wallets as separate MCP servers — one for your Solana trading wallet, one for your EVM yield strategies — with separate policy sets for each. The agent calls get_defi_positions to see current exposure across Aave, Kamino, Lido, and Jito, then acts on the result.

Quick Start: Five Steps to a Running Bot

Deploy WAIaaS: docker compose up -d — daemon runs at 127.0.0.1:3100
Create a wallet: POST /v1/wallets with masterAuth
Create a session: POST /v1/sessions with masterAuth, get wai_sess_... token
Set policies: At minimum, SPENDING_LIMIT + ALLOWED_TOKENS + CONTRACT_WHITELIST
Execute: Use sessionAuth for all bot calls — swap, lend, stake, bridge through the unified API

For auto-provisioning without a manual password setup:

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

docker exec waiaas cat /data/recovery.key

The full OpenAPI 3.0 spec is at http://127.0.0.1:3100/doc with an interactive reference UI at /reference. All 39 REST API route modules are documented there — useful when you're mapping protocol-specific action parameters.

What's Next

The 15 integrated DeFi protocols, 21 policy types, and ERC-4337 support are documented in full detail on the WAIaaS GitHub repository — the codebase is open source and the protocol provider implementations are readable. For production deployments, review the Docker Secrets overlay pattern (docker-compose.secrets.yml) and the 3-layer security architecture before going live with real funds. Visit waiaas.ai for the full documentation and community resources.

Complete Self-Hosting Guide: 20 CLI Commands + Docker for AI Agent Wallets

Wallet Guy — Wed, 22 Jul 2026 15:12:02 +0000

Complete Self-Hosting Guide: 20 CLI Commands + Docker for AI Agent Wallets

Self-hosting your AI agent's wallet infrastructure means your private keys never leave your server — and with WAIaaS, you can have the whole stack running in a single Docker command. If you've ever asked yourself whether you'd trust a third-party service with the keys that control your autonomous agent's funds, this guide is for you. We'll walk through every CLI command, the Docker setup, and the policy engine that keeps your agent from going rogue.

Why Self-Custody for AI Agents Actually Matters

There's a meaningful difference between self-hosting a blog and self-hosting financial infrastructure. When an AI agent can autonomously send transactions, the question of who controls the keys becomes genuinely important — not just philosophically, but operationally.

With a hosted wallet service, you're trusting a third party to hold private keys on behalf of your agent, enforce your spending rules, and keep your transaction history private. Every request you make passes through their infrastructure, subject to their rate limits, their uptime SLAs, and their terms of service. Self-hosting flips this entirely: your keys are generated and stored on your own hardware, your policies run in your own process, and the only rate limits you face are the ones your server can handle. It's the crypto equivalent of running your own email server — except in 2026, WAIaaS makes it genuinely practical rather than a masochistic weekend project.

What You're Actually Installing

WAIaaS is a 15-package monorepo organized as a Wallet-as-a-Service designed specifically for AI agents. The core daemon exposes 39 REST API route modules, provides 45 MCP tools for AI agent integration, supports 18 networks across both Solana and EVM chains, and integrates 15 DeFi protocol providers. It ships as two Docker images: the main WAIaaS daemon and a push-relay service for mobile notifications.

The architecture is built around three distinct principals:

Master password — system administrator, creates wallets and sessions
Session tokens — what your AI agent actually uses to transact
Owner auth — you, the human, approving high-value transactions via WalletConnect or Telegram

This separation means your AI agent has just enough access to do its job, and nothing more.

Installation: One Command or the Full CLI Path

The Docker Fast Lane

If you want to be running in under two minutes:

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. Notice the port binding: 127.0.0.1:3100:3100 — by default, the daemon only listens on localhost. This is a deliberate choice. You don't want an AI wallet daemon accidentally exposed to the public internet.

For a more production-ready setup, the included Docker Compose file handles health checks, restart policies, and environment configuration:

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

Start it with:

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

For production deployments where you want to keep secrets out of environment variables entirely, there's a secrets overlay:

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 docker-compose.secrets.yml overlay uses Docker Secrets to inject credentials into the container without exposing them in docker inspect output or shell history. This is the pattern you want for anything running in a homelab that faces even semi-public networks.

The CLI Path (All 20 Commands)

If you prefer installing locally or want more granular control, the CLI gives you everything:

npm install -g @waiaas/cli
waiaas init                    # Create data directory + config.toml
waiaas start                   # Start daemon
waiaas quickset --mode mainnet # Create wallets + MCP sessions in one step

The full CLI ships with exactly 20 commands:

Command	What it does
`init`	Create data directory and config.toml
`start`	Start the daemon process
`stop`	Stop the daemon
`status`	Check daemon health
`quickstart`	Opinionated first-run setup
`quickset`	Create wallets + sessions in one step
`set-master`	Harden master password after auto-provision
`wallet create`	Create a new wallet
`wallet info`	Display wallet details and address
`session prompt`	Open interactive session management
`owner connect`	Link owner wallet via WalletConnect
`owner disconnect`	Unlink owner wallet
`owner status`	Show owner connection status
`mcp setup`	Register wallets with Claude Desktop
`notification setup`	Configure push/Telegram notifications
`backup create`	Create encrypted backup
`backup inspect`	Read backup metadata without restoring
`backup list`	List available backups
`restore`	Restore from backup
`update`	Update WAIaaS to latest version

The recommended self-hosted workflow uses auto-provision to avoid typing a password during setup, then hardens it afterward:

npm install -g @waiaas/cli
waiaas init --auto-provision   # Generates random master password → recovery.key
waiaas start                   # No password prompt
waiaas quickset                # Creates wallets + sessions automatically
waiaas set-master              # Later: set a real password, then delete recovery.key

Creating Wallets and Sessions

Once the daemon is running, wallet creation goes through the master password:

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

Then create a session token for your AI agent to use:

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

That session token (wai_sess_...) is what your agent gets. It can check balances, send transactions, and call DeFi actions — but it cannot create new wallets, modify policies, or access the master password. Sessions support per-token TTL, maxRenewals, and absoluteLifetime configuration, so you can scope exactly how long an agent credential stays valid.

The Policy Engine: Where Self-Hosting Really Pays Off

This is where running your own WAIaaS instance genuinely shines. The policy engine has 21 policy types, 4 security tiers, and enforces default-deny: if ALLOWED_TOKENS or CONTRACT_WHITELIST aren't configured, transactions are blocked by default. You're not opting into restrictions — you're explicitly opting out of the safest state.

The four security tiers determine what happens when a transaction comes in:

INSTANT — Execute immediately, no notification
NOTIFY — Execute immediately, send you a notification
DELAY — Queue for N seconds, giving you time to cancel
APPROVAL — Hold until you explicitly approve via WalletConnect or Telegram

A spending limit policy that uses all four tiers looks like this:

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

Under this policy: transactions under $100 go straight through, $100–$500 trigger a notification to your phone, $500–$2,000 are queued for 15 minutes (cancellable), and anything above $2,000 requires your explicit approval. The transaction pipeline runs through 7 stages — validate, auth, policy, wait, execute, confirm — so the delay and approval mechanics are enforced at the infrastructure level, not in application code you wrote.

Beyond spending limits, you have policies like:

ALLOWED_TOKENS — whitelist which tokens the agent can touch
CONTRACT_WHITELIST — whitelist which contracts it can call
PERP_MAX_LEVERAGE — cap leverage for Hyperliquid perp trading
X402_ALLOWED_DOMAINS — control which APIs the agent can autonomously pay
REPUTATION_THRESHOLD — require minimum ERC-8004 onchain reputation score before transacting

The full list of 21 types covers everything from TIME_RESTRICTION (only allow transactions during business hours) to LENDING_LTV_LIMIT (max loan-to-value ratio for Aave positions).

Connecting Your AI Agent

Once you have a session token, connecting Claude or any MCP-compatible agent takes about 30 seconds:

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

Or configure 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"
      }
    }
  }
}

The MCP server exposes 45 tools covering wallet operations, transfers, DeFi actions, NFT management, and x402 HTTP payments. After setup, you can tell Claude to check your balance, swap SOL for USDC on Jupiter, or show your DeFi positions across all 15 integrated protocols — and every one of those transactions flows through the policy engine you configured on your own server.

For agents built with the TypeScript SDK instead of MCP:

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}`);

const tx = await client.sendToken({
  to: 'recipient-address...',
  amount: '0.1',
});

A Python SDK (pip install waiaas) is also available with async/await support, using the same session token for auth.

Keeping Things Running

A few operational notes for self-hosters:

Backups: Use waiaas backup create before any major changes. The backup inspect command lets you read metadata from a backup file without actually restoring it — useful for verifying that your automated backup job is producing valid files.

Updates: waiaas update handles pulling the latest version. If you're running Docker Compose, you can also use Watchtower for automatic image updates — the daemon image supports this pattern.

RPC endpoints: By default you'll want to configure your own RPC endpoints rather than relying on public nodes:

WAIAAS_RPC_SOLANA_MAINNET=<your-rpc-url>
WAIAAS_RPC_EVM_ETHEREUM_MAINNET=<your-rpc-url>

Dry-run before you commit: The simulate endpoint lets you preview a transaction's outcome before actually 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
  }'

API docs: Once the daemon is running, hit http://127.0.0.1:3100/reference for the interactive Scalar API reference UI, or download the full OpenAPI 3.0 spec at /doc. With 39 route modules, having searchable docs locally is genuinely useful.

The Self-Hosted Philosophy in Practice

There's a particular type of developer who runs their own Nextcloud instead of Dropbox, their own Gitea instead of a hosted alternative, their own Vaultwarden instead of a hosted password manager. The motivation isn't that hosted services are bad — it's that sovereignty over your own data and infrastructure is worth the operational overhead.

AI agent wallets fit this mindset naturally. The agent is acting on your behalf, with your funds, following your rules. Having that entire system run on hardware you control — with private keys that never leave your server, policies enforced by your own process, and transaction logs stored in your own database — is simply the consistent application of the same principle you already apply to the rest of your stack.

WAIaaS is built for exactly this use case: open-source, self-hostable, with a 683+ test file codebase and a Docker image that runs as a non-root user (UID 1001) by default.

What's Next

The best next step is getting the daemon running and creating your first wallet — the quickstart flow takes about five minutes from zero. From there, spend time with the policy engine before connecting any live funds: understanding the 21 policy types and how the 4 security tiers compose gives you real confidence in what your agent can and cannot do autonomously.

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

AI Agents as Prediction Traders: Automating Polymarket with Real Money

Wallet Guy — Wed, 22 Jul 2026 09:03:28 +0000

AI Agents as Prediction Traders: Automating Polymarket with Real Money

Prediction market trading with AI agents isn't a research concept anymore — it's something you can deploy today, with real money, on Polymarket, using infrastructure that exists right now. The gap between "AI that can reason about probabilities" and "AI that can act on those probabilities in a market" has always been wallet infrastructure. That gap is now closed.

Why This Matters More Than You Think

Polymarket is one of the few places on the internet where being right about the future has immediate, verifiable financial consequences. Prediction markets aggregate information better than most institutions. They're also one of the cleaner venues for AI agents to demonstrate economic judgment — the signal is unambiguous. Either the market resolves in your favor or it doesn't.

But reasoning about outcomes is the easy part. The hard part is the infrastructure layer underneath: How does an agent hold funds? How does it execute a trade without a human approving every click? How do you prevent it from losing everything in a single bad position? These aren't AI problems. They're wallet problems. And they've been largely ignored while everyone focused on making agents smarter.

The moment you want an agent to participate in a prediction market autonomously — not just recommend trades, but actually execute them — you need autonomous wallet infrastructure. Not a custodied account with a human holding the keys. Not a hot wallet you paste into a config file and hope for the best. Something designed from the ground up for agents.

What "Autonomous Wallet Infrastructure" Actually Means

WAIaaS (Wallet-as-a-Service for AI agents) is an open-source, self-hosted daemon that gives AI agents their own wallet with full transaction capabilities, a policy engine that enforces spending rules, and a security model that keeps a human owner in the loop for decisions that matter — without requiring human approval for every small trade.

Here's what that looks like in practice for a Polymarket trading agent.

The agent needs to:

Hold USDC (Polymarket's settlement token)
Call Polymarket's smart contracts to place and manage positions
Stay within predefined risk limits
Report back to its owner when something significant happens

WAIaaS handles all four. The agent gets a session token. The owner sets policies. The daemon enforces them.

The Policy Engine: Your Risk Manager That Never Sleeps

Before writing a single line of agent code, you configure what the agent is allowed to do. WAIaaS has 21 policy types organized into 4 security tiers: INSTANT, NOTIFY, DELAY, and APPROVAL.

For a Polymarket agent, a reasonable starting configuration looks like this:

# Set a spending limit with tiered security
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
    }
  }'

What this does: any trade under $100 executes immediately with no notification. Trades between $100–$500 execute immediately but you get a notification. Trades between $500–$2,000 go into a 15-minute queue — you can cancel them. Anything over $2,000 requires explicit human approval. The daily cap is $5,000 regardless.

This is exactly how you'd configure a junior trader with a defined mandate. The agent has real autonomy within the envelope. You retain control over decisions outside it.

You'd also configure a CONTRACT_WHITELIST to make sure the agent can only interact with Polymarket's contracts — nothing else:

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": "CONTRACT_WHITELIST",
    "rules": {
      "contracts": [{"address": "0x4D97DCd97eC945f40cF65F87097ACe5EA0476045", "name": "Polymarket CTF Exchange", "chain": "polygon"}]
    }
  }'

WAIaaS enforces default-deny: if CONTRACT_WHITELIST is configured, the agent cannot call any contract that isn't on the list. Even if the agent's reasoning goes completely sideways and it tries to do something else with the funds, the policy layer blocks it at the daemon level — before the transaction ever hits the network.

The Polymarket integration itself is available through the polymarket provider, which is one of WAIaaS's 15 integrated DeFi protocol providers.

Giving the Agent Its Session Token

The wallet is created by a human administrator using the master password. The agent operates using a session token — a scoped credential that can be revoked at any time.

# Create the wallet (you do this once)
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": "polymarket-agent", "chain": "evm", "environment": "mainnet"}'

# Create a session for the agent (scoped to this wallet)
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>"}'

The session token goes into your agent's environment. The agent never sees the master password. It can't create new wallets, change policies, or touch anything outside its session scope. This is the authentication separation that makes autonomous operation safe: three distinct auth layers (masterAuth, sessionAuth, ownerAuth) with different capabilities and different holders.

Sessions support per-session TTL, maximum renewals, and absolute lifetime limits — so a compromised session has a hard expiry.

The Agent Code: Checking Balance and Executing a Trade

Once the agent has a session token, it operates through the REST API or the TypeScript SDK. Here's what a minimal Polymarket trading loop looks like using the 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'],
});

// Check available balance before placing any position
const balance = await client.getBalance();
console.log(`Available: ${balance.balance} ${balance.symbol} on ${balance.chain}/${balance.network}`);

// Agent reasoning happens here — probability assessment, Kelly criterion sizing, etc.
// Once the agent decides to place a trade, it submits via the actions API

The actual Polymarket position is executed through the polymarket action provider. The agent calls the action endpoint with the position details, and WAIaaS handles the rest: policy validation, transaction construction, signing, and submission.

If the transaction is within the INSTANT tier, it goes through immediately. If it hits the NOTIFY tier, it executes and the owner gets a notification. If it's large enough to require DELAY or APPROVAL, the agent gets back a pending transaction ID and can poll for status.

# Check a pending transaction status
curl http://127.0.0.1:3100/v1/transactions/<tx-id> \
  -H "Authorization: Bearer wai_sess_<token>"

Simulating Before You Commit Real Money

Before the agent goes live, you can run every transaction in dry-run mode. The simulation API evaluates the full pipeline — policy checks, balance validation, transaction construction — without actually submitting anything 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
  }'

Run your agent in dry-run mode for a week. Watch what it would have done. Tune the policies. Then flip the switch.

When the Agent Needs Human Sign-Off

For positions above your APPROVAL threshold, the owner gets a notification and can approve or reject via WalletConnect, Telegram, or a push notification. The transaction sits in the queue until the owner acts.

# Owner approves a pending large position
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>"

WAIaaS has 3 signing channels built in: push relay, Telegram, and wallet notification. The owner can approve from a phone while the agent continues operating normally on everything within its autonomous envelope.

This is the human-in-the-loop model that actually scales. Not "approve every trade" — that's not autonomous. Not "approve nothing" — that's not safe. The policy engine defines the boundary, and the agent operates freely within it.

Connecting to Claude or Any MCP-Compatible Agent

If you're using Claude or another MCP-compatible agent framework, WAIaaS exposes 45 MCP tools that cover the full wallet and trading surface. Setup is one command:

waiaas mcp setup --all

Then add the configuration to Claude Desktop:

{
  "mcpServers": {
    "waiaas-polymarket": {
      "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"
      }
    }
  }
}

Claude can now call get_balance, execute_action with the Polymarket provider, get_defi_positions, and simulate_transaction directly. The conversation becomes the trading interface. The policies you set in WAIaaS are the guardrails Claude operates within, regardless of what prompt someone feeds it.

Quick Start: Get a Polymarket Agent Running

Here's the minimal path from zero to a running agent:

Step 1: Install and start WAIaaS

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

Step 2: Create a wallet and configure policies

# Create the agent 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": "polymarket-agent", "chain": "evm", "environment": "mainnet"}'

# Set spending 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}}'

Step 3: Create a session token 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>"}'

Step 4: Install the SDK and start building

npm install @waiaas/sdk

Step 5: Run in dry-run mode first. Test your agent's logic against real market conditions without risking funds. Watch the policy engine catch anything outside your configured parameters.

The Deeper Point

What makes this interesting isn't Polymarket specifically. It's the model it demonstrates: an AI agent with a real economic presence, operating within a policy envelope defined by a human owner, capable of autonomous action within that envelope and escalation outside it.

Prediction markets are one of the cleaner test cases because the feedback loop is tight and objective. But the same infrastructure — scoped session tokens, a 21-type policy engine, 7-stage transaction pipeline, incoming transaction monitoring, and human-in-the-loop approval channels — applies to any economic activity you want an agent to perform.

The question "how do AI agents participate in economic activity" now has a working answer. The infrastructure exists. What agents do with it is the open question.

What's Next

The WAIaaS Admin UI at /admin gives you a real-time view of your agent's positions, transaction history, and policy status without touching the API. For production deployments, the Docker setup with secrets overlay handles credential management properly — worth reading before you go live with real funds.

Explore the codebase and full documentation on GitHub at https://github.com/waiaas/WAIaaS, or visit https://waiaas.ai for the official site. The OpenAPI spec and interactive API reference are available at /doc and /reference once your daemon is running — start there to understand the full surface area before building your agent.

Instant Cross-Chain Arbitrage: Across Protocol Integration for Trading Bots

Wallet Guy — Tue, 21 Jul 2026 15:14:05 +0000

Instant Cross-Chain Arbitrage: Across Protocol Integration for Trading Bots

Your arb bot spotted the opportunity — a price discrepancy between Ethereum and Solana that closes in seconds. The real question isn't whether your strategy is correct. It's whether your wallet infrastructure can execute before the window disappears. Cross-chain arbitrage bots fail not because of bad alpha, but because of brittle plumbing: fragmented wallets, missing gas checks, no policy guardrails, and no way to coordinate multi-leg trades across protocols in a single coherent loop.

Why Infrastructure Is the Bottleneck

Most trading bot builders spend weeks writing the alpha logic, then another month duct-taping wallet management together. You end up with hardcoded private keys, manual nonce tracking, no spending limits, and zero observability. When a trade goes sideways — wrong gas estimate, slippage exceeded, network congestion — there's no recovery path. The bot either throws or silently bleeds funds.

The infrastructure problem compounds as your strategy grows. A simple single-chain swap is manageable. But the moment you add cross-chain bridging, perpetual futures hedging, and automated token approvals, you need a system that handles auth, policy enforcement, transaction sequencing, and multi-protocol routing as first-class concerns — not afterthoughts bolted onto a key-value store.

WAIaaS is a self-hosted Wallet-as-a-Service built specifically for this. It's open-source, runs in Docker, and exposes a REST API your bots talk to over localhost. Your private keys never leave your infrastructure.

What's Available for Trading Bots

WAIaaS integrates 15 DeFi protocol providers out of the box:

Cross-chain bridging: Across and LI.FI
Spot and perp trading: Jupiter Swap (Solana), Drift (Solana perps), Hyperliquid (perps + spot), 0x Swap, D'CENT Swap
Lending/yield: Aave v3, Kamino, Pendle
Staking: Lido (EVM), Jito (Solana)
Prediction markets: Polymarket
XRPL DEX
Agent reputation: ERC-8004

For a cross-chain arb bot, the critical trio is: Jupiter Swap for Solana-side execution, Across for bridging capital between chains, and Drift or Hyperliquid for hedging exposure while the bridge settles.

The system runs across 18 networks (EVM + Solana) and supports 7 transaction types: Transfer, TokenTransfer, ContractCall, Approve, Batch, NftTransfer, and ContractDeploy.

The 7-Stage Transaction Pipeline

Before diving into code, understand what happens when your bot submits a trade. WAIaaS runs every transaction through a 7-stage pipeline:

Validate — schema and parameter checks
Auth — session token verification
Policy — 21 policy types evaluated against the transaction
Wait — gas condition checks, time delays if policy requires
Execute — broadcast to chain
Confirm — wait for on-chain confirmation

Stage 3 and Stage 4 are where trading bots benefit most. Policy enforcement means your bot can't accidentally blow past a daily limit. Gas conditional execution means the transaction only fires when network conditions meet your threshold — your bot doesn't waste gas on congested blocks.

Setting Up a Trading Wallet

Start the daemon and create a dedicated wallet for your arb bot:

# Install CLI and start daemon
npm install -g @waiaas/cli
waiaas init
waiaas start

# Or with Docker
docker compose up -d

Then 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": "arb-bot-eth", "chain": "evm", "environment": "mainnet"}'

Create a session token your bot will use for all trading operations:

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

Store the returned session token as WAIAAS_SESSION_TOKEN. Every trade your bot makes will authenticate with this token. No private key exposure, no nonce management in your bot code.

Policy Configuration for Trading Bots

This is the part most bot builders skip — and regret. Configure spending controls before your bot goes live.

# Daily limit with tiered approval 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
    }
  }'

The 4-tier system maps directly to trading risk management:

INSTANT (≤ $100): Small arb trades execute immediately — no latency added
NOTIFY (≤ $500): Executes immediately, but you get notified — good for monitoring
DELAY (≤ $2,000): Queued for 15 minutes, cancellable if market moves against you
APPROVAL (> $2,000): Requires human sign-off via WalletConnect or Telegram

For a bot trading smaller sizes at high frequency, set instant_max_usd to your max position size and let the engine handle the rest.

You should also whitelist the specific contracts your bot interacts with. The policy engine uses default-deny for contract calls — if CONTRACT_WHITELIST is configured, any contract not on the list is blocked:

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": "CONTRACT_WHITELIST",
    "rules": {
      "contracts": [
        {"address": "JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4", "name": "Jupiter v6", "chain": "solana"},
        {"address": "<across-spoke-pool-address>", "name": "Across SpokePool", "chain": "ethereum-mainnet"}
      ]
    }
  }'

For perpetual trading on Drift or Hyperliquid, add leverage limits to prevent your bot from over-leveraging in volatile conditions:

# Max 5x leverage on perps
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": {"maxLeverage": 5}
  }'

All 21 policy types are available — PERP_MAX_POSITION_USD, PERP_ALLOWED_MARKETS, RATE_LIMIT, and VENUE_WHITELIST are all relevant for systematic trading.

Executing the Arb: Swap → Bridge → Hedge

Here's a concrete multi-leg flow. Your bot detects a SOL/USDC price discrepancy between Jupiter and a CEX. The play: buy SOL on Jupiter, bridge USDC to Ethereum via Across, then hedge the delta on Hyperliquid perps.

Leg 1: Swap USDC → SOL 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": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
    "outputMint": "So11111111111111111111111111111111111111112",
    "amount": "1000000000"
  }'

Leg 2: Bridge USDC to Ethereum via Across

The Across provider handles the cross-chain bridge. Your bot submits to the /v1/actions/across/ endpoint with the origin and destination parameters. Across uses intent-based bridging with relayers, which means faster settlement than optimistic bridges — critical for arb timing.

Leg 3: Simulate before committing

Before any large trade fires, use dry-run to validate execution without spending gas:

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

Run this on every leg before committing. If the simulation fails — policy denied, insufficient balance, contract revert — your bot gets a structured error response with a machine-readable code:

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

retryable: false means don't retry. retryable: true means transient failure — safe to retry with backoff. Your bot's error handler can branch on error.code directly.

TypeScript Bot Integration

Use the TypeScript SDK for cleaner bot code with full type safety:

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'],
});

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

  // Submit trade
  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(`Transaction confirmed! Hash: ${tx.txHash}`);
      break;
    }
    if (tx.status === 'FAILED') {
      console.error(`Transaction failed: ${tx.error}`);
      break;
    }
    await new Promise(resolve => setTimeout(resolve, 1000));
  }
}

// Handle policy denials and other errors
try {
  await executeArbLeg();
} catch (error) {
  if (error instanceof WAIaaSError) {
    console.error(`API Error: [${error.code}] ${error.message}`);
    // error.code: INSUFFICIENT_BALANCE, POLICY_DENIED, TOKEN_EXPIRED
  }
}

The SDK has zero external dependencies. Methods you'll use constantly: getBalance(), getAssets(), sendToken(), getTransaction(), listTransactions(), signTransaction(). The full TypeScript SDK ships as @waiaas/sdk.

Gas Conditional Execution

This deserves its own section because it's underused. WAIaaS has a built-in gas condition stage in the pipeline — transactions queue until gas price drops below your configured threshold.

For arb bots, this is valuable in two scenarios:

Rebalancing operations — moving capital between wallets or chains is not time-sensitive. Let gas conditions decide when it executes.
Multi-leg setups with tolerance — if your arb margin is 0.3% and gas eats 0.25% at current prices, the trade isn't worth it. Gas conditional execution enforces this automatically.

Your bot submits the transaction, the pipeline holds it at stage 4, and execution fires when conditions are met. No polling loop required in your bot code.

Monitoring DeFi Positions

After your bot has deployed capital across Aave, Kamino, or Drift, you need to track aggregate exposure. The DeFi positions endpoint aggregates across all integrated protocols:

curl http://127.0.0.1:3100/v1/wallet/defi-positions \
  -H "Authorization: Bearer wai_sess_<token>"

For lending protocols, the LENDING_LTV_LIMIT policy type enforces a maximum loan-to-value ratio. If your bot is borrowing against collateral, this policy prevents it from opening positions that approach liquidation territory.

Connecting Claude or Other AI Agents to Your Bot Infrastructure

If you're building a hybrid system where an LLM agent assists with trade decisions, WAIaaS provides 45 MCP tools that connect directly to Claude Desktop or any MCP-compatible framework:

waiaas mcp setup --all

This auto-registers all wallets with Claude Desktop. The MCP tool list includes hyperliquid, polymarket, get-defi-positions, simulate-transaction, send-batch, and x402-fetch — the full surface area of the wallet API exposed as structured tools the LLM can call.

For multi-strategy setups, run separate MCP server instances per wallet:

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

Quickstart: Bot Infrastructure in 5 Steps

Install and start

   npm install -g @waiaas/cli
   waiaas init
   waiaas quickset --mode mainnet

Create a trading wallet — POST to /v1/wallets with chain: "evm" or chain: "solana"
Configure policies — SPENDING_LIMIT + CONTRACT_WHITELIST at minimum before going live
Install the SDK — npm install @waiaas/sdk, initialize with your session token
Dry-run every leg — set dryRun: true in your transaction payload, validate the response, then submit for real

The interactive API reference at http://127.0.0.1:3100/reference (Scalar UI) documents all 39 route modules. The OpenAPI 3.0 spec is downloadable at /doc for generating client code in any language. A Python SDK (pip install waiaas) is also available with full async/await support.

What's Next

WAIaaS is open-source and self-hosted — your keys stay on your infrastructure, your bot logic stays private, and you're not dependent on third-party custody. The 15 integrated DeFi protocols, 21 policy types, and

The Future of API Bills: When Machines Pay Machines with x402 Protocol

Wallet Guy — Tue, 21 Jul 2026 09:05:36 +0000

The Future of API Bills: When Machines Pay Machines with x402 Protocol

AI agents will need to pay for compute, data, and API calls — and right now, the infrastructure to let them do that autonomously barely exists. Most agents today either rely on humans to top up a credit card, or they're locked inside a platform's billing system with no ability to operate independently. That's a fundamental mismatch between what agents need to do and what they're actually capable of doing.

Why This Matters More Than It Sounds

Think about what an autonomous AI agent actually does all day. It calls APIs. It fetches data. It runs inference. It queries databases. Every one of those actions has a cost, and today, a human is almost always the one footing the bill — manually, via a shared API key, or through some corporate account the agent doesn't actually control.

This works fine when agents are simple tools. But as agents become more autonomous — running multi-step workflows, operating overnight, spawning sub-agents, coordinating with other systems — the billing model breaks down. You can't have a human approve every $0.003 API call at 2am. You need the agent to handle it.

The x402 protocol is one of the clearest answers to this problem that exists today. And WAIaaS ships it as a first-class feature, built into the wallet infrastructure your agents already use.

What x402 Actually Is

x402 is an HTTP payment protocol. The idea is simple but powerful: when a server needs payment before serving a response, it returns an HTTP 402 status code ("Payment Required") with machine-readable payment details. The client — in this case, your AI agent — reads those details, makes the payment automatically, and retries the request. The whole thing happens in milliseconds, with no human in the loop.

This isn't speculative. The HTTP 402 status code has existed since 1991, reserved for exactly this purpose. x402 finally gives it a practical implementation for the blockchain era.

What it looks like from the outside: your agent calls an API, the API says "pay me first," your agent pays, the API responds. One transaction, zero friction, zero human involvement.

The Wallet Problem

Here's the catch: for x402 to work, your agent needs a wallet. Not a wallet managed by a human who logs in to approve things — a wallet the agent can operate autonomously, within defined limits you set in advance.

This is where most attempts fall apart. Either the wallet is too custodied (a human has to approve every payment) or too open (the agent has unconstrained access to funds). Neither works for production autonomous agents.

WAIaaS is designed to solve exactly this. It's an open-source, self-hosted Wallet-as-a-Service built for AI agents. The agent gets a session token that gives it access to a wallet. You, as the owner, set policies in advance that define what the agent can and can't do. The agent operates within those boundaries autonomously.

x402 Support in WAIaaS

The x402Fetch capability is built directly into the WAIaaS SDK. It wraps a standard HTTP fetch call with automatic 402 payment handling. Your agent code doesn't need to know anything about the payment mechanics — it just calls x402Fetch instead of fetch.

Here's what that looks like in TypeScript:

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

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

// This call automatically handles 402 Payment Required responses
const response = await client.x402Fetch('https://api.some-paid-service.com/data');
const data = await response.json();

If the API returns 402, the SDK reads the payment requirements, the agent's wallet makes the payment, and the request retries — all transparently. Your agent code is the same whether the API charges or not.

The MCP integration exposes this as the x402-fetch tool, one of the 45 MCP tools available to AI agents connected through the Model Context Protocol. That means an agent running in Claude Desktop can make paid API calls without any custom code — the tool handles everything.

Policy Guardrails: How You Stay in Control

Giving an agent a wallet doesn't mean giving it unlimited access. WAIaaS has a policy engine with 21 policy types and 4 security tiers — and for x402 specifically, there's a dedicated policy type: X402_ALLOWED_DOMAINS.

This is a domain whitelist. You specify which domains the agent is allowed to make automatic payments to. Anything not on the list gets blocked. Combined with SPENDING_LIMIT policies, you can define exactly how much the agent can spend per transaction, per day, and per month — without touching a line of agent 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": "X402_ALLOWED_DOMAINS",
    "rules": {
      "domains": ["api.example.com", "*.openai.com"]
    }
  }'

And alongside that, a spending limit to cap what the agent can spend:

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

The four security tiers work like this: transactions below instant_max_usd execute immediately with no notification. Below notify_max_usd, they execute but you get a notification. Below delay_max_usd, they're queued for delay_seconds before executing — giving you a cancellation window. Above that threshold, they require explicit human approval via WalletConnect or Telegram.

For x402 micropayments — the $0.001 to $0.10 range where most API calls live — the INSTANT tier means the agent pays without any friction. For larger unusual payments, the system escalates automatically.

Policies follow a default-deny model: if ALLOWED_TOKENS or CONTRACT_WHITELIST policies aren't configured, transactions are blocked. This means you can't accidentally leave an agent with unconstrained spending — you have to explicitly grant permissions.

The 7-Stage Pipeline Behind Every Payment

Every transaction an agent makes — including x402 payments — goes through a 7-stage pipeline: validate, auth, policy, wait, execute, confirm, and stage management. This isn't just for safety theater. It means every payment has an audit trail, every policy check is logged, and the agent can't bypass the rules even if it tries.

The dry-run API lets you simulate any transaction before it executes:

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 useful during development — you can verify that your policy configuration works the way you expect before deploying with real funds.

Setting Up an Agent Wallet in Under 5 Minutes

Here's the minimal path from zero to a wallet-equipped agent that can make x402 payments:

Step 1: Install and start WAIaaS

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

Step 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": "agent-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>"}'

The session response includes a wai_sess_... token. That's what your agent uses.

Step 3: Set x402 policy

Create an X402_ALLOWED_DOMAINS policy and a SPENDING_LIMIT policy as shown above. The agent can only make x402 payments to domains you've whitelisted, within the spending limits you've set.

Step 4: Connect to Claude via MCP (optional)

waiaas mcp setup --all

This auto-registers your wallet with Claude Desktop. The x402-fetch tool becomes available immediately — Claude can make paid API calls on your behalf without any additional configuration.

Step 5: Fund the wallet and run your agent

Send funds to the wallet address (get it with waiaas wallet info), then run your agent with the session token in the environment:

WAIAAS_SESSION_TOKEN=wai_sess_... node my-agent.js

The Bigger Picture: Machine-to-Machine Economies

x402 is compelling on its own, but it becomes genuinely interesting when you think about where it leads. Right now, APIs are sold to developers. Developers pay monthly fees, manage API keys, handle billing — all human-in-the-loop activity.

x402 shifts this model. APIs can be sold to agents. An agent can discover a data source, evaluate its pricing, pay for access, and use the data — all without human involvement. The billing granularity drops from monthly subscriptions to per-request micropayments. The relationship isn't developer-to-vendor anymore, it's agent-to-service.

WAIaaS supports this with 18 networks across Solana and EVM chains (fact NET-01). An agent operating on Solana can make x402 payments in SOL or USDC. An agent on Ethereum or a Layer 2 can do the same in ETH or stablecoins. The wallet infrastructure handles the chain-specific details — your agent code doesn't need to know.

The 3-layer security model (session auth → time delay + approval → monitoring + kill switch) means this isn't a system you deploy and lose control of. You can monitor what your agent is spending, set kill switches, and recover access through owner authentication (SIWS/SIWE signature). The agent operates autonomously within the boundaries you set — not because you trust it blindly, but because you've defined exactly what "within bounds" means.

What This Looks Like at Scale

Imagine a research agent that needs to pull data from a dozen different sources during a multi-hour analysis run. Some sources are free. Some charge per query. Some have tiered pricing. Today, you either pre-purchase access to all of them (wasteful) or the agent has to stop and wait for human approval (slow).

With x402 and WAIaaS, the agent queries each source. Free sources respond normally. Paid sources return 402. The wallet pays automatically, within your pre-configured domain whitelist and spending limits. The analysis runs uninterrupted. You get a notification log of what was spent. If anything looks wrong, the policy engine already blocked it.

This is infrastructure for agents that do real work in the real economy. Not a demo, not a proof of concept — it runs today, on the chains that matter, with the security guarantees you need to actually trust an autonomous system with funds.

What's Next

The x402 protocol support in WAIaaS is one piece of a larger picture around autonomous agent infrastructure — if you want to understand how the policy engine works in depth or how DeFi actions fit into an agent's capabilities, the GitHub repository has the full source and documentation. The OpenAPI reference at /reference is also worth exploring once you have the daemon running — it's interactive and covers all 39 API route modules.

If you're building agents that need to participate in the economy rather than just simulate it, the place to start is the official site at https://waiaas.ai and the repository at https://github.com/waiaas/WAIaaS. Both are live, both reflect real working software, and the setup genuinely does take under five minutes.

APPROVE_TIER_OVERRIDE: Emergency Controls for High-Stakes DeFi Operations

Wallet Guy — Mon, 20 Jul 2026 15:19:59 +0000

APPROVE_TIER_OVERRIDE: Emergency Controls for High-Stakes DeFi Operations

Giving an AI agent a wallet without guardrails is like giving a toddler a credit card — the intentions might be fine, but the outcomes can be catastrophic. If you're building systems where AI agents execute DeFi operations autonomously, the question isn't whether something will go wrong, it's whether your security architecture will contain the damage when it does. WAIaaS is an open-source, self-hosted Wallet-as-a-Service built specifically for this problem, and this post walks through exactly how its layered security model — and specifically the APPROVE_TIER_OVERRIDE policy — keeps high-stakes DeFi operations under human control.

Why This Matters More Than You Think

Autonomous AI agents executing DeFi trades, managing lending positions, or running arbitrage strategies represent a genuinely new threat surface. The agent doesn't get tired, doesn't second-guess itself, and won't pause before submitting a transaction that wipes out a position. Traditional wallet security was designed for humans who read confirmations. It was not designed for a loop that fires 200 transactions per hour.

The stakes compound quickly. A misconfigured leverage position, a swap against a manipulated price feed, an approval transaction that grants unlimited spend to a malicious contract — any of these can drain a wallet in seconds. If your security model is "we trust the agent's logic," you're one bug away from a very bad day.

The honest answer to this problem is layered, explicit security that does not trust the agent by default. That's the design philosophy behind WAIaaS.

The 3-Layer Security Model

WAIaaS structures security as three concentric layers, each independent of the others:

Layer 1 — Session Authentication: Every agent gets a session token (wai_sess_...) with configurable TTL, maximum renewals, and an absolute lifetime. The agent can only operate within its session scope.

Layer 2 — Policy Engine: A 21-type policy engine with default-deny enforcement. Transactions are blocked unless explicitly allowed. This is where APPROVE_TIER_OVERRIDE lives.

Layer 3 — Monitoring and Kill Switch: Incoming transaction monitoring with real-time notifications and owner-controlled approval channels via WalletConnect, Telegram, or push relay.

Three separate authentication methods map to three roles: masterAuth (Argon2id) for the system administrator who creates wallets and configures policies, sessionAuth (JWT HS256) for the AI agent, and ownerAuth (SIWS/SIWE signatures) for the fund owner who approves transactions. The agent never holds the master password. The owner's approval is cryptographic, not just a button click.

Default-Deny: The Foundation

Before getting into APPROVE_TIER_OVERRIDE specifically, you need to understand the default-deny posture. In WAIaaS, if you create a wallet and give an agent a session token without configuring policies, the agent cannot transfer tokens that aren't on an explicit whitelist, and cannot call contracts that aren't on an explicit whitelist.

This is not a "warn on suspicious activity" model. It's a hard block. The error response is unambiguous:

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

To allow token transfers, you configure an ALLOWED_TOKENS policy:

curl -X POST http://localhost:3100/v1/policies \
  -H 'Content-Type: application/json' \
  -H 'X-Master-Password: <password>' \
  -d '{
    "walletId": "<wallet-uuid>",
    "type": "ALLOWED_TOKENS",
    "rules": {
      "tokens": [
        {
          "address": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
          "symbol": "USDC",
          "chain": "solana"
        }
      ]
    }
  }'

Your agent can't touch tokens you haven't explicitly allowed. That's the foundation everything else builds on.

The 4 Security Tiers

The SPENDING_LIMIT policy assigns every transaction to one of four tiers based on its USD value:

INSTANT — Execute immediately, no notification
NOTIFY — Execute immediately, notify the owner
DELAY — Queue the transaction for a configurable number of seconds, then execute (cancellable during the window)
APPROVAL — Require explicit human approval before execution

Here's what a realistic SPENDING_LIMIT configuration looks like for a DeFi trading agent:

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 configuration: swaps under $100 execute immediately, swaps between $100–$500 execute but you get notified, swaps between $500–$2,000 are queued for 15 minutes (giving you a window to cancel), and anything above $2,000 requires your explicit approval. The daily limit caps total exposure regardless of individual transaction size.

The tier assignment is deterministic: amount <= instant_max → INSTANT, <= notify_max → NOTIFY, <= delay_max → DELAY, > delay_max → APPROVAL.

APPROVE_TIER_OVERRIDE: Why It Exists

Here's the problem APPROVE_TIER_OVERRIDE solves. Your SPENDING_LIMIT policy handles regular transfers based on their USD value. But APPROVE transactions — token approvals — don't transfer funds. They grant a smart contract permission to transfer funds later, potentially without limit.

A $0 approval transaction could grant an unlimited spend allowance to a DEX router. Under a pure spending-limit model, that $0 transaction sails through as INSTANT because it moves no funds. But the downstream risk is enormous.

APPROVE_TIER_OVERRIDE forces token approval transactions into a specific security tier regardless of their dollar value. You can force every approval operation to require human sign-off, every time, no matter how small the nominal value appears to the spending limit check.

This is the right model for high-stakes DeFi operations. You want your agent to execute swaps autonomously within limits — that's the whole point — but you want to personally review every new approval that grants a contract access to your tokens.

The complementary policy APPROVE_AMOUNT_LIMIT lets you block unlimited approvals entirely, ensuring your agent only grants bounded allowances even when approvals are permitted.

Simulate Before You Execute

Before any transaction reaches the policy engine in production, you can run it through the simulation API. The dryRun flag submits the full transaction payload through the 7-stage pipeline — validation, auth, policy check, gas condition evaluation — 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
  }'

This is particularly useful when you're configuring policies for a new DeFi strategy. Run representative transactions through dry-run first to verify they land in the tier you expect before your agent starts operating in production. A transaction you thought would be NOTIFY hitting APPROVAL in production because you miscalculated the USD value is an annoying surprise. Catching it in dry-run is just good engineering.

Human Approval Channels

When a transaction requires APPROVAL tier, the owner receives a notification and must cryptographically approve it. The approval uses ownerAuth — the owner signs a message with their private key (ed25519 for Solana, secp256k1 for EVM):

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

WAIaaS supports three signing channels for delivering these approval requests: push relay, Telegram, and WalletConnect. The WalletConnect integration means the owner can approve transactions from any WalletConnect-compatible wallet app — a familiar interface for anyone in the DeFi space.

For DeFi operations that involve high-value positions, perpetual futures, or new contract interactions, the approval channel gives you a hard checkpoint that can't be bypassed by agent logic.

Policies Purpose-Built for DeFi

Beyond the general-purpose policies, WAIaaS includes several policy types designed specifically for DeFi risk management:

LENDING_LTV_LIMIT — Caps the loan-to-value ratio for lending positions. Your agent cannot open a position that would put your collateral at immediate liquidation risk.
LENDING_ASSET_WHITELIST — Restricts which assets the agent can use as collateral or borrow.
PERP_MAX_LEVERAGE — Hard cap on perpetual futures leverage. If you've integrated Hyperliquid for perp trading, this prevents the agent from opening positions at 50x when you intended 5x.
PERP_MAX_POSITION_USD — Maximum single position size in USD.
PERP_ALLOWED_MARKETS — Whitelist of permitted perpetual markets.
VENUE_WHITELIST — Restricts which trading venues the agent can interact with.
ACTION_CATEGORY_LIMIT — Caps DeFi action categories (lending, staking, swapping) independently.

These aren't bolt-ons. They're part of the same policy engine that handles spending limits and token whitelists, applied through the same default-deny framework, enforced in the same transaction pipeline.

Standing Up the Full Stack

The fastest path from zero to a secured DeFi agent runs 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

Or if you prefer Docker:

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

The Docker image runs as a non-root user (UID 1001), exposes only 127.0.0.1:3100 by default, and supports Docker Secrets for production secret management. For production deployments, use the secrets overlay:

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

Once the daemon is running, create a wallet, attach policies, generate a session token for your agent, and test your policy configuration with dry-run before going live. The OpenAPI 3.0 spec is available at http://127.0.0.1:3100/doc and the interactive Scalar reference UI at http://127.0.0.1:3100/reference — useful for exploring the full policy configuration options.

Using the TypeScript SDK in Your Agent

If you're building the agent itself rather than just the infrastructure, the TypeScript SDK gives you typed access to the full API:

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'],
});

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}`);
    // POLICY_DENIED surfaces here — handle gracefully, not with a retry loop
  }
}

The SDK is zero external dependencies. A POLICY_DENIED error with retryable: false means exactly that — the policy blocked it and retrying won't help. Your agent should surface that to a monitoring system or log it, not hammer the API hoping the policy changes.

The Security Architecture in One Mental Model

If you want a single frame for how this all fits together: WAIaaS assumes the agent will eventually do something wrong — a bug, a bad inference, a manipulated input — and builds the security architecture around containing that failure rather than preventing it through correctness.

The session token limits the blast radius to a single wallet with a configured scope. The policy engine's default-deny posture means misconfigured agent permissions fail closed rather than open. The spending limit tiers route high-value operations through human review. APPROVE_TIER_OVERRIDE ensures approval transactions never slip through on a technicality. The 15-minute delay window gives you time to intervene before a queued transaction executes.

None of these layers individually make your agent secure. Together, they mean a compromised or buggy agent has a very hard time causing catastrophic damage.

What's Next

The full policy reference, including all 21 policy types and their configuration schemas, is available in the interactive API docs at http://127.0.0.1:3100/reference once your daemon is running. For MCP-based agent integration with Claude Desktop, the waiaas mcp setup --all command handles the configuration automatically — your agent gets access to 45 MCP tools including DeFi positions, transaction simulation, and approval workflows without writing integration code.

The codebase is open source and self-hosted — you run it, you control the keys, and the policy engine is yours to inspect and extend.

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

Localhost-Only Security: Why Self-Hosted AI Wallets Should Never Bind to 0.0.0.0

Wallet Guy — Mon, 20 Jul 2026 09:39:16 +0000

Localhost-Only Security: Why Self-Hosted AI Wallets Should Never Bind to 0.0.0.0

Self-hosted AI wallets give you complete control over your keys and infrastructure — but that control means nothing if your wallet daemon is accidentally exposed to the world. If you're running an AI agent that holds real funds, the network binding of your wallet service is the first line of defense, and getting it wrong is the kind of mistake you only make once.

The Problem With "Just Open It Up"

When developers spin up a new service, there's a tempting shortcut: bind to 0.0.0.0 so it's reachable from anywhere. For a static site or a read-only API, this is fine. For a service that holds private keys and can authorize cryptocurrency transactions on behalf of an AI agent, it's a serious risk.

The stakes here are different from a misconfigured web server. If someone reaches your wallet daemon unexpectedly — from another container, another machine on your LAN, or through a misconfigured firewall — they're not reading your blog posts. They're potentially talking to an API that can sign and broadcast transactions. The damage is irreversible. On-chain transactions don't have a "dispute with your bank" option.

This is why self-hosting your AI wallet infrastructure isn't just about privacy and sovereignty (though those matter too). It's about applying the correct security defaults for what the service actually does.

Why Self-Hosting in the First Place?

Before getting into the technical details, it's worth grounding the philosophy here.

When you use a hosted Wallet-as-a-Service, someone else holds your keys or at minimum has the infrastructure-level ability to inspect, delay, or block your agent's transactions. You're trusting a third party's uptime, their security practices, their API rate limits, and their business continuity. For many use cases, that trade-off is fine. But for developers who care about sovereignty — running their own infrastructure, keeping their own keys, knowing exactly what software is executing — the hosted model has a ceiling.

Self-hosting an AI wallet is roughly the crypto equivalent of running your own email server. It was once seen as unnecessarily complicated. Now, with containers making it a one-command operation, the calculus has changed. You get full control over where your data lives, what network it's exposed to, and who can reach it.

WAIaaS is an open-source self-hosted Wallet-as-a-Service built specifically for AI agents. It runs as a local daemon, exposes a REST API over HTTP, and is designed from the start to live on 127.0.0.1 — not the public internet.

The Default: `127.0.0.1:3100`

The WAIaaS Docker Compose configuration binds to 127.0.0.1:3100:3100 by default. That colon-separated IP address at the front is doing critical work. It means the port is only reachable from the local machine — not from your LAN, not from another Docker network unless you explicitly configure it, and certainly not from the internet.

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

You'll notice WAIAAS_DAEMON_HOSTNAME=0.0.0.0 in the environment. This is not a contradiction — it means the daemon inside the container listens on all interfaces within the container's network namespace. The binding restriction (127.0.0.1:3100) is enforced by Docker at the host level. The process inside the container doesn't need to know it's isolated; Docker handles the network boundary.

This is the correct pattern: let the container runtime enforce network exposure, not hope the application gets it right.

Three Auth Layers Before Any Transaction Moves

Network isolation is layer zero. WAIaaS also enforces a 3-layer authentication model that separates concerns between the system administrator, the fund owner, and the AI agent itself.

# masterAuth — system administrator (wallet creation, session management, policies)
-H "X-Master-Password: my-secret-password"

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

# ownerAuth — fund owner (transaction approval, kill switch recovery)
-H "X-Owner-Signature: <ed25519-or-secp256k1-signature>"
-H "X-Owner-Message: <signed-message>"

The AI agent only ever holds a session token — a JWT that can be scoped, time-limited, and revoked. It never touches the master password. The master password (hashed with Argon2id) is only used for administrative operations: creating wallets, managing sessions, configuring policies. The fund owner, who holds an ed25519 or secp256k1 keypair, is the only one who can approve transactions that exceed the policy thresholds or recover from a compromised session.

Even if an attacker somehow reaches the API on localhost (which requires they already have code execution on your machine, at which point you have bigger problems), they still need to know which token or password authorizes which operation. The separation of roles limits blast radius significantly.

Production Secrets Without Environment Variables in Plain Text

For production deployments, WAIaaS supports Docker Secrets — a mechanism where secret values live in files rather than environment variables, reducing the risk of accidental exposure through docker inspect, log scraping, or process listings.

# 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

The docker-compose.secrets.yml overlay patches in the secret mounts without changing your base configuration. This means your base docker-compose.yml stays clean and can be committed to version control, while the secrets file stays out of it.

Auto-Provision for First Boot

If you're spinning up WAIaaS for the first time and don't want to manually set a master password, the auto-provision flag generates one for you and writes it to a recovery key file:

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 recovery key approach is practical: you get a running system immediately, and you can harden the password later using waiaas set-master from the CLI. The important thing is to delete the recovery key file once you've stored the password somewhere safe.

The Policy Engine as Your Second Network

Even after you've locked down network access and authentication, there's still the question of what the AI agent is allowed to do once it has a valid session token. This is where WAIaaS's policy engine becomes part of the security architecture rather than just a feature.

The policy engine enforces 21 policy types with 4 security tiers. Default-deny is the enforced behavior: if ALLOWED_TOKENS is not configured, token transfers are blocked. If CONTRACT_WHITELIST is not configured, contract calls are blocked.

Here's a policy that limits spending with tiered escalation:

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

The four tiers — INSTANT, NOTIFY, DELAY, and APPROVAL — mean that small transactions go through immediately, mid-range transactions send a notification to the owner, larger ones queue for a time delay (and are cancellable during that window), and anything above the threshold requires explicit human approval. This is enforced through a 7-stage transaction pipeline.

The AI agent has no way to bypass this. The pipeline enforces policy at the server level, not at the client level. The agent submits a transaction, and the pipeline decides what happens next based on the configured policies.

A Minimal Self-Hosted Setup in Five Steps

Here's the complete path from zero to a running, locally-bound AI wallet daemon:

Step 1: Install the CLI

npm install -g @waiaas/cli

Step 2: Initialize and start

waiaas init --auto-provision
waiaas start

Step 3: Create wallets and sessions in one command

waiaas quickset --mode mainnet

Step 4: Connect to your AI agent (Claude Desktop)

waiaas mcp setup --all

This auto-registers all wallets with Claude Desktop by writing the MCP configuration. The MCP server exposes 45 tools to the AI agent — everything from balance checks to DeFi actions — all proxied through your local daemon with session authentication enforced.

Step 5: Set a real master password

waiaas set-master

Once done, delete the auto-generated recovery key.

What "Your Keys, Your Server" Actually Means

Self-hosted infrastructure means the keys never leave your machine. WAIaaS runs entirely on your hardware, with data stored in a named Docker volume that only you control. There's no telemetry, no cloud sync, no third-party service that holds or proxies your keys.

The WAIaaS monorepo is a 15-package open-source codebase. The daemon, the CLI, the MCP server, the TypeScript SDK, the Python SDK, the admin UI — all of it is in the repository and auditable. If you want to know exactly what's running on your machine when you start the daemon, you can read the source.

This also means the Docker image comes from a specific, versioned registry path (ghcr.io/minhoyoo-iotrust/waiaas:latest) that you can verify. The entrypoint script handles auto-provisioning and Docker Secrets in a way you can inspect before running.

The daemon also runs as a non-root user (UID 1001) inside the container. This is a small detail with meaningful consequences: even if a bug in the daemon led to container escape, the process wouldn't have root privileges on the host. Defense in depth applies at every layer.

What's Next

If you want to go deeper on the policy engine and understand how to configure the full set of 21 policy types for your specific use case, the policy configuration documentation is the right next step. For teams who want to integrate WAIaaS into an existing AI agent framework rather than Claude Desktop, the OpenClaw plugin and the TypeScript or Python SDK are worth looking at — the SDK has over 40 methods and zero external dependencies.

The full source is at https://github.com/minhoyoo-iotrust/WAIaaS and the official site with documentation is at https://waiaas.ai. If you're running this in a homelab or a privacy-focused setup, the GitHub issues and discussions are the right place to share what you're building and ask questions.

The API Economy Goes Autonomous: When AI Agents Pay Their Own Bills

Wallet Guy — Sun, 19 Jul 2026 14:34:21 +0000

The API Economy Goes Autonomous: When AI Agents Pay Their Own Bills

AI agents will need to pay for compute, data, and API calls — and right now, almost none of the infrastructure to support that exists. We talk endlessly about autonomous agents that research, trade, and act on our behalf, but we hand-wave past a fundamental question: when an agent needs to pay for something, who actually pays, and how? The answer today is usually "a human does it manually," which quietly defeats the entire point of autonomy.

Why This Gap Matters More Than It Seems

Think about what a genuinely autonomous agent needs to do its job. It calls APIs to fetch data. It pays for compute time. It moves funds between protocols based on market conditions. It settles microtransactions in milliseconds. Every one of those operations has a cost, and every cost requires a payment method.

The current workarounds are either custodial (a company holds funds on the agent's behalf, reintroducing the human intermediary) or fragile (hardcoded private keys with no spending controls, which is how you get drained wallets at 3am). Neither is acceptable infrastructure for agents operating at any real scale or value.

The missing layer is autonomous wallet infrastructure — something an agent can operate independently, with guardrails that protect against mistakes and malicious behavior, without requiring a human to approve every transaction.

That infrastructure exists today. Let's look at how it actually works.

The Architecture: Wallets That Agents Can Drive

WAIaaS (Wallet-as-a-Service for AI agents) is an open-source, self-hosted daemon that gives agents structured access to crypto wallets across 18 networks, with a policy engine that lets you define exactly what the agent can and cannot do.

The core idea is a three-role authentication model that cleanly separates concerns:

masterAuth (Argon2id) — the system administrator who creates wallets and sets policies
sessionAuth (JWT HS256) — the AI agent, which operates with a scoped session token
ownerAuth (SIWS/SIWE signatures) — the fund owner, who can approve high-value transactions or kill the session entirely

The agent only ever sees a session token. It can't create new wallets, change policies, or override spending limits. Those are administrator and owner concerns. The agent just operates within the sandbox you've defined.

This sounds simple, but it solves a genuinely hard problem: how do you give an agent enough autonomy to be useful while retaining the ability to constrain and audit everything it does?

The x402 Protocol: Machines That Pay for What They Use

The most forward-looking piece of this is x402 HTTP payment support. The x402 protocol extends standard HTTP with a payment flow: an API returns a 402 Payment Required response with payment details, the client pays, and retries the request with proof of payment.

For humans, this is awkward. For agents, it's natural. An agent calling a data API that costs $0.001 per request should just... pay for it. No billing account setup, no OAuth dance, no human approving a subscription. The agent pays directly, in real time, for what it uses.

WAIaaS exposes this as a single method in the 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 automatically handles 402 responses and pays inline
const response = await client.x402Fetch('https://api.someservice.com/data/premium-endpoint');
const data = await response.json();

The agent doesn't know or care that a payment happened. It made an HTTP request and got data back. The wallet handled the payment. You can whitelist domains via the X402_ALLOWED_DOMAINS policy, so the agent can only auto-pay approved services — not arbitrary endpoints it decides to call.

This is the economic model for agentic compute: pay-per-call, with the payment infrastructure embedded in the agent's toolkit rather than managed by a billing dashboard somewhere.

The Policy Engine: Guardrails That Actually Work

Giving an agent a wallet with no constraints is not a product — it's a liability. The policy engine is what makes autonomous wallets safe enough to actually deploy.

WAIaaS ships 21 policy types across 4 security tiers: INSTANT (execute immediately), NOTIFY (execute and notify the owner), DELAY (queue for a configurable number of seconds, cancellable), and APPROVAL (require explicit human sign-off via WalletConnect or a notification channel).

A realistic policy setup for a trading agent looks something like this:

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, transactions under $100 execute instantly. Between $100 and $500, they execute but you get a notification. Between $500 and $2,000, the transaction is queued for 15 minutes — enough time to cancel it if something looks wrong. Anything above $2,000 requires your explicit approval.

The policy engine enforces default-deny for token transfers and contract interactions: if you haven't explicitly whitelisted a token or contract, the transaction is blocked. An agent can't start sending funds to new addresses it discovers on its own unless you've allowed it.

Other policy types cover perpetual futures trading (max leverage, max position size, allowed markets), DeFi lending (max LTV ratio, asset whitelist), ERC-8004 onchain reputation thresholds, and more — 21 types in total, designed for the specific risk surface of autonomous financial agents.

DeFi Operations: What Agents Can Actually Do

Once you have the session token and policies in place, an agent can execute across 15 DeFi protocol integrations. On Solana, that includes Jupiter swaps, Kamino lending, and Jito staking. On EVM chains, it includes Aave v3, Lido staking, Pendle, Hyperliquid perpetuals, and Polymarket prediction markets, among others. Cross-chain operations run through LI.FI and Across.

A Jupiter swap from an agent 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 agent sends one API call. The daemon handles route optimization, transaction construction, signing, and submission. The policy engine checks the transaction against all applicable policies before anything is signed. A 7-stage pipeline handles validation, authorization, policy evaluation, optional time delays, execution, and confirmation.

Before execution, agents can also simulate: add "dryRun": true to any transaction payload to get back exactly what would happen — fees, expected output, policy evaluation results — without committing to the chain. This matters for agents making decisions based on expected costs.

Connecting Claude (or Any AI) Directly

For agents running inside Claude or other LLM frameworks, WAIaaS ships 45 MCP tools covering wallet operations, transactions, DeFi positions, NFTs, and x402 payments. Setup is one command:

waiaas mcp setup --all

That registers all wallets with Claude Desktop automatically. After that, Claude can check balances, execute swaps, query DeFi positions, and handle x402 payments as native tool calls — no custom integration code required.

The Claude Desktop configuration looks like this if you're setting it up manually:

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

For multi-agent setups where you want different agents with different permissions, you configure one MCP server per wallet — each with its own session token and associated policies. A trading agent gets broad DeFi permissions with aggressive spending limits. A data-fetching agent gets x402 domain whitelist only. Permissions are scoped at the wallet and session level, not globally.

Deploying the Infrastructure

The daemon runs as a self-hosted Docker container, which means you control the keys and the data — nothing is custodied by a third party.

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

Auto-provision generates a master password on first start and writes it to a recovery key file. After initial setup, you can harden the password and delete the recovery file. The container runs as a non-root user (UID 1001), includes a healthcheck, and supports Watchtower for automatic updates.

For production, Docker Secrets via the secrets overlay file keeps credentials out 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 CLI gives you 20 commands for managing the daemon, wallets, sessions, backups, and MCP configuration without touching the REST API directly:

npm install -g @waiaas/cli
waiaas init
waiaas start
waiaas quickset --mode mainnet   # Creates wallets + MCP sessions in one step

The Broader Picture

What we're describing is economic infrastructure for the agentic layer — the missing piece between "AI that can reason about financial decisions" and "AI that can actually execute them safely."

The x402 protocol is particularly significant here. Today, API monetization assumes human billing accounts. As agents become the primary consumers of certain APIs — data feeds, inference endpoints, specialized tools — that assumption breaks down. Pay-per-call, agent-native payment infrastructure is the natural replacement. An agent that can pay for exactly what it consumes, with no subscription overhead, no billing reconciliation, and no human in the loop for routine payments, is genuinely more economically efficient than the alternative.

The guardrails matter just as much as the capability. An autonomous agent with unconstrained wallet access is not a product anyone should ship. A policy engine that enforces spending limits, whitelists, time delays, and human approval thresholds at the transaction level — with 21 policy types covering the specific risk surface of DeFi and API payments — is what makes autonomous wallets deployable in practice.

This infrastructure exists today, it's open source, and it runs on your own hardware.

Quick Start: Running Your First Autonomous Agent Wallet

Getting a wallet running that an agent can use takes about five minutes:

Install the CLI — npm install -g @waiaas/cli
Initialize and start — waiaas init && waiaas start
Create wallets and sessions — waiaas quickset --mode mainnet
Set spending policy — Use the REST API or Admin UI to configure SPENDING_LIMIT and ALLOWED_TOKENS
Connect to Claude — waiaas mcp setup --all, paste the config into Claude Desktop

The agent is now operating with real wallet access, bounded by the policies you've defined, with full transaction history and audit trail.

What's Next

The open-source codebase, API reference, and Docker images are all available now. If you're building agents that need to participate in the economy — paying for APIs, executing DeFi strategies, handling microtransactions — this is the infrastructure layer worth understanding.

Explore the project on GitHub at https://github.com/minhoyoo-iotrust/WAIaaS and find documentation, deployment guides, and SDK references at https://waiaas.ai.

Cross-Chain Arbitrage with LI.FI: When Your Bot Finds Profit Across Networks

Wallet Guy — Sun, 19 Jul 2026 08:37:57 +0000

Cross-chain arbitrage bots live and die by execution speed — your bot spotted a price discrepancy between Ethereum and Solana, but bridging, swapping, and hedging across networks typically means juggling multiple SDKs, fragile key management, and zero built-in risk controls. That's the infrastructure tax that eats your edge before you even get to the trade.

The Real Cost of Arbitrage Infrastructure

Most arb bot write-ups focus on the strategy: find the spread, calculate profitability, execute. What they gloss over is the plumbing. You need to:

Hold and sign transactions on multiple chains simultaneously
Bridge assets without losing your shirt on gas
Apply position limits so a runaway bot doesn't drain your treasury
Know whether it's even worth executing given current gas prices

Every piece of that is custom code you have to write, audit, and maintain. A bug in your key management or a misconfigured gas estimate doesn't cost you a trade — it costs you the wallet. WAIaaS is a self-hosted Wallet-as-a-Service that bundles all of this into a single daemon with a REST API, so you can focus on your strategy instead of your signing logic.

What WAIaaS Gives a Trading Bot Builder

Let's be concrete. WAIaaS ships with 15 DeFi protocol providers integrated: aave-v3, across, dcent-swap, drift, erc8004, hyperliquid, jito-staking, jupiter-swap, kamino, lido-staking, lifi, pendle, polymarket, xrpl-dex, and zerox-swap. For a cross-chain arb system, the immediately relevant ones are:

LI.FI — cross-chain bridging and swapping aggregation
Across — fast cross-chain bridging
Jupiter — Solana swap aggregation
Drift — Solana perpetuals for hedging
Hyperliquid — perpetual futures, spot trading, and sub-accounts
0x Swap — EVM DEX aggregation

One daemon, one session token, all of these reachable via REST. Your bot doesn't need separate SDK integrations for each protocol.

Beyond protocol access, the features that matter for automated trading are:

Gas conditional execution. Transactions execute only when the gas price meets a configured threshold. Your bot doesn't have to implement its own gas oracle and gating logic — WAIaaS handles it at the pipeline stage before the transaction is even submitted.

A 7-stage transaction pipeline that handles validation, authentication, policy enforcement, waiting (for gas conditions or time delays), execution, and confirmation. You get structured status responses at each stage.

21 policy types with 4 security tiers (INSTANT, NOTIFY, DELAY, APPROVAL). For a trading bot, the critical ones are SPENDING_LIMIT, ALLOWED_TOKENS, CONTRACT_WHITELIST, APPROVED_SPENDERS, PERP_MAX_LEVERAGE, PERP_MAX_POSITION_USD, PERP_ALLOWED_MARKETS, and VENUE_WHITELIST. These are your circuit breakers — they run server-side so a strategy bug can't bypass them.

Dry-run / simulation API so you can validate transaction structure and policy compliance before committing.

Setting Up the Daemon

# Docker — fastest path to a running 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

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

The daemon binds to 127.0.0.1:3100 by default — keep it off the public internet. For a production deployment, use the secrets overlay:

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

Creating Wallets for Your Arb System

A cross-chain arb bot typically needs at least two wallets: one on EVM (for bridging out via LI.FI, trading via 0x) and one on Solana (for Jupiter swaps and Drift hedges). Create them with masterAuth:

# EVM 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-evm", "chain": "evm", "environment": "mainnet"}'

# Solana 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-solana", "chain": "solana", "environment": "mainnet"}'

Then create a session token for each wallet. Your bot uses session tokens — the master password never leaves your ops environment:

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": "<solana-wallet-uuid>"}'

Store the returned session token as WAIAAS_SESSION_TOKEN in your bot's environment.

The Trade Execution Flow

Here's the cross-chain arb sequence your bot would execute:

Step 1: Check balance before committing

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

Step 2: Simulate the swap before execution

Before spending gas on a real transaction, validate 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
  }'

The dry-run runs the full pipeline including policy checks — so if your SPENDING_LIMIT policy would block this trade, you find out now, not after the gas is spent.

Step 3: Execute the swap on Jupiter (Solana leg)

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

Step 4: Bridge via LI.FI (EVM leg)

Your EVM session token hits the lifi action provider directly. Same pattern — POST to /v1/actions/lifi/<action> with the bridge parameters.

Step 5: Hedge on Drift or Hyperliquid

The Hyperliquid provider supports perpetual futures, spot trading, and sub-accounts. If your arb strategy requires a delta-neutral hedge, it's the same API surface — POST to /v1/actions/hyperliquid/<action>.

Policy Configuration for a Trading Bot

This is where WAIaaS earns its keep. A runaway bot is an existential risk. Configure your circuit breakers before you go live.

# Set a spending limit with tiered approval
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
    }
  }'

The 4-tier logic: transactions under $100 execute immediately (INSTANT), $100–$500 execute and notify you (NOTIFY), $500–$2000 queue for 15 minutes then execute (DELAY, cancellable), and anything over $2000 requires your explicit approval (APPROVAL). This is your kill switch without having to write kill switch code.

For a trading bot you also want:

PERP_MAX_LEVERAGE — cap leverage on Hyperliquid or Drift positions
PERP_MAX_POSITION_USD — absolute position size limit
VENUE_WHITELIST — only trade on protocols you've explicitly approved
ALLOWED_TOKENS — token transfer whitelist (default-deny means if you don't list USDC, the bot cannot send USDC, period)
CONTRACT_WHITELIST — same default-deny for contract calls

Default-deny is the right default for a trading bot. If you don't explicitly whitelist a contract, the bot cannot call it. A compromised strategy or a dependency with a bug cannot drain to an unexpected address.

TypeScript SDK for Tighter Bot Integration

If your bot is TypeScript-based, skip the curl layer and use the SDK directly:

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));
}

Error handling is typed — WAIaaSError gives you a code field (INSUFFICIENT_BALANCE, POLICY_DENIED, TOKEN_EXPIRED) that your bot can branch on without string-matching error messages:

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

POLICY_DENIED means your circuit breaker fired. Log it, alert, and halt — don't retry.

Quick Start for Trading Bot Builders

Run 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

Create wallets and session tokens for each chain your strategy touches (EVM, Solana)
Configure policies before going live: SPENDING_LIMIT, ALLOWED_TOKENS, CONTRACT_WHITELIST, PERP_MAX_LEVERAGE at minimum
Dry-run your first trade: add "dryRun": true to any transaction request and validate it clears policy
Install the SDK (npm install @waiaas/sdk) and wire your strategy to the session token — your signing and gas logic is done

What's Next

The OpenAPI 3.0 spec is available at http://127.0.0.1:3100/doc and the interactive Scalar API reference at http://127.0.0.1:3100/reference — every endpoint, parameter, and response schema is documented there, which makes it straightforward to generate a client in whatever language your bot runs in. The 39 REST API route modules cover everything from batch transactions to ERC-4337 UserOps if your strategy needs account abstraction and gasless execution.

Build your strategy, not your wallet infrastructure. The code is at github.com/minhoyoo-iotrust/WAIaaS and the project site is at waiaas.ai.

NOTIFY Tier Policies: Silent Monitoring for Your Trading Bot's Risky Moves

Wallet Guy — Sat, 18 Jul 2026 14:24:01 +0000

NOTIFY Tier Policies: Silent Monitoring for Your Trading Bot's Risky Moves

Your trading bot spotted the opportunity — but does your wallet infrastructure know when to let it run and when to quietly flag a move for review? For developers building automated trading bots, arbitrage systems, or algorithmic strategies, the challenge isn't just execution speed. It's knowing which trades should fire instantly, which ones deserve a second look, and which ones should never happen without a human in the loop. WAIaaS's NOTIFY tier policy gives you exactly that middle layer: transactions execute immediately, but you get notified in real time.

The Problem With All-or-Nothing Risk Controls

Most wallet setups for trading bots are binary. Either the bot has full autonomy — which is terrifying at 3am when something misbehaves — or you've locked everything down so tightly that the bot misses opportunities while waiting for manual approval. Neither extreme is workable for serious algo trading.

What you actually want is graduated control. Small, routine trades? Fire instantly, no noise. A swap that's 10x your usual size? Execute it, but ping me right now so I can watch the position. An attempted transfer well above any reasonable threshold? Stop it cold and demand explicit approval before a single satoshi moves.

This is exactly what WAIaaS's 4-tier policy engine is designed for, and the NOTIFY tier is the unsung workhorse of the system.

How the 4-Tier Security Model Works

WAIaaS enforces a SPENDING_LIMIT policy with four tiers that map to transaction value:

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

The tier is determined automatically based on the transaction amount versus your configured thresholds. Here's what a realistic trading bot policy looks like:

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 configuration:

A $8 arbitrage fee payment → INSTANT (fires immediately, zero noise)
A $75 SOL-to-USDC swap on Jupiter → NOTIFY (executes immediately, you get pinged)
A $600 position open on Drift → DELAY (queued for 5 minutes, cancellable)
Anything above $1,000 → APPROVAL (hard stop, requires your explicit sign-off)

The NOTIFY tier is your surveillance layer. Your bot keeps running at full speed, but you have eyes on every move that matters.

Why NOTIFY Matters More Than You Think

When you're running an arb bot or an algorithmic strategy across multiple protocols, unusual transaction sizes are your earliest signal that something is wrong. Maybe your position sizing logic has a bug. Maybe a price oracle fed in a bad value. Maybe someone is replaying a transaction.

The NOTIFY tier catches these situations without interrupting execution. The transaction still goes through — you're not adding latency to your hot path — but you get an immediate alert so you can intervene before the next trade compounds the problem.

This is meaningfully different from the DELAY tier. With DELAY, you've added a 5-minute queue to every transaction in that bracket, which is fine for large, deliberate position changes but completely unworkable for a bot that needs to respond to market conditions in real time. NOTIFY gives you observability without the latency penalty.

The Full Policy Stack for a Trading Bot

A SPENDING_LIMIT policy handles your size-based tiers, but a production trading bot needs more layers. WAIaaS gives you 21 policy types, and several of them are specifically designed for DeFi trading scenarios.

Lock down which tokens can move:

{
  "type": "ALLOWED_TOKENS",
  "rules": {
    "tokens": [
      {
        "address": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
        "symbol": "USDC",
        "chain": "solana"
      },
      {
        "address": "So11111111111111111111111111111111111111112",
        "symbol": "SOL",
        "chain": "solana"
      }
    ]
  }
}

ALLOWED_TOKENS is default-deny. If your bot tries to transfer any token not on this list — even accidentally — the transaction is blocked before it reaches the pipeline. This is your first line of defense against logic bugs that try to touch tokens you never intended to trade.

Whitelist the contracts your bot is allowed to call:

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

Again, default-deny. Your bot can only interact with contracts you've explicitly approved. If a compromised dependency or a buggy trade router tries to call an unknown contract, it's blocked.

Cap perpetual futures leverage and position size:

{
  "type": "PERP_MAX_LEVERAGE",
  "rules": { "maxLeverage": 10 }
}

{
  "type": "PERP_MAX_POSITION_USD",
  "rules": { "maxPositionUsd": 5000 }
}

These are specifically built for strategies running on Hyperliquid or Drift, both of which are integrated as DeFi protocol providers in WAIaaS.

Restrict which markets you're allowed to trade:

{
  "type": "PERP_ALLOWED_MARKETS",
  "rules": { "markets": ["SOL-PERP", "ETH-PERP"] }
}

Executing Trades Through the Pipeline

Every transaction your bot submits goes through WAIaaS's 7-stage pipeline: validate → auth → policy → wait → execute → confirm. The policy stage is where your SPENDING_LIMIT thresholds are evaluated and tier assignment happens. If the transaction hits NOTIFY, it continues through the pipeline immediately while the notification fires asynchronously.

Here's what a typical Jupiter swap looks like from your bot's perspective:

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

Your bot sends the request. The pipeline validates the session, checks your token whitelist and contract whitelist, evaluates the USD value against your spending tiers, assigns NOTIFY if it's in that bracket, and fires the swap. The notification goes out in parallel. From your bot's perspective, this is functionally identical to an INSTANT transaction — same response time, same execution path.

If the policy engine denies the transaction instead, you get a structured error you can handle cleanly in your code:

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

Before You Execute: Dry Run Mode

For a trading bot, testing your logic against real market conditions without actually moving funds is essential. WAIaaS has a dry-run mode built directly into the transaction endpoint:

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

Add "dryRun": true to any transaction payload and WAIaaS simulates the full pipeline — including policy evaluation — without submitting anything to the network. This lets you verify that your SPENDING_LIMIT thresholds are behaving as expected and that your NOTIFY tier is triggering at the right amounts before you go live.

Setting Up the Bot Wallet

Getting a trading bot wallet running takes about five minutes:

Step 1: Install the CLI and start the daemon

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

Step 2: Create a wallet and get a session token

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

Step 3: Apply your SPENDING_LIMIT 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": 10,
      "notify_max_usd": 100,
      "delay_max_usd": 1000,
      "delay_seconds": 300,
      "daily_limit_usd": 500,
      "monthly_limit_usd": 5000
    }
  }'

Step 4: Add your token and contract whitelists (use the JSON examples above, same endpoint, same master auth)

Step 5: Start trading with the session token

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}`);

The session token is what your bot uses. The master password stays out of the hot path entirely.

Deploy with Docker for Production

When you're ready to run this in production, Docker handles the infrastructure:

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 daemon binds to 127.0.0.1:3100 by default — not exposed to the public internet. Your bot talks to it over localhost. The data volume persists your wallets, sessions, and policy configuration across container restarts.

The Protocols Your Bot Can Access

WAIaaS integrates 15 DeFi protocol providers, which means your bot can interact with a serious range of venues through a single authenticated session. On Solana: Jupiter for swaps, Drift for perpetuals, Kamino for lending, Jito for staking. Cross-chain bridging through LI.FI and Across. Prediction markets via Polymarket. Yield via Pendle. Perpetuals on Hyperliquid. All of them accessible through the same session token, all of them subject to the same policy engine.

That means your SPENDING_LIMIT policy applies uniformly whether your bot is swapping on Jupiter, opening a position on Drift, or bridging assets via LI.FI. One policy layer covers the entire surface.

What's Next

The NOTIFY tier is one piece of a larger risk management architecture. As you push more volume through your bot, you'll want to layer in RATE_LIMIT to cap transaction frequency, LENDING_LTV_LIMIT if you're using DeFi lending as part of your strategy, and PERP_ALLOWED_MARKETS to prevent any edge case from opening positions in markets you're not tracking.

The full OpenAPI spec is available at http://127.0.0.1:3100/reference once your daemon is running — interactive, explorable, and worth spending time with before you go live.

Explore the codebase and deploy your trading bot wallet:

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

Docker Auto-Provisioning Deep Dive: Zero-Config AI Wallet Deployment

Wallet Guy — Sat, 18 Jul 2026 08:13:09 +0000

Docker Auto-Provisioning Deep Dive: Zero-Config AI Wallet Deployment

Docker auto-provisioning for AI wallets sounds like it should require a weekend of configuration — but WAIaaS ships with a zero-config path that gets you from docker run to a fully operational, self-hosted AI wallet daemon in under a minute. If you've ever asked yourself whether you'd trust a third-party service with your AI agent's private keys, this post is for you. We're going to walk through exactly how WAIaaS's auto-provision system works, why self-hosting matters for AI agent wallets specifically, and how to go from nothing to a running wallet daemon with one command.

Why Self-Hosting an AI Wallet Actually Matters

There's a philosophical argument for self-hosting almost anything — privacy, control, no vendor lock-in. But with AI agent wallets, the stakes are higher than with, say, a self-hosted RSS reader.

An AI agent with a wallet has the ability to sign and broadcast real transactions. It can move funds, interact with DeFi protocols, pay for API calls via x402, trade on perpetual markets, and bridge assets across chains. That's not a read-only integration — it's an agent with real financial authority. When that agent lives inside a hosted service, you're trusting that service with:

Your private keys (or their custody of them)
The policy rules that govern what your agent can and can't do
The audit log of every transaction your agent executes
Uptime and rate limits that are outside your control

Self-hosting doesn't just satisfy a philosophical preference. It means your keys never leave your infrastructure, your policy engine runs on hardware you control, and your agent's transaction history is yours. Think of it like running your own email server — except this one actually holds money, so the sovereignty argument isn't just ideological.

WAIaaS is open-source and designed from the ground up to run on your own hardware. The Docker image at ghcr.io/minhoyoo-iotrust/waiaas:latest is the canonical distribution, and the auto-provisioning system means you don't need to configure anything to get started.

What Auto-Provisioning Actually Does

When you pass WAIAAS_AUTO_PROVISION=true to the container, the Docker entrypoint generates a master password for you on first start and writes it to a recovery key file. This means you can spin up a fully secured daemon without ever typing a password manually — the system creates one, stores it somewhere safe, and you retrieve it after the fact.

Here's the full one-liner:

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

A few things worth noting about that single command:

The port binding is 127.0.0.1:3100:3100 — localhost only, by default. The daemon doesn't expose itself to the network unless you deliberately change this. That's a sane default for a service that controls wallets.

The data volume is named, not a bind mount to a random path. Your keys and transaction history survive docker compose down and come back intact on restart.

The recovery key is in /data — the same volume you mounted. If you're running this in production, that volume should be encrypted at rest and backed up. The key itself is just a file, so treat it like one.

The entrypoint also supports Docker Secrets for production deployments, which we'll cover shortly.

The Full Docker Compose Setup

For anything beyond a quick test, docker compose is the right tool. The full docker-compose.yml that ships with WAIaaS looks like this:

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

The healthcheck matters if you're running this behind a reverse proxy or with a process supervisor that needs to know when the daemon is actually ready. It polls /health every 30 seconds and gives the container 10 seconds to warm up before starting checks.

The restart: unless-stopped policy means the daemon comes back after host reboots without you having to do anything. For a homelab or dedicated server, that's the behavior you want.

To get started from the repo:

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

That's it. Three commands.

Hardening for Production: Docker Secrets

Environment variables are fine for development, but for a production self-hosted deployment, you don't want your master password sitting in shell history or visible in docker inspect. WAIaaS ships with a docker-compose.secrets.yml overlay specifically for this use case.

# 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

The secrets overlay injects the password as a Docker Secret rather than an environment variable. The file permission (chmod 600) ensures only root can read it on the host, and Docker Secrets mount it into the container at a path inaccessible from docker inspect output. For homelabbers running Portainer or Dockge, this is worth setting up even if it feels like extra steps — the master password controls wallet creation, session management, and policy configuration, so it's worth protecting.

Key Environment Variables You Should Know

The daemon is configured primarily through environment variables. The ones you're most likely to need:

WAIAAS_AUTO_PROVISION=true              # Auto-generate master password on first start
WAIAAS_DAEMON_PORT=3100                 # Listening port
WAIAAS_DAEMON_HOSTNAME=0.0.0.0         # Bind address
WAIAAS_DAEMON_LOG_LEVEL=info            # Log level (trace/debug/info/warn/error)
WAIAAS_DATA_DIR=/data                   # Data directory
WAIAAS_RPC_SOLANA_MAINNET=<url>         # Solana mainnet RPC endpoint
WAIAAS_RPC_EVM_ETHEREUM_MAINNET=<url>   # Ethereum mainnet RPC endpoint

The RPC endpoint variables deserve special mention. By default, WAIaaS will use public RPC endpoints, which are fine for experimentation but rate-limited for production. If you're running this seriously — especially if you have an agent executing DeFi actions across 18 supported networks — you'll want to plug in your own RPC URLs from providers like Alchemy, Helius, or your own node. This is another advantage of self-hosting: you control the entire stack, including where your RPC calls go.

From Running Container to Configured Wallet: The CLI Path

Once your container is up, you have two paths to initial configuration: the REST API directly, or the CLI. The CLI is faster for humans.

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

If you went the auto-provision route with Docker, you skip init and start and go straight to quickset. The quickset command creates wallets and MCP sessions in one step — it's designed for exactly this use case where you want to go from zero to an AI agent that can actually do things as fast as possible.

The CLI has 20 commands in total. The ones most relevant to initial Docker setup are init, start, quickset, status, stop, and wallet create. The backup create and restore commands are worth knowing about for ongoing maintenance of a self-hosted instance.

Verifying Your Setup with the REST API

Once the daemon is running, the REST API is available at http://127.0.0.1:3100. The interactive API reference lives at /reference and the OpenAPI 3.0 spec is at /doc:

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

# View interactive API reference
open http://127.0.0.1:3100/reference

There are 39 REST API route modules in total, covering wallets, transactions, policies, DeFi actions, NFTs, sessions, and more. But for a sanity check after initial deployment, the simplest test is creating a wallet and checking its balance.

First, create a wallet using your master password (retrieved from recovery.key if you used auto-provision):

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

Then create a session token for an AI agent to use:

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

And verify the session works by checking balance:

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

If you get a balance response, your self-hosted AI wallet daemon is fully operational. Your keys are on your hardware, your transactions are in your database, and your policy engine is running under your control.

Setting Up Policies Before Letting Your Agent Loose

This is the step self-hosters sometimes skip because they're excited to get their agent running — don't skip it. WAIaaS uses a default-deny policy model, meaning certain transaction types are blocked unless explicitly allowed. Before you hand a session token to an AI agent, set at least 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
    }
  }'

There are 21 policy types available, organized around 4 security tiers: INSTANT (execute immediately), NOTIFY (execute and alert), DELAY (queue and wait before executing), and APPROVAL (require human sign-off). The spending limit policy shown above maps dollar thresholds to these tiers — transactions under $100 go through instantly, transactions between $100-$500 trigger a notification, transactions between $500-$2000 wait 15 minutes before executing (giving you time to cancel), and anything above $2000 requires your explicit approval.

The policy engine runs entirely on your server. There's no external service deciding whether your agent's transaction is legitimate — it's all local, deterministic rules that you wrote.

Common Docker Maintenance Commands

For ongoing management of your self-hosted instance:

docker compose up -d          # Start daemon
docker compose logs -f        # Follow logs
docker compose down           # Stop (data preserved in named volume)
docker compose down -v        # Stop + delete data volume

The distinction between down and down -v is important. Without -v, your wallet keys, transaction history, and policies survive the container being removed. With -v, everything is gone. Keep that in mind before running the second variant.

For backups, the CLI has a dedicated command:

waiaas backup create
waiaas backup list
waiaas restore

For a self-hosted setup that's actually managing funds, treat backups the way you'd treat a hardware wallet seed phrase backup — redundant, offline, and tested.

The Two-Image Architecture

WAIaaS actually ships two Docker images: the main waiaas daemon and a push-relay service. The push-relay handles the signing channel notifications — when your agent initiates a transaction that requires human approval, the push-relay is what delivers that approval request to you via push notification. For a minimal self-hosted setup, you can start with just the daemon. The push-relay becomes relevant when you want to approve transactions from your phone rather than having to be at your terminal.

Quick Start Summary

If you want to go from zero to running right now:

Pull and start: docker compose up -d from the cloned repo
Retrieve your password: docker exec waiaas cat /data/recovery.key
Create a wallet: POST to /v1/wallets with your master password
Set a spending policy: POST to /v1/policies before creating any agent sessions
Create a session: POST to /v1/sessions and hand that token to your agent

The whole process takes under five minutes. Everything runs on your hardware, your keys never leave your server, and you have full audit visibility into everything your agent does.

What's Next

Once your daemon is running, the natural next step is connecting it to an AI agent via the MCP integration — WAIaaS provides 45 MCP tools that give Claude and other MCP-compatible agents direct wallet access within the policy guardrails you've set. From there, you can explore the DeFi integrations across 15 supported protocols, or set up the Admin Web UI at /admin for a visual dashboard of your wallets, sessions, and positions.

The full source is at https://github.com/minhoyoo-iotrust/WAIaaS and the project site is at https://waiaas.ai. If you're running this in a homelab or on a VPS and have questions, the GitHub issues and discussions are the right place — this is open-source software maintained in the open.

Your keys, your server, your rules.

Automated Yield Optimization: Building Pendle Protocol Trading Bots

Wallet Guy — Fri, 17 Jul 2026 14:51:32 +0000

Automated Yield Optimization: Building Pendle Protocol Trading Bots

Pendle trading bots live and die by execution — your bot spotted the PT/YT mispricing, the yield curve shifted, and you have seconds before the market corrects. Building that bot on fragile wallet infrastructure means watching profitable trades fail at the signing step, burning gas on failed transactions, or — worse — having no risk controls when your bot misbehaves at 3am. WAIaaS gives you the wallet layer purpose-built for this: multi-protocol DeFi access, gas conditional execution, a 7-stage transaction pipeline, and a policy engine with 21 policy types so you can automate aggressively without losing sleep.

Why Yield Trading Bots Need Infrastructure, Not Just Code

Pendle splits yield-bearing assets into Principal Tokens (PT) and Yield Tokens (YT), creating a rich surface for yield curve arbitrage, fixed-rate locking, and leveraged yield plays. But the complexity doesn't stop at the strategy layer. Your bot needs to:

Execute across Pendle and connected protocols (lending, bridging, staking) without managing separate wallet integrations for each
Avoid wasting gas on transactions that will fail policy checks or hit insufficient balances
Apply risk controls at the infrastructure level — not bolted on in application code that can have bugs
Let you observe and intervene when positions move against you, without shutting down the entire system

These are solved problems at the infrastructure layer. The mistake most bot builders make is solving them at the application layer, in the same codebase as their alpha. Separating concerns here is the difference between a bot you can maintain and one that becomes a liability.

What WAIaaS Brings to Pendle Bot Infrastructure

WAIaaS is a self-hosted Wallet-as-a-Service built for AI agents, but its architecture maps directly onto automated trading bot requirements. Let's walk through what matters for Pendle trading specifically.

15 DeFi Protocol Providers Out of the Box

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. Pendle is directly integrated — your bot calls the action API, not a hand-rolled contract interaction layer you have to maintain.

For a Pendle yield optimization strategy that also hedges on Drift perpetuals or uses Aave v3 for leverage, all of that is accessible through a single wallet and a single session token. One bot, one API, multiple protocols.

Gas Conditional Execution

This one matters a lot for profitability. WAIaaS includes gas conditional execution — transactions execute only when the gas price meets your configured threshold. For a yield arb strategy where your edge is measured in basis points, paying 3x the expected gas because you submitted during a network spike can erase the trade entirely.

Configure your gas threshold at the infrastructure level and let the pipeline handle it. Your bot submits the intent; WAIaaS waits for the right conditions.

7-Stage Transaction Pipeline

Every transaction runs through a 7-stage pipeline: validate, auth, policy, wait, execute, confirm, and a final stages step. For a trading bot, this means:

Validate catches malformed transactions before they touch the network
Auth verifies your session is valid — no surprise authorization failures mid-trade
Policy applies your risk rules before execution — spending limits, allowed tokens, contract whitelists
Wait handles gas conditions and time delays
Execute submits to chain
Confirm tracks the transaction to completion

You get this pipeline for free. Your bot doesn't need to implement retry logic, gas polling, or confirmation tracking — the daemon handles it.

The Policy Engine as a Risk Management Layer

The policy engine is where WAIaaS becomes genuinely useful for serious trading systems. 21 policy types, 4 security tiers (INSTANT, NOTIFY, DELAY, APPROVAL), and default-deny enforcement.

For a Pendle bot, relevant policies include:

SPENDING_LIMIT — 4-tier security based on transaction amount. Small routine trades execute instantly; large position entries require your approval via WalletConnect or Telegram
CONTRACT_WHITELIST — default-deny contract whitelist. Your bot can only interact with Pendle contracts and the other protocols you explicitly list. No scope creep, no accidental interactions with unvetted contracts
ALLOWED_TOKENS — default-deny token whitelist. The bot can only transact in assets you've approved
PERP_MAX_LEVERAGE — if your strategy involves leveraged positions on Drift, cap the leverage at the infrastructure level
PERP_MAX_POSITION_USD — hard cap on position size in USD, enforced before execution
LENDING_LTV_LIMIT — max loan-to-value ratio for lending positions, relevant if your strategy uses Aave v3 leverage
RATE_LIMIT — max transactions per period, useful for preventing runaway bots from draining gas

Here's how you configure a spending limit for a Pendle trading session:

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

Trades under $100 execute immediately. Trades between $100-$500 execute and notify you. Trades between $500-$2000 queue for 15 minutes (giving you time to cancel). Anything over $2000 requires your explicit approval. This is risk management built into the wall, not the application.

Setting Up Your Pendle Bot

Step 1: Spin Up 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

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

The daemon binds to localhost by default. For a trading bot running on the same machine, this is the right posture — don't expose it externally.

Step 2: Create a Wallet and Session

# Create a 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": "pendle-bot", "chain": "evm", "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>"}'

The session token (wai_sess_...) is what your bot uses for all transaction operations. The master password stays out of the bot process entirely.

Step 3: Configure Your Risk Policies

Apply your CONTRACT_WHITELIST before funding the wallet. This ensures the bot can only touch the contracts you've vetted:

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": "CONTRACT_WHITELIST",
    "rules": {
      "contracts": [
        {"address": "<pendle-router-address>", "name": "Pendle Router", "chain": "ethereum-mainnet"},
        {"address": "<pendle-market-address>", "name": "Pendle Market", "chain": "ethereum-mainnet"}
      ]
    }
  }'

Step 4: Write Your Bot Using 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'],
});

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

  // Dry-run first to validate the transaction will pass policy checks
  // and simulate execution before committing gas
  const dryRun = await client.sendToken({
    type: 'TRANSFER',
    to: 'pendle-contract-address',
    amount: '0.1',
    dryRun: true,
  } as any);
  console.log(`Dry run status: ${dryRun.status}`);

  // Execute the actual Pendle action
  const tx = await client.sendToken({
    type: 'TRANSFER',
    to: 'pendle-contract-address',
    amount: '0.1',
  });

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

The dry-run API is particularly valuable for yield trading: simulate the transaction before committing gas, verify it passes all policy checks, and confirm the expected output before execution. This is a call to POST /v1/transactions/send with "dryRun": true in the payload.

Handling Policy Denials Gracefully

Your bot will hit policy denials. That's the point — the policy engine is catching things before they become problems. Handle them explicitly:

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

    if (error.code === 'POLICY_DENIED') {
      // Log the denied trade, alert, wait for manual approval
      // Do NOT retry automatically — that's how bots get into trouble
    }
  }
}

The error response format gives you a structured code, message, domain, and retryable flag:

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

Non-retryable errors like POLICY_DENIED should trigger an alert to your monitoring system, not a retry loop.

Multi-Protocol Yield Strategies

If your Pendle strategy involves more than just PT/YT swaps — say, borrowing on Aave v3 to lever up a yield position, then hedging duration risk on Drift — WAIaaS handles all of this through the actions API. The same session token, the same wallet, the same policy rules applying across every protocol.

The 15 integrated providers cover the main protocols a yield optimizer would touch. Bridging is covered by LI.FI and Across if your strategy spans chains. Liquid staking via Lido (EVM) and Jito (Solana) is available if part of your yield stack involves staked assets.

Observability and Human Override

For a trading bot running unattended, observability is not optional. WAIaaS provides:

Incoming transaction monitoring with real-time notifications for deposits — you know when funds arrive
WalletConnect integration for owner approval of APPROVAL-tier transactions — your phone becomes the hardware approval step for large trades
Transaction history queryable via the SDK with listTransactions()
39 REST API route modules exposed for custom monitoring integrations
OpenAPI 3.0 spec at /doc and interactive reference at /reference — useful when building custom dashboards

The interactive API reference at http://127.0.0.1:3100/reference is worth bookmarking during development. You can test endpoints directly against your running instance, which speeds up the iteration loop considerably.

Quick Start Checklist

Deploy the daemon via Docker with WAIAAS_AUTO_PROVISION=true — takes about 60 seconds
Create a dedicated trading wallet — never use a wallet for multiple bots
Set up CONTRACT_WHITELIST and SPENDING_LIMIT policies before funding — default-deny means nothing executes until you explicitly allow it
Test with dry-run — use dryRun: true to validate your transaction logic before going live
Configure WalletConnect for APPROVAL-tier override — your kill switch for large positions

The 20-command CLI (waiaas quickset, waiaas start, waiaas status, etc.) handles the initialization flow if you prefer not to script the API directly.

What's Next

The WAIaaS codebase is open-source and self-hosted — you control your keys, your data, and your infrastructure. Start with the GitHub repository to review the policy engine implementation and transaction pipeline before deploying capital:

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

The interactive API docs at /reference are the fastest way to understand the full surface area once your daemon is running. With 39 REST API routes, 45 MCP tools, and 21 policy types, there's significant depth to explore as your strategy matures — but the core flow for a Pendle trading bot is straightforward enough to have running in an afternoon.