DEV Community: Wallet Guy

RATE_LIMIT Policy: Prevent Your DeFi Bot from Getting Rekt by MEV

Wallet Guy — Sun, 11 Oct 2026 18:01:29 +0000

RATE_LIMIT Policy: Prevent Your DeFi Bot from Getting Rekt by MEV

Your DeFi bot is firing transactions faster than you can monitor them — and without rate limiting baked into your wallet infrastructure, you're not just vulnerable to MEV, you're handing over free money to every searcher watching the mempool. Whether you're running an arb loop, a liquidation bot, or a multi-protocol yield strategy, uncontrolled transaction velocity is one of the fastest ways to blow up a wallet.

Why Transaction Rate Control Is a First-Class Problem

Here's a scenario most bot builders have lived through: your arb strategy detects a pricing discrepancy between two DEX pools. Your bot fires. Then fires again. Then fires a third time because the first confirmation hasn't landed yet and your loop hasn't exited. You've just broadcast three competing transactions from the same wallet, front-run yourself, and paid gas on all three — two of which reverted.

MEV bots didn't steal that trade. You handed it to them.

Rate limiting at the infrastructure level — not just in your application code — is the difference between a bot that survives market volatility and one that drains itself dry during a busy block. Application-level rate limiting is fragile: a restart, a race condition, a missed exception handler, and your throttle is gone. You need the wallet itself to enforce limits, independent of whatever application logic is running above it.

This is where WAIaaS's RATE_LIMIT policy comes in.

What RATE_LIMIT Actually Does

WAIaaS has a policy engine with 21 policy types and 4 security tiers: INSTANT, NOTIFY, DELAY, and APPROVAL. The RATE_LIMIT policy caps how many transactions your wallet can submit within a given period — and it enforces this at the daemon level, before execution, inside the 7-stage transaction pipeline.

That means no matter what your bot code does — whether it crashes and restarts in a loop, has a logic bug that triggers duplicate sends, or gets compromised and starts spamming — the wallet will hard-stop once the rate limit is hit.

The policy configuration is simple:

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

You set the max number of transactions allowed per period, and any submission beyond that gets rejected with a structured error before it ever touches the chain.

Setting Up RATE_LIMIT for Your Trading Bot

First, you need a wallet. Here's the full flow from zero to rate-limited bot wallet using the REST API:

Create the wallet:

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

Create a session for your bot:

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

Apply the RATE_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": "RATE_LIMIT",
    "rules": {
      "maxTransactions": 10,
      "period": "hourly"
    }
  }'

Ten transactions per hour is a conservative starting point. For a high-frequency arb bot you might push that higher. For a yield rebalancer that only needs to act a few times a day, you'd set it lower. The point is that it's explicit, enforced at the wallet level, and observable.

When your bot hits the limit, it gets a structured error response — not a chain revert, not a silent failure:

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

Your bot can catch this, log it, and back off — rather than spiraling into a retry loop that chews through gas.

Layering RATE_LIMIT With SPENDING_LIMIT for Compound Protection

RATE_LIMIT controls frequency. SPENDING_LIMIT controls size. Used together, they give you two independent axes of risk control — and WAIaaS's policy engine applies both simultaneously.

Here's a SPENDING_LIMIT policy configured for a trading bot wallet:

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, the 4-tier logic works like this:

Under $100 → INSTANT: executes immediately, no notification
$100–$500 → NOTIFY: executes immediately, but you get an alert
$500–$2000 → DELAY: queued for 15 minutes, cancellable
Over $2000 → APPROVAL: requires human sign-off via WalletConnect or push notification

For a trading bot, this means your routine small swaps execute at full speed, while anything anomalously large trips the delay or approval gate. If a bug in your bot logic generates a massive unexpected trade, it doesn't execute immediately — you have a window to intervene.

Gas Conditional Execution: Don't Trade When It's Expensive

Beyond rate limiting, WAIaaS has gas conditional execution built into its transaction pipeline. Transactions execute only when gas price meets your configured threshold.

For Solana bots on Jupiter this is less of a concern, but for EVM bots — especially anything interacting with Aave, Pendle, or Hyperliquid on Ethereum-based chains — gas timing can make or break a strategy. An arb that's profitable at 20 gwei becomes a loss at 80 gwei.

Gas-conditional execution gives your bot a structural filter: it only fires when execution cost is within your acceptable range.

Multi-Protocol Access: One Wallet, 15 DeFi Integrations

The other reason to run your trading infrastructure through WAIaaS is the breadth of DeFi protocol access. WAIaaS integrates 15 DeFi protocol providers:

Jupiter (Solana DEX aggregation)
Drift (Solana perpetuals)
Hyperliquid (perpetual futures, spot trading, sub-accounts)
Aave V3 (lending/borrowing)
Kamino (Solana lending)
LI.FI + Across (cross-chain bridging)
Lido + Jito (liquid staking)
0x + D'CENT swap (EVM DEX aggregation)
Pendle (yield trading)
Polymarket (prediction markets)
XRP Ledger DEX (XRPL native DEX)
ERC-8004 (onchain agent reputation)

A multi-leg strategy — say, borrow on Aave, swap on 0x, bridge via LI.FI, then stake the output on Lido — runs through a single wallet, a single session token, and a single policy set. You're not managing credentials and rate limits across five different integrations.

Here's what a Jupiter swap looks like through the API:

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

That's a SOL → USDC swap. The wallet handles signing, the policy engine checks it against your RATE_LIMIT and SPENDING_LIMIT rules, and the transaction goes out — or gets blocked, depending on your configuration.

Dry-Run Before You Execute

Before your bot goes live, or before you commit to a trade in a new market condition, simulate it:

curl -X POST http://127.0.0.1:3100/v1/transactions/send \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer wai_sess_<token>" \
  -d '{
    "type": "TRANSFER",
    "to": "recipient-address",
    "amount": "0.1",
    "dryRun": true
  }'

The dryRun flag runs the transaction through the full 7-stage pipeline — including policy evaluation — without hitting the chain. You can verify that your bot's intended transaction would pass your rate limit, spending limit, token whitelist, and contract whitelist before committing real funds.

This is especially useful during strategy development: wire up your bot logic, run it in dry-run mode under load, and see exactly which transactions would have been blocked and why.

Quick Start: Bot Wallet With Rate Limiting in 5 Steps

Install the CLI and start the daemon

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

Create a dedicated 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": "trading-wallet", "chain": "solana", "environment": "mainnet"}'

Create a session token for your bot

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

Apply RATE_LIMIT and SPENDING_LIMIT policies

# Rate limit: 10 transactions per hour
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": "RATE_LIMIT",
    "rules": {"maxTransactions": 10, "period": "hourly"}
  }'

# Spending limit: tiered security by transaction size
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
    }
  }'

Run your first dry-run trade to verify policies are working

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 Infrastructure Layer Your Bot Actually Needs

The pattern here isn't complicated, but it's easy to skip when you're moving fast: enforce your risk rules at the infrastructure level, not in application code. Application code restarts, has bugs, and gets updated. A wallet-level policy enforced inside a 7-stage transaction pipeline before execution is a harder guarantee.

WAIaaS gives you 21 policy types to work with — rate limits, spending tiers, token whitelists, contract whitelists, network restrictions, venue whitelists, and more. For a trading bot, you'd typically combine RATE_LIMIT + SPENDING_LIMIT + ALLOWED_TOKENS + CONTRACT_WHITELIST to get a wallet that can only do exactly what your strategy requires, at the frequency and size your risk parameters allow.

The policy engine enforces default-deny: if ALLOWED_TOKENS or CONTRACT_WHITELIST isn't configured, those transaction types are blocked. Your bot can't accidentally interact with a contract you didn't explicitly whitelist.

What's Next

The full policy engine documentation, including all 21 policy types and their configuration schemas, is available via the interactive API reference at http://127.0.0.1:3100/reference once your daemon is running. For connecting your bot to Claude or other LLM-based agent frameworks, the 45 MCP tools in @waiaas/mcp cover the full trading surface — from balance queries to DeFi position management.

Check out the codebase and open issues on GitHub, and find the full documentation on the official site:

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

CLI Session Hardening: TTL, Renewals, and Emergency Disconnection for Self-Hosted Wallets

Wallet Guy — Sun, 11 Oct 2026 13:05:18 +0000

CLI Session Hardening: TTL, Renewals, and Emergency Disconnection for Self-Hosted Wallets

Would you trust a third party with your AI agent's private keys? If you're running autonomous agents that move real money, the answer shapes everything about how you architect your setup. Self-hosted wallet infrastructure gives you something no hosted service can: the ability to define, inspect, and enforce exactly how long an AI agent's access lasts — and to kill that access instantly when something goes wrong.

Why Session Hygiene Matters When Agents Hold Value

There's a meaningful difference between an AI agent that can access a wallet and one that should — and that difference is time.

Hosted wallet services abstract this away, which is convenient until it isn't. If an agent session token is long-lived and you don't control the server, a compromised token is someone else's problem to revoke. When you self-host, the session lifecycle is entirely yours. You decide when a token expires, whether it can be renewed, and how hard the ceiling is. And when you need to pull the plug — because the agent behaved unexpectedly, or you just want to sleep soundly — you can do it from your own terminal, against your own server, with no support ticket required.

WAIaaS (Wallet-as-a-Service for AI agents) is an open-source, self-hosted daemon built around this philosophy. Your keys live on your server. Your policies run on your server. Your session rules are enforced on your server.

The Three Auth Layers You're Actually Working With

Before diving into session hardening specifically, it helps to understand the three authentication roles in WAIaaS, because they serve different principals with different levels of trust.

masterAuth is the system administrator credential, used with X-Master-Password. It can create wallets, manage sessions, and set policies. This is the credential you use at setup time and keep locked away.

sessionAuth is what your AI agent carries around — a JWT token prefixed wai_sess_. This is the credential that actually moves money. It's scoped to a single wallet and constrained by whatever policies and TTL you configure.

ownerAuth is for the human fund owner — the person who approves high-value transactions or issues a kill switch. It uses cryptographic signatures (Ed25519 or secp256k1) rather than a shared password.

The session layer is where most of your day-to-day hardening happens.

Creating a Session with Explicit Lifetime

Creating a session is a single API call with masterAuth:

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

WAIaaS supports per-session TTL, maxRenewals, and absoluteLifetime configuration. This means you can create a session that:

Expires after a short window (TTL)
Can be renewed by the agent up to N times (maxRenewals)
Has a hard ceiling it can never cross (absoluteLifetime), regardless of renewals

The practical effect: an agent can keep itself alive during a long trading run by renewing its own session, but it cannot extend that access indefinitely. When absoluteLifetime hits, the session is dead and the agent must come back to a human (or an automated provisioning system) for a new one.

This is the crypto equivalent of issuing a contractor a keycard that works for 8 hours, auto-renews if they badge in before expiry, but physically deactivates at midnight no matter what.

The CLI Owns Your Session Workflow

WAIaaS ships a CLI with 20 commands. The session-relevant ones are what you'll reach for most:

npm install -g @waiaas/cli
waiaas init          # Initialize config directory
waiaas start         # Start the daemon
waiaas quickset      # Create wallets + sessions in one step

For day-to-day operations:

waiaas session prompt    # Interactive session management
waiaas status            # Check daemon status
waiaas owner status      # Check owner connection state
waiaas owner disconnect  # Disconnect the owner approval channel

The waiaas quickset command is worth calling out specifically. If you want wallets created and MCP session tokens generated in a single step — without manually stitching together API calls — quickset handles that. For self-hosters who want to go from "fresh Docker volume" to "agent has a working token" in under two minutes, this is the path.

Emergency Disconnection: The Kill Switch

Here's the scenario: your agent starts behaving oddly — maybe it's submitting transactions you didn't expect, or your logs show something you don't understand. You want to stop it now, not after you've found the right API endpoint in documentation at 2am.

WAIaaS's security architecture includes three layers. The first is session auth — time-limited tokens that constrain normal operation. The second is time delay plus approval — transactions above your configured threshold get queued and require human sign-off before execution. The third is monitoring and kill switch.

The kill switch is operated via ownerAuth. If you have WalletConnect connected (via waiaas owner connect), you can approve or reject pending transactions from your phone. More relevantly here: you can disconnect and revoke access through the owner channel entirely.

waiaas owner disconnect   # Disconnect owner approval channel

For pending transactions that already hit the APPROVAL tier, the ownerAuth endpoint lets you reject them:

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

Rejection works the same way — the ownerAuth endpoint handles both approval and denial of queued transactions.

Policy as a Second Line of Defense

Session TTL handles when access expires. Policies handle what the agent can do while access is active. These two systems work together.

The policy engine has 21 policy types and 4 security tiers: INSTANT, NOTIFY, DELAY, and APPROVAL. The default is deny — if you haven't explicitly allowed a token or contract, the transaction is blocked.

A minimal spending policy 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
    }
  }'

With this configuration:

Under $100: executes immediately
$100–$500: executes and sends a notification
$500–$2,000: queued for 15 minutes, cancellable during that window
Over $2,000: requires explicit owner approval

Combined with a short session TTL and maxRenewals, this means even a fully autonomous agent is operating inside a box with hard walls on both time and value. If the agent misbehaves, the DELAY tier gives you a window to cancel before anything executes. The APPROVAL tier means certain actions simply cannot happen without a human.

Dry-Run Before You Commit

One underrated tool for self-hosters: the dry-run API. Before your agent goes live, you can simulate any transaction to see how the policy engine would respond — without broadcasting anything to a blockchain.

curl -X POST http://127.0.0.1:3100/v1/transactions/send \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer wai_sess_<token>" \
  -d '{
    "type": "TRANSFER",
    "to": "recipient-address",
    "amount": "0.1",
    "dryRun": true
  }'

This is how you validate your policy configuration before exposing a session token to an agent. Run a dry-run at $50, $150, $600, $2,100 — confirm each hits the tier you intended. If a POLICY_DENIED comes back when you expected INSTANT, you know your ALLOWED_TOKENS policy isn't configured yet.

The error format is machine-readable, so agents can inspect why a transaction was rejected:

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

Getting a Self-Hosted Instance Running

If you want to try this on your own hardware, the Docker path is the fastest:

Step 1: Clone and start

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 — it's not publicly accessible unless you explicitly expose it.

Step 2: Auto-provision for a passwordless first start

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

Step 3: Install the CLI and initialize

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

Step 4: Harden your master password when ready

waiaas set-master    # Replace auto-provisioned password with your own

After that, delete recovery.key from your data volume. It's only needed for the initial bootstrap.

Step 5: Configure a spending policy and set a session TTL

Use the policy API call from earlier in this post. Then create a session for your agent with the scoped TTL you want. The agent gets a wai_sess_ token; your policies enforce the rest.

For Production: Secrets Overlay

If you're running this on a server rather than a local machine, use the Docker secrets overlay for your master password:

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

This keeps your master password out of environment variables and out of your compose file's commit history.

The Self-Hosted Mindset

Running your own wallet infrastructure for AI agents is closer to "actually practical" than it used to be. The operational surface is a single Docker container, a CLI, and a handful of API calls. The tradeoff you're making — accepting operational responsibility — is the same one you make when you run your own email server, your own VPN, or your own Nextcloud instance.

What you get in exchange is meaningful: no third-party custody, no API rate limits from hosted services, no dependency on another company's uptime, and complete auditability of every session token ever issued. When an agent's session expires, it's because you said it should. When a transaction gets blocked, it's because your policy said so. When the kill switch fires, it fires on your server.

That's not a philosophical position — it's an architecture decision with concrete security properties.

What's Next

The WAIaaS documentation covers the full policy type reference, MCP integration for connecting agents to Claude and other LLM frameworks, and the TypeScript and Python SDKs for building agents that interact with the REST API directly.

Start at the GitHub repository — https://github.com/waiaas/WAIaaS — where you'll find the Docker Compose files, the CLI source, and the full monorepo. The project site at https://waiaas.ai has additional guides for specific deployment patterns and agent integrations.

The Micropayment Revolution: How AI Agents Will Transform Digital Commerce with x402

Wallet Guy — Sat, 10 Oct 2026 17:48:41 +0000

The Micropayment Revolution: How AI Agents Will Transform Digital Commerce with x402

AI agents will need to pay for compute, data, and API calls — and the infrastructure to make that happen exists today, not in some theoretical future. The x402 HTTP payment protocol, combined with autonomous wallet infrastructure, means machines can already transact on their own behalf. If you're building AI systems or thinking seriously about the agent economy, this is the layer you need to understand.

The Problem Nobody Talks About

Everyone is excited about AI agents that can browse the web, write code, and make decisions. Far fewer people are asking the obvious follow-up question: how do agents pay for things?

Right now, the answer is embarrassing. An agent that needs to call a paid API either uses a hardcoded key controlled by a human, hits a free tier until it runs out, or stops working entirely. There's no mechanism for an autonomous agent to walk up to a paywall, evaluate whether the data is worth the cost, and pay for it — the way a human would with a credit card.

This matters because the economics of the agent economy break down without it. If every agent action that costs money requires a human to approve a payment, you haven't built an autonomous agent. You've built a very sophisticated assistant that keeps interrupting you to ask for your wallet.

The missing layer is autonomous payment infrastructure: wallets that agents can operate independently, within rules set by humans, without requiring human approval for every transaction.

What x402 Actually Is

The x402 protocol is elegantly simple. When an HTTP server requires payment for a resource, it responds with a 402 Payment Required status code, along with the payment details in the response headers. A client that understands x402 can then make the payment and retry the request automatically.

For AI agents, this is transformative. An agent making API calls doesn't need to know in advance which endpoints cost money or how much. It encounters a 402 response, evaluates the payment terms, pays if authorized, and continues — all without human involvement.

WAIaaS implements x402 support directly, so agents using the SDK can make HTTP requests that automatically handle payment when they hit a 402 response:

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

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

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

That single method call is doing something that would otherwise require significant custom infrastructure: detecting payment requirements, constructing the payment, submitting it on-chain, and retrying the original request. The agent doesn't need to know any of that is happening. It just gets its data.

The Wallet Problem for Autonomous Agents

For x402 payments to work autonomously, agents need wallets they can actually use — not wallets controlled by humans that agents have to ask permission to spend from, and not custodied accounts managed by a centralized service.

The requirements for an agent wallet are different from a human wallet:

Programmable spending rules. An agent shouldn't be able to spend unlimited amounts. The humans deploying the agent need to define exactly what it's allowed to spend, on what, with what limits. These rules need to be enforced at the infrastructure level, not by hoping the agent follows instructions.

Session-based authorization. Agents operate in sessions. A session token scopes what the agent can do, for how long, with what permissions. When a session expires or is revoked, the agent loses access — immediately.

Audit trails. Every payment an agent makes needs to be logged, attributable, and reviewable. Not for regulation (though that matters too) — for debugging. When your agent spends money unexpectedly, you need to know exactly what it paid for and why.

Human escalation paths. Some transactions should require human approval. Large payments, unusual patterns, high-risk actions — these should surface to a human who can approve or reject, without blocking the agent entirely.

WAIaaS is built around exactly these requirements. It's a self-hosted, open-source Wallet-as-a-Service specifically designed for AI agents, and the policy engine is where the real thinking has happened.

The Policy Engine: Rules That Actually Enforce

The WAIaaS policy engine has 21 policy types and 4 security tiers (INSTANT, NOTIFY, DELAY, and APPROVAL). The tiers determine what happens when a transaction is submitted:

INSTANT — execute immediately, no notification
NOTIFY — execute immediately, but notify the owner
DELAY — queue the transaction and execute after a time delay (cancellable)
APPROVAL — hold until a human explicitly approves

For x402 payments specifically, there's a dedicated policy type: X402_ALLOWED_DOMAINS. This lets you whitelist exactly which domains an agent is allowed to pay automatically:

curl -X POST http://localhost:3100/v1/policies \
  -H 'Content-Type: application/json' \
  -H 'X-Master-Password: <password>' \
  -d '{
    "walletId": "<wallet-uuid>",
    "type": "X402_ALLOWED_DOMAINS",
    "rules": {
      "domains": ["api.example.com", "*.openai.com"]
    }
  }'

An agent trying to make an x402 payment to a domain not on this list will have the transaction blocked. The policy is enforced at the infrastructure level — the agent doesn't get to override it.

Combine this with a spending limit policy and you have real guardrails:

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

An agent that tries to make a payment under $10 executes instantly. A payment between $10 and $100 executes but you get notified. A payment between $100 and $1,000 queues for 5 minutes (giving you time to cancel). Anything over $1,000 requires your explicit approval.

The default-deny design matters here: transactions are blocked unless explicitly allowed by policy. An agent with no configured ALLOWED_TOKENS or CONTRACT_WHITELIST can't move funds. You have to opt in to permissions, not opt out of them.

The Three-Layer Security Model

The authentication model in WAIaaS reflects the different roles in the agent economy:

masterAuth is for system administrators — the humans who set up wallets, create sessions, and configure policies. This uses Argon2id password hashing and controls the critical administrative operations.

sessionAuth is for AI agents. A session token (JWT HS256) scopes what the agent can do. When you create a session for an agent, you're handing it a credential that lets it operate within the boundaries you've defined. The agent uses this token for balance queries, transactions, DeFi actions, and x402 payments.

ownerAuth is for fund owners — the humans who hold the actual assets. This uses cryptographic signatures (Ed25519 or secp256k1) and is what's required to approve transactions that hit the APPROVAL tier, or to exercise the kill switch if something goes wrong.

Creating a wallet and issuing a session to an agent looks like this:

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

# Create a session for the agent (masterAuth)
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 agent then uses the session token for everything it does. It never sees the master password. It can't create other sessions or modify policies. It operates within the box you've defined.

Dry-Run: The Sanity Check Before Spending

One capability worth highlighting for agent payments is dry-run simulation. Before executing a transaction, an agent (or the system building on WAIaaS) can simulate it to check what would happen without committing to 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
  }'

For an agent making autonomous payments, this is valuable. Before committing to an x402 payment, you can check whether it would be blocked by policy, whether the balance is sufficient, and what the expected outcome would be. This is the kind of infrastructure that makes autonomous payment systems trustworthy rather than terrifying.

Getting It Running in Five Minutes

The fastest path from zero to a running agent wallet:

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

Or with Docker if you prefer containers:

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

For production, Docker Secrets support is built in:

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 running, the interactive API reference at /reference shows every available endpoint with the ability to try calls directly. The OpenAPI 3.0 spec at /doc is machine-readable if you're generating clients.

The MCP Connection: Agents That Already Understand Wallets

If you're building with Claude or another AI that supports the Model Context Protocol, WAIaaS ships 45 MCP tools out of the box. One of them is x402-fetch — meaning Claude can make x402-authenticated HTTP requests directly through the tool interface.

Setting it up takes one command:

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

After that, your Claude Desktop configuration points to the WAIaaS MCP server, and Claude gains wallet capabilities: checking balances, sending tokens, querying DeFi positions, and making x402 payments — all within the policy boundaries you've configured.

This isn't a conceptual demo. The MCP package is @waiaas/mcp on npm, the tools are real, and the wallet operations go through the same policy engine described above.

What the Agent Economy Needs

The x402 protocol solves the discovery and payment mechanics. WAIaaS solves the wallet infrastructure. What's still needed — and what the community is actively working on — is the ecosystem of services that expose paid APIs via x402, and the conventions for how agents should evaluate payment terms before agreeing to them.

The ERC-8004 integration in WAIaaS is relevant here: it provides onchain agent reputation and validation, so services can assess the trustworthiness of an agent making payment before deciding whether to accept. The REPUTATION_THRESHOLD policy type means wallet operators can also require that agents they interact with have sufficient onchain reputation. Trust flows in both directions.

The infrastructure layer is ready. What happens next depends on builders deciding to expose paid services via x402 and agents being deployed with wallets capable of paying for them.

What's Next

If you want to explore the full API surface, the interactive reference is at http://127.0.0.1:3100/reference once you have WAIaaS running. The codebase itself — 15 packages, 684+ test files, 39 API route modules — is on GitHub and MIT licensed.

The shift from agents that ask for permission to agents that operate within pre-approved rules is happening now. The wallets and payment protocols exist. The question is what you build on top of them.

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

Policy Stack Architecture: Layering 21 Security Controls for High-Frequency DeFi Bots

Wallet Guy — Sat, 10 Oct 2026 12:43:49 +0000

Policy Stack Architecture: Layering 21 Security Controls for High-Frequency DeFi Bots

DeFi trading bots operate in an adversarial environment where a single misconfigured permission can drain a wallet in seconds — so before your bot executes a single swap, you need a policy stack that's as carefully engineered as the trading logic itself. Most teams bolt on risk controls as an afterthought, wrapping transactions in ad-hoc checks scattered across their codebase. WAIaaS takes the opposite approach: a structured 21-policy engine with four security tiers baked directly into the transaction pipeline, so your bot inherits production-grade risk management without you writing a line of custom guard logic.

The Problem With DIY Risk Controls

When you're building an arb bot or a market-making system, the trading logic gets all the attention — spreads, slippage tolerances, execution latency. The risk layer usually ends up as a handful of if statements: check the recipient, check the amount, maybe check the gas price. This works until it doesn't.

The failure modes are well-documented. A compromised session token gives an attacker unlimited spend. A DeFi integration bug routes funds to an unintended contract. A runaway bot loop drains its own wallet executing bad trades at 2am. None of these are exotic attacks — they're routine incidents that teams only think about after the fact.

What you actually need is a policy engine that sits between your bot's intent and execution: one that enforces spending caps, whitelists contracts, restricts token approvals, sets leverage limits, and requires human sign-off above a threshold — all before the transaction ever hits the chain.

The WAIaaS Policy Architecture

WAIaaS runs every transaction through a 7-stage pipeline. Stage 3 is the policy engine, and it enforces 21 policy types organized into four security tiers:

INSTANT — Execute immediately, no notification
NOTIFY — Execute immediately, send a notification to the owner
DELAY — Queue the transaction for a configurable delay period (cancellable)
APPROVAL — Block until the fund owner explicitly approves via WalletConnect, Telegram, or push notification

The engine is default-deny: if you haven't configured ALLOWED_TOKENS or CONTRACT_WHITELIST, the transaction is blocked. This is the right default for a bot. You explicitly enumerate what the bot is allowed to do, and everything else fails closed.

Building a Policy Stack for a Solana Trading Bot

Let's walk through a realistic configuration for a Solana arbitrage bot that swaps on Jupiter and holds positions on Drift.

Layer 1: Spending Limits With Tiered Security

The foundation of any bot policy stack is a spending limit that maps transaction sizes to security tiers. Small routine trades execute instantly. Larger positions trigger notifications. Anything above your comfort threshold requires your explicit approval.

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": 100,
      "notify_max_usd": 1000,
      "delay_max_usd": 5000,
      "delay_seconds": 300,
      "daily_limit_usd": 20000,
      "monthly_limit_usd": 200000
    }
  }'

This single policy means your arb bot can execute $100 swaps all day without friction. A $500 position gets a push notification to your phone. A $3000 trade queues for five minutes before executing — giving you a window to cancel if something looks wrong. Anything above $5000 hard-blocks until you approve it.

The tier assignment logic is straightforward: amount <= instant_max → INSTANT, <= notify_max → NOTIFY, <= delay_max → DELAY, > delay_max → APPROVAL. You can also set per-token limits within the same policy using token_limits, so your SOL exposure and your USDC exposure have separate thresholds.

Layer 2: Token Whitelist (Default-Deny)

Without an ALLOWED_TOKENS policy, the engine blocks all token transfers. Add one to define exactly which tokens your bot is permitted to touch:

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

If a bug in your Jupiter integration accidentally constructs a swap to an unfamiliar mint address, the engine rejects it before it ever touches the signing stage. Your bot cannot move tokens that aren't on this list.

Layer 3: Contract Whitelist

For a Solana bot interacting with Jupiter and Drift, you want to explicitly enumerate the program addresses the bot is allowed to call:

curl -X POST http://localhost:3100/v1/policies \
  -H 'Content-Type: application/json' \
  -H 'X-Master-Password: <password>' \
  -d '{
    "walletId": "<wallet-uuid>",
    "type": "CONTRACT_WHITELIST",
    "rules": {
      "contracts": [
        {"address": "JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4", "name": "Jupiter", "chain": "solana"},
        {"address": "dRiftyHA39MWEi3m9aunc5MzRF1JYuBsbn6VPcn33UH", "name": "Drift", "chain": "solana"}
      ]
    }
  }'

This is your blast radius limiter. Even if your bot's session token is leaked, an attacker can't route funds to an arbitrary program. The whitelist is enforced at the policy layer — before signing, before broadcast.

Layer 4: Approval Controls

Perpetual futures bots need a different class of policy. The PERP_MAX_LEVERAGE, PERP_MAX_POSITION_USD, and PERP_ALLOWED_MARKETS types give you guardrails at the DeFi semantic level rather than just the transaction value level:

# Cap leverage at 5x
curl -X POST http://localhost:3100/v1/policies \
  -H 'Content-Type: application/json' \
  -H 'X-Master-Password: <password>' \
  -d '{
    "walletId": "<wallet-uuid>",
    "type": "PERP_MAX_LEVERAGE",
    "rules": {"maxLeverage": 5}
  }'

# Cap position size
curl -X POST http://localhost:3100/v1/policies \
  -H 'Content-Type: application/json' \
  -H 'X-Master-Password: <password>' \
  -d '{
    "walletId": "<wallet-uuid>",
    "type": "PERP_MAX_POSITION_USD",
    "rules": {"maxPositionUsd": 10000}
  }'

A runaway position-sizing bug can't lever your wallet into oblivion when PERP_MAX_LEVERAGE is enforced at the policy layer.

Layer 5: Rate Limiting and Time Restrictions

For bots that should only trade during specific market windows:

# Maximum 50 transactions per hour
curl -X POST http://localhost:3100/v1/policies \
  -H 'Content-Type: application/json' \
  -H 'X-Master-Password: <password>' \
  -d '{
    "walletId": "<wallet-uuid>",
    "type": "RATE_LIMIT",
    "rules": {"maxTransactions": 50, "period": "hourly"}
  }'

A RATE_LIMIT policy is your circuit breaker for feedback loops. If a bug causes your bot to hammer the same trade repeatedly, it hits the rate cap before the damage compounds.

Gas Conditional Execution

One of the more operationally useful features for high-frequency bots is gas conditional execution — transactions execute only when the gas price meets a configured threshold. Your bot submits the transaction to the pipeline; the pipeline holds it in the wait stage until gas conditions are met. This is particularly relevant for EVM bots where gas spikes can make an otherwise profitable arb unprofitable.

This behavior is handled by the pipeline's wait stage, which sits before execution. Combined with the DELAY tier from your spending limit policy, you get a transaction queue that's both security-gated and gas-aware.

Simulating Before You Execute

Before your bot sends a real transaction, use the dry-run API to validate that the transaction would pass policy checks and estimate the outcome:

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

For a trading bot this is valuable during development and in production before entering new market conditions. A dry run traverses the full pipeline — validation, policy engine, simulation — without touching the chain. If your policy stack would block the transaction, you find out here rather than at execution time.

Executing DeFi Actions

Once your policy stack is configured, your bot interacts with the 15 integrated DeFi protocols through a consistent action API. Here's a Jupiter swap:

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 session token used here is scoped — it can only operate within the policy constraints you configured for that wallet. The bot never touches the master password. If the session is compromised, the attacker operates within a policy-constrained environment: token whitelist enforced, contract whitelist enforced, spending limits applied, rate limits active.

The Three Auth Layers

Understanding the auth separation matters for bot architecture:

masterAuth (Argon2id) — Your system administrator identity. Creates wallets, manages sessions, sets policies. Your bot never holds this credential.
sessionAuth (JWT HS256) — Your bot's operating credential. Scoped to a specific wallet, subject to all configured policies. This is what goes into your bot's environment variables.
ownerAuth (SIWS/SIWE) — The fund owner's identity for approving high-value transactions. Used by you personally via WalletConnect or a signing tool.

# Bot uses sessionAuth for all trading operations
curl -X POST http://127.0.0.1:3100/v1/transactions/send \
  -H "Authorization: Bearer wai_sess_<token>" \
  -H "Content-Type: application/json" \
  -d '{"type": "TRANSFER", "to": "recipient-address", "amount": "0.1"}'

# Owner approves a transaction that hit the APPROVAL tier
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>"

Quick Start: Standing Up a Policy-Gated Trading Wallet

Here's the minimum viable setup for a bot with sensible defaults:

1. Start the daemon:

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

2. Create a wallet and session:

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

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

3. Apply your policy stack — spending limit, token whitelist, contract whitelist, rate limit as shown above.

4. Put the session token in your bot's environment and start trading:

export WAIAAS_SESSION_TOKEN=wai_sess_<token>

Your bot now operates within a policy-gated environment. All 21 policy types are available to layer in as your strategy grows more complex.

What's Next

The full list of 21 policy types — including LENDING_LTV_LIMIT, APPROVE_AMOUNT_LIMIT, VENUE_WHITELIST, and ERC8128_ALLOWED_DOMAINS — is documented in the interactive API reference at http://127.0.0.1:3100/reference once your daemon is running. The OpenAPI 3.0 spec is available at /doc for integration with your tooling.

If you're building cross-chain strategies that also need bridge operations via LI.FI or Across, or want to connect to Claude or another LLM via the 45-tool MCP server for a hybrid agent/bot architecture, the same policy stack governs all of it — one configuration, consistent enforcement across every protocol and chain.

Explore the codebase and self-host your own instance: github.com/waiaas/WAIaaS

Full documentation and hosted options: waiaas.ai

Claude Waits for Cheap Gas: MCP Tools for Gas-Conditional DeFi Execution

Wallet Guy — Fri, 09 Oct 2026 18:47:03 +0000

Claude Waits for Cheap Gas: MCP Tools for Gas-Conditional DeFi Execution

MCP tools for DeFi execution are about to change how your Claude agent interacts with onchain protocols — instead of hardcoding wallet logic into every script, you add one entry to claude_desktop_config.json and Claude gains a fully-featured wallet with 45 tools covering swaps, staking, lending, bridging, and yes, gas-conditional execution. This post shows you exactly how to set that up and why gas conditions matter for autonomous agents running DeFi strategies.

The Problem: Autonomous Agents and Gas Timing

Anyone who has run an automated DeFi strategy knows the pain. Your agent executes a swap at exactly the wrong moment — gas spikes, the transaction costs three times what it should, and the trade is no longer profitable. If a human were watching, they'd wait. But autonomous agents don't wait. They fire and forget.

This is a real problem when you're giving an AI agent control over onchain actions. The agent might be smart enough to find the right trade, but without infrastructure that enforces execution conditions, it'll burn gas whenever it decides to move. For long-running strategies — think recurring rebalancing, yield harvesting, or position management — bad gas timing compounds into serious losses over time.

The answer isn't to make the agent smarter about gas in every prompt. The answer is to build the gas condition into the infrastructure layer, so the agent can't execute until conditions are met. That's exactly what WAIaaS's gas conditional execution feature does, and it's exposed directly through MCP tools that Claude can call.

What WAIaaS Brings to Claude Desktop

WAIaaS is an open-source, self-hosted Wallet-as-a-Service designed for AI agents. It runs as a local daemon (default port 3100) and exposes its capabilities through multiple integration surfaces — REST API, TypeScript SDK, Python SDK, and an MCP server.

The MCP server is the interesting part for Claude users. It packages 45 tools into a single stdio-based server that Claude Desktop can call directly. Those tools cover:

Wallet operations (balance, address, assets, transaction history)
Token transfers and batch transactions
DeFi actions across 15 integrated protocols
NFT queries and transfers
ERC-4337 UserOp building and signing
x402 HTTP payment protocol
Simulation and dry-run before execution
WalletConnect integration for human approval flows

The gas conditional execution feature (FEAT-GAS) lives in the transaction pipeline. When your agent submits a transaction, the pipeline checks whether the current gas price meets a configured threshold before proceeding to execution. The agent doesn't need to poll gas prices, implement retry logic, or manage any of this — it submits, and the infrastructure handles the waiting.

One Line to Give Claude a Wallet

Here's the configuration. Open ~/Library/Application Support/Claude/claude_desktop_config.json and add:

{
  "mcpServers": {
    "waiaas": {
      "command": "npx",
      "args": ["-y", "@waiaas/mcp"],
      "env": {
        "WAIAAS_BASE_URL": "http://127.0.0.1:3100",
        "WAIAAS_SESSION_TOKEN": "wai_sess_<your-token>",
        "WAIAAS_DATA_DIR": "~/.waiaas"
      }
    }
  }
}

That's it. Restart Claude Desktop, and Claude can now call any of the 45 MCP tools. It can check balances, send tokens, execute swaps on Jupiter, manage Aave positions, stake with Lido or Jito, bridge via LI.FI or Across, and more — all from natural language instructions in the chat window.

The transport is stdio, which means no network ports are opened for the MCP connection itself. The MCP process talks to your local WAIaaS daemon over HTTP on 127.0.0.1:3100, which is bound to localhost only by default (fact DOCKER-02).

Getting the Daemon Running First

Before Claude can use the tools, you need the daemon running. The fastest path:

Step 1 — Install the CLI and initialize:

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

The --auto-provision flag generates a random master password and writes it to recovery.key. No password prompt on startup — useful for getting started quickly. You can harden it later with waiaas set-master.

Step 2 — Create wallets and sessions in one command:

waiaas quickset --mode mainnet

This creates wallets and MCP-ready session tokens in a single step. The CLI prints the MCP config JSON — paste it into your Claude Desktop config, or use:

waiaas mcp setup --all

...to auto-register all wallets with Claude Desktop automatically.

Step 3 — Add the MCP config and restart Claude Desktop.

That's the whole setup. Three commands, one config edit.

Alternatively, if you prefer Docker:

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

The Docker image (waiaas/daemon:latest) includes auto-provision support, Docker Secrets integration for production deployments, a healthcheck, and runs as a non-root user (UID 1001). The compose file binds to 127.0.0.1:3100:3100 by default, keeping the daemon local.

How Gas-Conditional Execution Works in Practice

The gas conditional execution feature (FEAT-GAS) sits inside WAIaaS's 7-stage transaction pipeline: validate → auth → policy → wait → execute → confirm. The gas condition check happens in the wait stage. If the current gas price exceeds your configured threshold, the transaction queues and waits. Once gas drops to an acceptable level, execution proceeds automatically.

From Claude's perspective, the interaction is simple. Claude calls the send or DeFi action tool, the transaction enters the pipeline, and Claude can query the transaction status later. The waiting happens server-side. Claude doesn't need to implement any retry logic or gas-checking loops.

Here's what that looks like from the REST API side (which the MCP tools wrap):

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

Before you execute anything for real, you can simulate it:

curl -X POST http://127.0.0.1:3100/v1/transactions/send \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer wai_sess_<token>" \
  -d '{
    "type": "TRANSFER",
    "to": "recipient-address",
    "amount": "0.1",
    "dryRun": true
  }'

The dry-run API (FEAT-DRYRUN) lets Claude (or you) validate a transaction's expected outcome before committing gas. For a DeFi agent running strategies autonomously, this is a useful safety check before any significant action.

The Policy Layer: What Claude Is and Isn't Allowed to Do

Giving Claude a wallet without guardrails is a bad idea. WAIaaS has a policy engine with 21 policy types and 4 security tiers — INSTANT, NOTIFY, DELAY, and APPROVAL — enforced on every transaction the agent attempts.

The default-deny behavior is important: transactions are blocked unless explicitly allowed. An agent without a CONTRACT_WHITELIST policy can't call arbitrary contracts. Without ALLOWED_TOKENS, it can't transfer arbitrary tokens. You define exactly what Claude can touch.

For a gas-conditional DeFi setup, a sensible starting policy set 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
    }
  }'

With this configuration:

Transactions under $100 execute immediately (INSTANT)
$100–$500 execute but you get notified (NOTIFY)
$500–$2,000 queue for 15 minutes before executing, giving you time to cancel (DELAY)
Over $2,000 requires your explicit approval via WalletConnect or Telegram (APPROVAL)

The WalletConnect integration (FEAT-WC) is how you approve transactions from your phone when Claude requests something above your DELAY threshold. Claude submits the transaction, it lands in a pending state, and you get a WalletConnect prompt to approve or reject it.

There are also DeFi-specific policy types worth knowing about for this use case:

PERP_MAX_LEVERAGE — caps the leverage Claude can use on Hyperliquid perpetuals
PERP_MAX_POSITION_USD — caps absolute position size
LENDING_LTV_LIMIT — prevents Claude from borrowing against collateral at dangerous ratios on Aave
VENUE_WHITELIST — restricts which protocols Claude can interact with
ACTION_CATEGORY_LIMIT — limits DeFi action categories (e.g., allow swaps but not perpetuals)

These aren't just nice-to-haves. For a gas-conditional agent that executes while you're asleep, they're the guardrails that keep a strategy from going sideways.

The 15 DeFi Protocols Claude Can Access

Once your MCP session is configured and policies are set, Claude has access to 15 integrated DeFi protocol providers:

Swaps: Jupiter (Solana), 0x, D'CENT swap, LI.FI

Lending: Aave v3, Kamino, Pendle

Staking: Lido (EVM liquid staking), Jito (Solana)

Perpetuals: Hyperliquid (perps, spot, sub-accounts), Drift

Bridging: LI.FI, Across

Prediction markets: Polymarket

DEX: XRPL DEX

Onchain agent reputation: ERC-8004

For example, to execute a Jupiter swap (Solana), Claude calls the action-provider tool which maps to:

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

Claude can also query DeFi positions across protocols using the get-defi-positions tool — useful for portfolio-aware agents that need to understand their current exposure before taking action.

Multi-Wallet Setup for Strategy Isolation

If you're running multiple strategies, you probably want them isolated in separate wallets with separate policies. WAIaaS supports this with per-wallet sessions and per-wallet policy sets.

The MCP config supports multiple named servers pointing to different wallets on the same daemon:

{
  "mcpServers": {
    "waiaas-trading": {
      "command": "npx",
      "args": ["-y", "@waiaas/mcp"],
      "env": {
        "WAIAAS_BASE_URL": "http://127.0.0.1:3100",
        "WAIAAS_AGENT_ID": "019c47d6-51ef-7f43-a76b-d50e875d95f4",
        "WAIAAS_AGENT_NAME": "trading-agent",
        "WAIAAS_DATA_DIR": "~/.waiaas"
      }
    },
    "waiaas-solana": {
      "command": "npx",
      "args": ["-y", "@waiaas/mcp"],
      "env": {
        "WAIAAS_BASE_URL": "http://127.0.0.1:3100",
        "WAIAAS_AGENT_ID": "019c4cd2-86e8-758f-a61e-9c560307c788",
        "WAIAAS_AGENT_NAME": "solana-wallet",
        "WAIAAS_DATA_DIR": "~/.waiaas"
      }
    }
  }
}

Two MCP servers, two wallets, two independent policy sets. Claude Desktop sees both as separate tool namespaces. Each wallet's session has its own TTL, renewal limits, and policy configuration — defined at session creation time (fact SEC-04).

What the Full Setup Looks Like

To recap the end-to-end picture:

WAIaaS daemon runs locally (Docker or CLI), manages wallets, enforces policies, executes the 7-stage transaction pipeline including gas condition checks
MCP server (@waiaas/mcp) connects Claude Desktop to the daemon via stdio, exposing 45 tools
Claude receives natural language instructions, selects the appropriate MCP tool, and submits the action
Policy engine validates the action against your 21 configured policy types before anything hits the chain
Gas condition holds the transaction in the wait stage until gas price meets your threshold
Signing channels notify you (Push, Telegram, WalletConnect) when human approval is needed

The agent does the reasoning. The infrastructure does the enforcement. You stay in control of what the agent is allowed to do and when transactions actually execute.

What's Next

The WAIaaS codebase is open source and actively developed — the monorepo has 15 packages, 684+ test files, and covers EVM and Solana across 18 networks. If you want to dig into the policy engine in detail, the OpenAPI spec and interactive reference UI are available at http://127.0.0.1:3100/doc and /reference once your daemon is running.

Star the repo, try the quickstart, and open an issue if you hit anything unexpected.

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

21 Policy Types for AI Agent Security: Machine Learning Meets Crypto Risk Management

Wallet Guy — Fri, 09 Oct 2026 13:27:49 +0000

21 Policy Types for AI Agent Security: How WAIaaS Puts Guardrails on Crypto Wallets

Giving an AI agent a wallet without guardrails is like giving a toddler a credit card — the intent might be good, but the outcomes can be catastrophic. AI agent security in crypto is not a solved problem, and most developers building autonomous on-chain agents are one misconfigured prompt away from watching their funds disappear. WAIaaS is an open-source, self-hosted Wallet-as-a-Service that approaches this problem seriously: default-deny policies, 3-layer authentication, and explicit human approval channels sit between your agent and your funds at all times.

The Real Risk of Autonomous Agents with Wallets

Autonomous AI agents are increasingly useful for on-chain tasks — arbitrage, yield farming, portfolio rebalancing, paying for API access. But the moment an agent has signing authority over a wallet, you have created a new attack surface. The agent can be manipulated through prompt injection. A bug in your logic can trigger unintended transactions. A compromised session token can be replayed. And unlike a web app where a bad action might corrupt a database you can restore, an on-chain transaction is final.

The security question is not "do you trust your AI?" — it is "what is the blast radius if it goes wrong?" Good security design answers that question before anything gets deployed.

WAIaaS answers it with three concrete layers: authentication controls who can issue commands, a policy engine controls what those commands are allowed to do, and a human approval channel controls whether high-risk actions actually execute. Let's walk through each.

Layer 1: Three Authentication Methods, Three Principals

WAIaaS separates concerns across three distinct principals, each with its own authentication method:

# 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 master password (hashed with Argon2id) is a system-level credential used only to create wallets, configure policies, and manage sessions. Your AI agent never sees it.

The session token (JWT HS256) is what your agent actually uses. It is scoped to a single wallet, carries a TTL, a maximum renewal count, and an absolute lifetime ceiling. If the token is compromised, the blast radius is bounded — the attacker cannot create new wallets, cannot modify policies, and cannot approve their own transactions.

The owner authentication (Ed25519 or secp256k1 signature from the fund owner's wallet) is the kill switch and approval channel. It cannot be faked by the agent. It requires the actual owner to sign a message with their private key, which means it requires a human being.

This separation is not cosmetic. It means that a fully compromised agent session still cannot drain funds beyond what the policy engine allows, and still cannot approve its own high-value transactions.

Layer 2: The Policy Engine — 21 Types, 4 Tiers, Default-Deny

This is the core of WAIaaS security. The policy engine enforces rules on every transaction before it executes, and it is default-deny: if you have not explicitly configured ALLOWED_TOKENS or CONTRACT_WHITELIST, transactions that involve tokens or contracts are blocked.

There are 21 policy types organized around different risk vectors:

SPENDING_LIMIT          — Amount-based 4-tier security
WHITELIST               — Allowed recipient addresses
TIME_RESTRICTION        — Allowed transaction hours
RATE_LIMIT              — Max transactions per period
ALLOWED_TOKENS          — Token transfer whitelist (default-deny)
CONTRACT_WHITELIST      — Contract call whitelist (default-deny)
METHOD_WHITELIST        — Allowed function selectors
APPROVED_SPENDERS       — Token approval whitelist (default-deny)
APPROVE_AMOUNT_LIMIT    — Max approve amount, block unlimited
APPROVE_TIER_OVERRIDE   — Force tier for APPROVE transactions
ALLOWED_NETWORKS        — Network restriction
X402_ALLOWED_DOMAINS    — x402 payment domain whitelist
LENDING_LTV_LIMIT       — Max loan-to-value ratio for DeFi lending
LENDING_ASSET_WHITELIST — Allowed lending assets
PERP_MAX_LEVERAGE       — Max perpetual futures leverage
PERP_MAX_POSITION_USD   — Max position size in USD
PERP_ALLOWED_MARKETS    — Allowed perpetual markets
REPUTATION_THRESHOLD    — ERC-8004 onchain reputation threshold
ERC8128_ALLOWED_DOMAINS — ERC-8128 HTTP signing domains
VENUE_WHITELIST         — Allowed trading venues
ACTION_CATEGORY_LIMIT   — DeFi action category limits

The Spending Limit: Four Tiers of Risk

The SPENDING_LIMIT policy is the most fundamental control. It maps transaction amounts to four security tiers:

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

Here is how you create a 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": 100,
      "notify_max_usd": 500,
      "delay_max_usd": 2000,
      "delay_seconds": 900,
      "daily_limit_usd": 5000
    }
  }'

With this configuration: a $50 transfer goes through immediately. A $300 transfer goes through but you get a notification. A $1,200 transfer is queued for 15 minutes — giving you a window to cancel it if it was a mistake or an attack. A $3,000 transfer requires you to explicitly approve it with your owner signature. Nothing above $5,000 in a single day executes regardless of tier.

This is not a vague "security feature." It is a precise, auditable rule that you can reason about.

Default-Deny Token Whitelist

One of the most important policies is ALLOWED_TOKENS. Without it configured, your agent cannot transfer tokens — any token transfer is blocked by default. You must explicitly declare which tokens the agent is permitted to move:

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

Same logic applies to CONTRACT_WHITELIST (which contracts the agent can call), APPROVED_SPENDERS (which addresses the agent can grant token approvals to), and ALLOWED_NETWORKS (which chains the agent can operate on at all).

The default-deny posture means you are opting in to capabilities, not opting out of risks. That is the correct direction for security design.

DeFi-Specific Risk Controls

WAIaaS integrates 15 DeFi protocols including Aave v3, Hyperliquid, Jupiter, Kamino, and Pendle. Each category of DeFi activity has specific policy controls:

LENDING_LTV_LIMIT caps the loan-to-value ratio for lending positions, preventing your agent from over-leveraging collateral on Aave or Kamino.
PERP_MAX_LEVERAGE and PERP_MAX_POSITION_USD bound perpetual futures exposure on Hyperliquid and Drift — an agent cannot open a 50x leveraged position if you have capped leverage at 5x.
PERP_ALLOWED_MARKETS restricts which perpetual markets the agent can trade, so an agent configured for BTC/USD perpetuals cannot suddenly start trading illiquid altcoin contracts.
VENUE_WHITELIST restricts which DEXes or trading venues the agent can route through.
ACTION_CATEGORY_LIMIT lets you set rate limits per DeFi action category — for example, limiting how many lending actions can occur per day regardless of individual amounts.

Approve Transaction Controls

Token approvals (APPROVE) are one of the most exploited mechanisms in DeFi. APPROVE_AMOUNT_LIMIT blocks the agent from issuing unlimited token approvals — a common attack vector where a malicious contract drains all of a token indefinitely. APPROVE_TIER_OVERRIDE lets you force all approval transactions to require human sign-off regardless of the dollar amount, which is a sensible default for most setups.

x402 and HTTP Payment Policies

WAIaaS supports the x402 HTTP payment protocol, which lets agents automatically pay for API calls. X402_ALLOWED_DOMAINS is a whitelist of domains the agent is permitted to pay automatically. Without this policy configured, the agent cannot make x402 payments to any domain. With it, you can allow *.openai.com and api.example.com while blocking everything else.

Layer 3: Human Approval Channels

When a transaction hits the APPROVAL tier — either by exceeding spending limits or by matching a policy that always requires approval — it is queued and waits. The owner must actively approve it. WAIaaS supports three signing channels for this: push relay, Telegram, and WalletConnect notification.

Approving a pending transaction looks like this:

curl -X POST http://127.0.0.1:3100/v1/transactions/<tx-id>/approve \
  -H "X-Owner-Signature: <ed25519-or-secp256k1-signature>" \
  -H "X-Owner-Message: <signed-message>"

This requires a cryptographic signature from the owner's key. It cannot be spoofed by the agent. It cannot be automated away. A human being with access to the owner's private key must sign the approval message. The delay tier works similarly — transactions are queued for delay_seconds and then execute automatically, but they can be cancelled during that window if you catch something wrong.

The Transaction Pipeline

Every transaction — regardless of type — passes through a 7-stage pipeline before execution: validate, auth, policy, wait, execute, confirm. The policy stage runs after authentication and before any waiting or execution, which means a policy violation is caught early and returns an error immediately:

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

There is also a dry-run mode for simulating transactions before committing them — useful for testing policy configurations without moving real funds:

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

And there is gas conditional execution — transactions can be configured to execute only when gas price meets a threshold, preventing your agent from sending transactions during fee spikes.

Quick Start: Deploying a Secured Agent Wallet

Here is the minimal path to a secured agent wallet:

Step 1: Start WAIaaS

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

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": "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: Configure a 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": 100,
      "notify_max_usd": 500,
      "delay_max_usd": 2000,
      "delay_seconds": 900,
      "daily_limit_usd": 5000
    }
  }'

Step 4: Configure allowed tokens (remember: default-deny)

Set an ALLOWED_TOKENS policy listing every token your agent is permitted to transfer. Without this, token transfers are blocked.

Step 5: Give the session token to your agent, keep the master password out of it

Your agent gets wai_sess_<token>. Your master password stays in your environment config, never in the agent's context.

What's Next

The Admin Web UI at /admin provides a visual policy editor and DeFi positions dashboard if you prefer not to manage policies through the REST API. For integrating with Claude or other MCP-compatible AI agents, waiaas mcp setup --all registers all wallets automatically and gives you a ready-to-paste Claude Desktop config.

Explore the full codebase and self-host your own instance at github.com/waiaas/WAIaaS, and read the full documentation at waiaas.ai. Security questions and contributions are welcome — this is open source, and the policy engine behavior is auditable in the code.

Auto-Updating Self-Hosted Crypto Wallets: Watchtower + GHCR Production Setup

Wallet Guy — Thu, 08 Oct 2026 19:15:55 +0000

Auto-Updating Self-Hosted Crypto Wallets: Watchtower + GHCR Production Setup

Self-hosting your AI agent's wallet infrastructure means you never have to ask: "Who actually controls these private keys?" If you've been running homelab services for a while, you already know the value of owning your stack. This guide walks through a production-ready WAIaaS deployment with automatic Docker image updates via Watchtower and GitHub Container Registry (GHCR) — so you get the control of self-hosting without the maintenance burden of manual updates.

Why Self-Hosting Your Agent's Wallet Actually Matters

When an AI agent moves real money — swapping tokens, paying for API calls, interacting with DeFi protocols — the custody question isn't academic. Hosted wallet services mean someone else's server holds the keys, enforces the rate limits, and logs the transactions. That's a reasonable trade-off for prototyping, but it's a meaningful one.

Running WAIaaS on your own hardware means your keys stay on your hardware. The daemon runs locally, the database lives in a named Docker volume you control, and nothing phones home unless you've configured an RPC endpoint that does. It's the crypto equivalent of running your own email server — except WAIaaS has a one-command quick start, so it's actually practical.

The production concern that kills most self-hosted setups isn't the initial deployment — it's the update treadmill. Security patches, new DeFi integrations, bug fixes: staying current manually is tedious. That's where Watchtower comes in.

What You're Building

By the end of this guide you'll have:

WAIaaS daemon running in Docker, bound to 127.0.0.1:3100 (not exposed to the internet)
Automatic image updates pulling from ghcr.io/waiaas/waiaas:latest
Production secrets managed via Docker Secrets (no passwords in environment variables)
A healthcheck that restarts the container if the daemon goes unresponsive

The full WAIaaS stack is a 15-package monorepo with a 7-stage transaction pipeline, 21 policy types, and 45 MCP tools for AI agent integration. You don't need to understand all of that to run it — but it's good to know the depth is there when you need it.

Step 1: Clone and Understand the Compose File

git clone https://github.com/waiaas/WAIaaS.git
cd WAIaaS

The repository ships with a docker-compose.yml that's already production-shaped. Here's what it looks like, annotated:

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

volumes:
  waiaas-data:
    driver: local

A few things worth noting for the self-hoster:

Port binding is localhost-only. 127.0.0.1:3100:3100 means the API is not reachable from outside the host. If you want to access it from another machine, you handle that at the reverse-proxy layer (nginx, Caddy, Tailscale) — not by changing this binding to 0.0.0.0.

Named volume, not a bind mount. waiaas-data is managed by Docker, which keeps things clean. Your wallet data, session tokens, and configuration survive container restarts and image updates. docker compose down preserves the volume; docker compose down -v deletes it — don't run the latter in production.

Healthcheck is built in. The daemon exposes /health, and Docker will automatically restart the container if it stops responding. No external monitoring required for basic uptime.

Step 2: First Boot with Auto-Provision

For a first deployment, auto-provision is the cleanest path. It generates a random master password and writes it to /data/recovery.key inside the container:

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

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

Save that password somewhere secure (a password manager, not a sticky note). Once you've noted it, you can harden the setup using waiaas set-master from the CLI if you have it installed, then delete the recovery key file.

For most homelab setups, the CLI-based flow is even cleaner:

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) Harden password, then delete recovery.key

The CLI has 20 commands covering everything from backup create to wallet info. The quickset command is particularly useful — it creates wallets and MCP sessions in one step, printing the Claude Desktop config JSON you can paste directly.

Step 3: Production Secrets (No Passwords in Environment Variables)

Environment variables are convenient but they leak into docker inspect, process lists, and log aggregators. For a production self-hosted setup, Docker Secrets are the right tool.

WAIaaS ships a docker-compose.secrets.yml overlay for exactly this purpose:

# 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 entrypoint script in the Docker image handles reading from Docker Secrets automatically — that's a built-in capability of the entrypoint, not something you need to wire up yourself.

Step 4: Watchtower for Automatic Updates

This is the part that makes self-hosting sustainable. Watchtower watches your running containers, checks their registries for new image versions, and performs rolling updates automatically.

Add Watchtower to your compose file:

services:
  daemon:
    image: ghcr.io/waiaas/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
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3100/health"]
      interval: 30s
      timeout: 5s
      start_period: 10s
      retries: 3

  watchtower:
    image: containrrr/watchtower
    container_name: watchtower
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - WATCHTOWER_CLEANUP=true
      - WATCHTOWER_POLL_INTERVAL=86400
    restart: unless-stopped

volumes:
  waiaas-data:
    driver: local

WATCHTOWER_POLL_INTERVAL=86400 checks for updates once a day. WATCHTOWER_CLEANUP=true removes old image layers after updating, keeping your disk tidy.

The WAIaaS image pulls from ghcr.io/waiaas/waiaas:latest (GitHub Container Registry), which is public and doesn't require authentication for pulls. Watchtower will detect new pushes to that tag and update your local container automatically — with a graceful restart that preserves the named volume and all your wallet data.

If you'd rather pin to a specific version and update manually, swap :latest for a specific tag. That's a reasonable choice if you want to review release notes before updating a production wallet daemon.

Step 5: Configure Your RPC Endpoints

By default, WAIaaS needs RPC endpoints to talk to blockchain networks. The key environment variables:

WAIAAS_RPC_SOLANA_MAINNET=<url>         # Solana mainnet RPC endpoint
WAIAAS_RPC_EVM_ETHEREUM_MAINNET=<url>   # Ethereum mainnet RPC endpoint

Put these in a .env file in your project directory (it's in .gitignore by default). The daemon supports 2 chain types — Solana and EVM — across 18 networks total. You only need to configure the ones you're actually using.

For a privacy-conscious setup, this is where self-hosting really shines. You can point to your own RPC node, a private endpoint from a provider you trust, or a local node if you're running one. No third-party wallet service is sitting between your agent and the chain.

Step 6: Create a Wallet and Lock It Down with Policies

Once the daemon is running, create a wallet:

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

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

The agent uses the session token (wai_sess_...) for all its operations. Your master password never leaves your server.

Before letting an agent loose with real funds, set up a spending policy. The policy engine has 21 policy types with 4 security tiers (INSTANT, NOTIFY, DELAY, APPROVAL) and enforces default-deny — transactions are blocked unless explicitly permitted:

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

This single policy means: transactions under $100 execute immediately, $100–$500 execute with a notification to you, $500–$2000 are queued for 15 minutes (cancellable), and anything over $2000 requires your explicit approval via WalletConnect or Telegram.

The default-deny enforcement on ALLOWED_TOKENS and CONTRACT_WHITELIST means if you haven't explicitly whitelisted a token or contract, the transaction is denied. An agent can't spend funds on something you haven't approved.

Checking That Everything Works

# Follow logs in real time
docker compose logs -f

# Verify the healthcheck is passing
docker inspect waiaas-daemon --format='{{.State.Health.Status}}'

# Check your wallet balance from the agent's perspective
curl http://127.0.0.1:3100/v1/wallet/balance \
  -H "Authorization: Bearer wai_sess_eyJhbGciOiJIUzI1NiJ9..."

# View the interactive API reference (if you want to explore)
open http://127.0.0.1:3100/reference

The /reference endpoint serves an interactive Scalar API reference UI auto-generated from the OpenAPI 3.0 spec. There are 39 REST API route modules in total — the reference UI is the fastest way to explore them without reading source code.

The Management Commands You'll Actually Use

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 (careful)

For CLI-based management, waiaas status and waiaas wallet info cover most day-to-day checks. The waiaas backup create / waiaas backup list / waiaas restore commands handle your disaster recovery workflow.

The Architecture in Brief

What you're running is a daemon with a 7-stage transaction pipeline: validate → auth → policy → wait → execute → confirm. The policy check at stage 3 is where your spending limits, whitelists, and approval requirements get enforced. The "wait" stage handles the delay-tier queuing. Nothing reaches the chain without passing all prior stages.

The daemon supports 15 DeFi protocol integrations (Aave v3, Jupiter, Hyperliquid, Lido, Jito, and others), 45 MCP tools for connecting AI agents via Claude Desktop, and 7 transaction types (Transfer, TokenTransfer, ContractCall, Approve, Batch, NftTransfer, ContractDeploy). All of that runs in a single Docker container on your hardware.

For AI agent integration via the Model Context Protocol, the setup is a single CLI command after the daemon is running:

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

Your Keys, Your Server, Your Rules

The philosophy here is straightforward: a self-hosted wallet daemon gives you the same trust model as running your own Bitcoin node. You verify things yourself. You don't depend on a third party's uptime, pricing decisions, or data retention policies.

With Watchtower handling updates from GHCR and Docker Secrets keeping your master password out of environment variables, you get a production setup that's both sovereign and maintainable. The 684+ test files in the codebase mean updates hitting :latest have been through a real test suite before you pull them.

The full source is at https://github.com/waiaas/WAIaaS — worth reading the Docker entrypoint and compose files yourself before running anything in production. And the project home with documentation is at https://waiaas.ai.

If you're already comfortable self-hosting services, the hardest part of this setup is probably choosing which DeFi protocols to whitelist — not the deployment itself.

Automated Yield Strategy Bots: Pendle + Kamino + Lido Cross-Chain Optimization

Wallet Guy — Thu, 08 Oct 2026 13:42:20 +0000

Automated Yield Strategy Bots: Pendle + Kamino + Lido Cross-Chain Optimization

Building a DeFi yield optimization bot means wiring together Pendle for fixed-rate yield, Kamino for Solana liquidity, and Lido for liquid staking — and doing that across both EVM and Solana chains in a single coherent strategy. Most developers end up with a graveyard of half-finished protocol SDKs, inconsistent error handling, and fragile RPC logic before they even write the first line of strategy code. WAIaaS gives you one unified API across 15 DeFi protocols and 18 networks so you can focus on the strategy, not the plumbing.

The Real Problem: Protocol Fragmentation

Cross-chain yield optimization isn't conceptually hard. The idea is simple: find the best risk-adjusted yield available, rotate capital toward it, and hedge where needed. Pendle lets you strip fixed yield from yield-bearing tokens. Kamino concentrates liquidity on Solana for boosted LP returns. Lido gives you stETH so your staked ETH keeps earning while you deploy it elsewhere.

The implementation is hard because each of those protocols has its own SDK, its own transaction format, its own RPC requirements, and its own quirks. Add in cross-chain bridging via LI.FI or Across, and you're now managing async state across multiple chains simultaneously. A bot that sounds like a weekend project turns into a months-long integration effort — before you've written a single line of strategy logic.

The stakes are real. Yield optimization bots that can't react quickly to rate changes leave basis points on the table. Bots that have brittle multi-SDK setups go down at the worst moments. And bots that don't have proper policy guardrails can drain a wallet on a bad parameter.

One API Across 15 Protocols

WAIaaS integrates 15 DeFi protocol providers: aave-v3, across, dcent-swap, drift, erc8004, hyperliquid, jito-staking, jupiter-swap, kamino, lido-staking, lifi, pendle, polymarket, xrpl-dex, and zerox-swap. That's the full stack for a cross-chain yield strategy — Lido and Aave on EVM, Kamino and Jito on Solana, Pendle for fixed yield, LI.FI or Across for bridging — all behind a single REST API running locally at 127.0.0.1:3100.

The architecture is straightforward. You spin up the WAIaaS daemon (one Docker container), create wallets for each chain, create session tokens for your bot, set spending policies, and then call the action API. Every DeFi operation goes through the same endpoint pattern:

POST /v1/actions/<provider>/<action>
Authorization: Bearer wai_sess_<token>

Your bot doesn't need to know about Kamino's SDK, Pendle's contract ABI, or Lido's submit method. It just speaks REST.

Structuring a Cross-Chain Yield Bot

Here's how you'd architect a Pendle + Kamino + Lido optimization bot using WAIaaS.

Step 1: Separate wallets per chain. You want an EVM wallet for Lido/Pendle/Aave and a Solana wallet for Kamino/Jito/Jupiter. Each wallet gets its own session token. Your strategy engine holds both tokens and routes actions to the right one.

Step 2: Policy first, strategy second. Before your bot executes anything, define the guardrails. A spending limit policy with a daily cap, an allowed tokens whitelist, and a contract whitelist prevents a strategy bug from becoming a catastrophic loss.

# Create spending limit on the EVM wallet
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": "<evm-wallet-uuid>",
    "type": "SPENDING_LIMIT",
    "rules": {
      "instant_max_usd": 100,
      "notify_max_usd": 1000,
      "delay_max_usd": 10000,
      "delay_seconds": 900,
      "daily_limit_usd": 50000
    }
  }'

Transactions above $10,000 will queue for 15 minutes before executing. Transactions above the daily limit get blocked entirely. This isn't optional safety theater — it's the difference between a recoverable bug and a drained wallet.

The policy engine supports 21 policy types. For a yield bot specifically, LENDING_LTV_LIMIT is critical: it caps the loan-to-value ratio your bot can reach on Aave or Kamino lending. LENDING_ASSET_WHITELIST ensures the bot can only supply or borrow approved assets. CONTRACT_WHITELIST enforces that only known protocol contracts can be called.

Step 3: Check positions before acting. Your strategy loop should start by reading the current state. WAIaaS exposes DeFi positions across protocols through a single call that returns lending positions, staking balances, and LP positions.

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

Step 4: Execute the strategy actions. Here's where the unified API pays off. Lido staking, a Jupiter swap on Solana, and a Kamino deposit all follow the same pattern — you just change the provider name.

# Stake ETH via Lido
curl -X POST http://127.0.0.1:3100/v1/actions/lido-staking/stake \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer wai_sess_<evm-token>" \
  -d '{
    "amount": "1.0",
    "network": "ethereum-mainnet"
  }'

# Swap SOL → USDC via Jupiter before depositing to Kamino
curl -X POST http://127.0.0.1:3100/v1/actions/jupiter-swap/swap \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer wai_sess_<solana-token>" \
  -d '{
    "inputMint": "So11111111111111111111111111111111111111112",
    "outputMint": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
    "amount": "1000000000"
  }'

For Pendle, you're interacting with yield token markets — buying PT (principal tokens) to lock in a fixed rate, or LP'ing to earn trading fees. For cross-chain rebalancing, you'd route through LI.FI or Across depending on which bridge offers better rates for that specific route.

Dry-Run Before Every Rebalance

Any strategy that moves meaningful capital should simulate before executing. WAIaaS has a dry-run flag on every transaction:

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

Pass "dryRun": true and the request runs through the full 7-stage transaction pipeline — validation, auth check, policy evaluation, gas estimation — but stops before broadcasting. You get back exactly what would happen, including any policy denial, without committing to the chain. For a yield bot that's rebalancing every few hours, this is how you validate the move before making it.

The TypeScript SDK for Strategy Code

If you're writing your strategy engine in TypeScript rather than shelling out to curl, the @waiaas/sdk package wraps the REST API cleanly:

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

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

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

// Check balances on both chains before deciding where to rotate yield
const [evmBalance, solanaBalance] = await Promise.all([
  evmClient.getBalance(),
  solanaClient.getBalance(),
]);

console.log(`EVM: ${evmBalance.balance} ${evmBalance.symbol}`);
console.log(`Solana: ${solanaBalance.balance} ${solanaBalance.symbol}`);

Error handling is typed and consistent across every protocol:

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

    if (error.code === 'POLICY_DENIED') {
      // Strategy tried to exceed spending limit — log and skip this cycle
    }
  }
}

The SDK covers getBalance(), getAddress(), getAssets(), sendToken(), getTransaction(), listTransactions(), signTransaction(), and x402Fetch() — enough to build a complete strategy loop without touching the raw REST API at all. A Python SDK (pip install waiaas) is also available with async/await support for teams that prefer Python for quant work.

Gas-Conditional Execution

Yield optimization on EVM is heavily gas-sensitive. Rebalancing a Pendle position during a gas spike can wipe out days of yield. WAIaaS has a gas conditional execution feature that holds a transaction until the gas price meets a threshold — the transaction queues and executes automatically when conditions are met, without your bot needing to poll.

This is particularly useful for Lido staking operations and Aave supply/withdraw calls that don't need to happen in the same block they're triggered — you set the gas threshold and let the daemon handle the timing.

Human-in-the-Loop for Large Moves

For rebalancing moves above a certain size — say, bridging $50k from EVM to Solana via Across — you probably want a human to approve before execution. The policy engine's APPROVAL tier combined with WalletConnect integration handles this:

# Approve a pending transaction (ownerAuth via WalletConnect or Telegram)
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>"

When a transaction hits the APPROVAL tier, the daemon sends a push notification through the configured signing channel (push relay, Telegram, or WalletConnect). The fund owner reviews and signs on their phone. The bot waits. Once approved, execution continues automatically.

This is how you build a yield bot that scales to serious capital: the bot handles the analysis and routine operations autonomously, but large moves require a human signature.

Quick Start: From Zero to Running Strategy

1. Start the daemon

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

2. Create wallets and sessions via CLI

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

This creates wallets across chains and outputs MCP session config in one step. For programmatic setup, use the REST API directly:

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

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

3. Set policies before funding

Configure SPENDING_LIMIT, ALLOWED_TOKENS, CONTRACT_WHITELIST, and LENDING_LTV_LIMIT before sending any capital to the wallet. The policy engine is default-deny: transactions to contracts not on the whitelist are blocked automatically.

4. Install the SDK and write your strategy

npm install @waiaas/sdk

Your strategy loop calls getBalance() → evaluate yield opportunities → dry-run the rebalance → execute if simulation passes.

5. Explore the interactive API docs

open http://127.0.0.1:3100/reference

The interactive Scalar API reference at /reference documents all 39 REST API route modules with live request/response examples. It's the fastest way to explore what's available for a specific protocol before writing code.

What's Next

The 15 DeFi protocol integrations in WAIaaS cover the most common yield strategies, but the architecture is built for composition — Pendle PT positions hedged with Hyperliquid perps, Kamino LP positions funded via Jupiter swaps, Lido stETH bridged to Solana via Across. The policy engine with 21 policy types gives you the guardrails to run those strategies with real capital.

Explore the full codebase and open issues on GitHub at https://github.com/waiaas/WAIaaS, and see the complete documentation and protocol coverage at https://waiaas.ai.

Claude Desktop Checks AI Reputation: MCP Tools for ERC-8004 Trustless Agent Validation

Wallet Guy — Wed, 07 Oct 2026 19:19:19 +0000

Claude Desktop Checks AI Reputation: MCP Tools for ERC-8004 Trustless Agent Validation

MCP tools are the fastest way to give your Claude agent onchain superpowers — and with WAIaaS, you can add not just a wallet and DeFi access, but also the ability to verify the reputation of other AI agents before trusting them with anything valuable. One config entry. Forty-five tools. And two of them let your agent check whether another agent has earned the right to interact with it onchain.

The Problem: Your Agent Can't Tell Who It's Dealing With

As AI agents proliferate, they're increasingly interacting with each other — one agent delegating to another, one service calling another service's agent interface, one autonomous system handing off a transaction to a specialized bot. That's exciting. It's also a trust problem nobody has fully solved yet.

How does your agent know the other agent it's handing money to is legitimate? How does it verify reputation without a centralized registry you have to trust blindly? If you're building multi-agent workflows in Claude Desktop, this is going to become your problem sooner than you think.

ERC-8004 is one answer. It's a standard for onchain agent reputation and validation — a way to record, query, and verify an agent's track record directly on the blockchain, no middleman required. WAIaaS integrates ERC-8004 as part of its MCP server, which means your Claude agent can query agent reputation and validation status just like it checks a wallet balance or executes a swap.

Why Onchain Reputation Matters for Autonomous Agents

Think about what your agent is being asked to do. If it's a trading bot, it's moving real money. If it's a DeFi manager, it's approving token spend limits, opening lending positions, setting leverage. If it's part of a multi-agent system, it may receive instructions from upstream agents it didn't choose.

In that context, "I received a transaction request from another agent" is a security event, not just an input. You want to know: has this agent been validated? What's its reputation score? Is it above the threshold you've configured?

WAIaaS provides three things that work together here:

ERC-8004 MCP tools — so Claude can query agent info and reputation directly
REPUTATION_THRESHOLD policy — so you can enforce a minimum reputation score at the transaction pipeline level
Default-deny policy enforcement — so nothing goes through unless it's explicitly allowed

The combination means you can build Claude workflows where your agent actively checks who it's dealing with before executing anything sensitive.

One Line in Your Config

Let's start at the beginning. Adding WAIaaS to Claude Desktop is a single config entry:

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

Paste that into ~/Library/Application Support/Claude/claude_desktop_config.json, restart Claude Desktop, and your agent now has access to 45 MCP tools — including erc8004-get-agent-info, erc8004-get-reputation, and erc8004-get-validation-status.

If you haven't set up the daemon yet, the CLI quickstart gets you there in under two minutes:

npm install -g @waiaas/cli
waiaas init
waiaas start
waiaas quickset --mode mainnet
waiaas mcp setup --all

waiaas mcp setup --all auto-registers all your wallets and prints the MCP config JSON directly. Copy, paste, done.

The Three ERC-8004 Tools

Once WAIaaS is connected as an MCP server, Claude has three tools specifically for agent reputation:

erc8004-get-agent-info — Retrieves the onchain profile of an agent by address. Use this when your agent receives a delegation request, an inbound transaction, or a message claiming to be from a specific agent. Before acting on it, ask: who actually is this?

erc8004-get-reputation — Returns the reputation score for an agent address. This is the quantitative signal — a number derived from onchain activity that reflects the agent's track record.

erc8004-get-validation-status — Returns whether the agent has passed validation according to the ERC-8004 standard. Validation is a harder gate than reputation score — it's a binary pass/fail based on the protocol's criteria.

In practice, Claude can chain these together in a workflow:

User: "I received a delegation request from agent 0xABCD...1234. Should I accept?"
→ Claude calls erc8004-get-agent-info → retrieves agent profile
→ Claude calls erc8004-get-reputation → checks reputation score
→ Claude calls erc8004-get-validation-status → checks validation pass/fail
→ Claude summarizes: "This agent has [score] reputation and [passed/failed] validation. Here's what I found..."

No custom code. No API wrappers. Just the tools that are already there.

Enforcing Reputation at the Policy Layer

The MCP tools let your agent query reputation. The policy engine lets you enforce it — automatically, before any transaction executes.

WAIaaS has a 21-type policy engine with a 4-tier security model (INSTANT, NOTIFY, DELAY, APPROVAL) and default-deny enforcement. One of those 21 types is REPUTATION_THRESHOLD — and it does exactly what it sounds like: transactions from agents below a configured reputation threshold are blocked at the pipeline level, before they reach execution.

Here's how you create that policy:

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

Layer a REPUTATION_THRESHOLD policy on top, and your wallet won't execute transactions from agents that haven't met the bar — even if Claude is willing to try. The pipeline enforces it independently.

This matters because it separates concerns cleanly. Claude makes decisions. The policy engine enforces constraints. The two don't need to agree for the constraint to hold — the policy engine runs regardless of what the agent wants to do.

The Full Security Stack

ERC-8004 reputation checking is one layer. WAIaaS gives you several others that work together:

3-layer security architecture:

Session auth → time delay + approval → monitoring + kill switch

3 auth methods:

masterAuth (Argon2id) — for wallet creation, session management, policies
ownerAuth (SIWS/SIWE) — for transaction approval and kill switch recovery
sessionAuth (JWT HS256) — for your AI agent's day-to-day operations

The 7-stage transaction pipeline runs every transaction through: validate → auth → policy → wait → execute → confirm. Reputation threshold checks happen at the policy stage, before execution. If a transaction fails the reputation check, you get a structured error back:

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

(Substitute REPUTATION_THRESHOLD for SPENDING_LIMIT in the real-world case — the structure is the same.)

WalletConnect integration means large or suspicious transactions can be routed to you for manual approval on your phone, via WalletConnect. The APPROVAL security tier in the policy engine triggers this automatically.

Multi-Agent Setups: One MCP Server Per Wallet

If you're running multi-agent workflows — say, a trading agent and a separate analytics agent — you can give each its own wallet and MCP server instance:

{
  "mcpServers": {
    "waiaas-trading": {
      "command": "npx",
      "args": ["-y", "@waiaas/mcp"],
      "env": {
        "WAIAAS_BASE_URL": "http://127.0.0.1:3100",
        "WAIAAS_AGENT_ID": "019c47d6-51ef-7f43-a76b-d50e875d95f4",
        "WAIAAS_AGENT_NAME": "trading-agent",
        "WAIAAS_DATA_DIR": "~/.waiaas"
      }
    },
    "waiaas-solana": {
      "command": "npx",
      "args": ["-y", "@waiaas/mcp"],
      "env": {
        "WAIAAS_BASE_URL": "http://127.0.0.1:3100",
        "WAIAAS_AGENT_ID": "019c4cd2-86e8-758f-a61e-9c560307c788",
        "WAIAAS_AGENT_NAME": "solana-wallet",
        "WAIAAS_DATA_DIR": "~/.waiaas"
      }
    }
  }
}

Each agent gets its own session token, its own spending limits, its own reputation threshold. They share a single daemon. The daemon handles isolation.

In this setup, if the trading agent wants to pass a task to the Solana agent, the Solana agent's policy layer can require the trading agent to have a minimum ERC-8004 reputation before accepting — enforced automatically, no extra code.

Quick Start: ERC-8004 Validation in Claude Desktop

Here's the minimal path to having Claude check agent reputation onchain:

Step 1: Install the daemon

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

Step 2: Get your MCP config

waiaas mcp setup --all

Copy the printed JSON into your Claude Desktop config file.

Step 3: Restart Claude Desktop

Your agent now has 45 tools, including erc8004-get-agent-info, erc8004-get-reputation, and erc8004-get-validation-status.

Step 4: Test it

In Claude Desktop, type:

"Use the ERC-8004 tools to check the reputation of agent address [some-address]."

Claude will call the tools, return the results, and you can build from there.

Step 5: Add a reputation policy via the API

curl http://127.0.0.1:3100/reference

Browse to the interactive API reference and create a REPUTATION_THRESHOLD policy for your wallet. Transactions from low-reputation agents will be blocked automatically from that point forward.

The Broader Picture: 45 Tools, 15 DeFi Protocols

ERC-8004 is one slice of what's available. The full MCP server ships with 45 tools across wallet management, transactions, DeFi, NFTs, and the x402 HTTP payment protocol. The 15 integrated DeFi protocols include Aave v3, Jupiter, Uniswap (via 0x), Hyperliquid, Lido, Jito, Kamino, Pendle, Polymarket, and more — accessible from Claude with natural language.

Agent reputation checking sits alongside tools like simulate-transaction (dry-run before executing), get-health-factor (check lending position health), send-batch (multiple operations in one call), and wc-connect (WalletConnect for owner approval). They're all in the same server. They all benefit from the same policy enforcement.

What's Next

Explore the full list of 45 MCP tools, the 21 policy types, and the interactive API reference at https://waiaas.ai. The source code — including the ERC-8004 provider, the MCP tools, and the policy engine — is all open source at https://github.com/waiaas/WAIaaS. If you're building multi-agent workflows where trust between agents matters, the combination of ERC-8004 MCP tools and the REPUTATION_THRESHOLD policy is the place to start.

Economic Infrastructure for AI Agents: The Missing Layer Between Code and Commerce

Wallet Guy — Wed, 07 Oct 2026 13:36:51 +0000

Economic Infrastructure for AI Agents: The Missing Layer Between Code and Commerce

AI agents will need to pay for compute, data, and API calls — and right now, there is no clean answer for how that happens. The missing piece isn't smarter models or better orchestration frameworks. It's economic infrastructure: a wallet layer that agents can operate independently, without a human holding the keys on their behalf. That gap exists today, and it's worth thinking seriously about what fills it.

Why This Actually Matters

Consider what happens when an AI agent needs to call a paid API. Today, a developer hardcodes credentials, prepays a quota, and manually tops up accounts when they run low. The agent itself has no awareness of cost, no ability to authorize a payment, and no way to operate economically on its own. It's entirely dependent on the infrastructure a human built around it.

This is fine for demos. It breaks down at scale. When you have dozens of agents running concurrently — each accessing different data providers, spinning up compute, paying for inference — the overhead of managing all that manually becomes untenable. More importantly, it creates a fundamental asymmetry: the agent can think, reason, and act, but it can't pay. It can't participate in the economy it's operating inside.

The stakes are higher than developer convenience. If autonomous agents are going to be genuinely useful — doing research, managing operations, executing strategies — they need the ability to transact. Not accounts custodied by a developer who might be asleep at 3am. Real, autonomous wallet infrastructure.

The Infrastructure That Already Exists

WAIaaS (Wallet-as-a-Service for AI Agents) is an open-source, self-hosted daemon that gives AI agents exactly this. It's not a concept or a whitepaper — it's a running service with a REST API, an MCP integration, TypeScript and Python SDKs, and a policy engine that lets you define precisely what agents are allowed to do economically.

The architecture is worth understanding because it's designed specifically for the agent use case.

Three Auth Layers, Each for a Different Principal

WAIaaS separates three different principals with different levels of trust:

masterAuth (Argon2id) — The system administrator. Creates wallets, manages sessions, configures policies. This is you, the developer, at setup time.

sessionAuth (JWT HS256) — The AI agent. This is the token you hand to the agent. It can transact, check balances, execute DeFi actions — within the limits you've defined.

ownerAuth (SIWS/SIWE) — The fund owner. Signs approvals for high-value transactions via WalletConnect or Telegram. The human in the loop, but only when the policy says they need to be.

This separation matters. The agent never needs admin credentials. It gets a scoped session token with expiry, renewal limits, and an absolute lifetime. If the token leaks or the agent misbehaves, you revoke it.

Giving an Agent a Wallet

Setup is a few API calls:

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

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

The agent gets back a wai_sess_... token. That token is the agent's economic identity. Everything it does financially flows through that session.

From the agent's perspective — whether it's a Python script, a TypeScript service, or a Claude conversation via MCP — usage looks like this:

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',
});
console.log(`Transaction: ${tx.id}`);

The agent checks its balance. It sends tokens. It polls for confirmation. This is economic participation — the agent has genuine awareness of its financial state and can act on it.

The x402 Protocol: Machines That Pay for What They Use

One of the most interesting pieces in this stack is x402 support. The x402 HTTP payment protocol is a standard where an API server responds with HTTP 402 (Payment Required) when an unauthenticated request arrives. The client — in this case, an AI agent — sees the payment terms, authorizes a micropayment, and retries the request. All automatically.

WAIaaS includes an x402-fetch tool in its 45 MCP tools and an x402Fetch() method in the SDK. An agent can call any x402-enabled API and pay for it transparently, without human intervention.

This is the mechanism that makes "agents pay for compute" real rather than hypothetical. A data provider publishes an x402 endpoint. An agent with a WAIaaS wallet calls it. The payment happens. The data is returned. No prepaid API keys, no quota management, no developer woken up at 3am to top up a balance.

The policy layer makes this safe. You can configure X402_ALLOWED_DOMAINS — a whitelist of domains the agent is permitted to pay. Payments to anything outside that list are blocked automatically.

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

The agent has autonomy within bounds you define. That's the right model.

Policy Engine: Autonomy With Guardrails

Autonomous doesn't mean uncontrolled. WAIaaS ships a policy engine with 21 policy types and 4 security tiers. Every transaction runs through a 7-stage pipeline — validate, auth, policy check, wait, execute, confirm. A transaction that doesn't pass policy never executes.

The four tiers are:

INSTANT — Execute immediately, no notification
NOTIFY — Execute immediately, send you a notification
DELAY — Queue for N seconds, then execute (you can cancel in the window)
APPROVAL — Require explicit human approval via WalletConnect or Telegram

The spending limit policy maps transaction amounts to tiers automatically:

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

Under $100: the agent moves immediately. $100-$500: it moves and you get a notification. $500-$2000: it queues for 15 minutes — you can cancel if something looks wrong. Over $2000: it waits for your explicit approval.

This is the right mental model for agent economics. Not "the agent can do anything" and not "the agent can do nothing without asking." A graduated autonomy that scales with risk. Small transactions — paying for an API call, executing a routine swap — happen without friction. Large transactions surface to the human who should be aware of them.

The policy system also includes DeFi-specific controls: PERP_MAX_LEVERAGE for perpetual futures, LENDING_LTV_LIMIT for lending protocols, PERP_MAX_POSITION_USD for position sizing, REPUTATION_THRESHOLD for ERC-8004 agent reputation validation. These aren't generic financial controls bolted onto a wallet — they're designed for agents operating in DeFi.

Default-deny enforcement means if you haven't configured ALLOWED_TOKENS or CONTRACT_WHITELIST, transactions are blocked. An agent with a fresh wallet can't do anything harmful by default. You opt into capabilities explicitly.

DeFi Access: 15 Protocols, Ready to Use

When we talk about agent economic activity, we're not just talking about sending tokens. Agents operating in DeFi need to swap, stake, lend, borrow, bridge, and trade. WAIaaS integrates 15 DeFi protocol providers directly: Aave v3, Across, D'CENT Swap, Drift, Hyperliquid, Jito Staking, Jupiter Swap, Kamino, Lido Staking, LI.FI, Pendle, Polymarket, XRPL DEX, and 0x Swap, plus ERC-8004 for onchain agent reputation.

An agent executing a Jupiter swap on Solana looks like this via the REST API:

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

The agent passes through the same 7-stage pipeline as any other transaction — policy checks, gas conditions, dry-run simulation if configured. The fact that it's a DeFi action rather than a native transfer doesn't bypass any of the safety machinery.

Critically, you can simulate any transaction before execution:

curl -X POST http://127.0.0.1:3100/v1/transactions/send \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer wai_sess_<token>" \
  -d '{
    "type": "TRANSFER",
    "to": "recipient-address",
    "amount": "0.1",
    "dryRun": true
  }'

dryRun: true runs the entire pipeline — validation, policy checks, simulation — without broadcasting. An agent can verify what a transaction will do before committing. This matters enormously for agents operating with real funds. You want to know before the fact, not after.

Connecting to AI Frameworks: MCP and OpenClaw

The most direct path to giving an existing AI agent economic capabilities is through the Model Context Protocol (MCP) integration. WAIaaS ships 45 MCP tools covering wallet operations, transactions, DeFi positions, NFTs, and x402 payments.

Setup with Claude Desktop is a single CLI command:

waiaas mcp setup --all

Or manual configuration:

{
  "mcpServers": {
    "waiaas": {
      "command": "npx",
      "args": ["-y", "@waiaas/mcp"],
      "env": {
        "WAIAAS_BASE_URL": "http://127.0.0.1:3100",
        "WAIAAS_SESSION_TOKEN": "wai_sess_<your-token>",
        "WAIAAS_DATA_DIR": "~/.waiaas"
      }
    }
  }
}

After that, Claude — or any MCP-compatible agent framework — can check balances, send tokens, query DeFi positions, and execute swaps through natural conversation. The agent isn't simulating financial capability. It has a real wallet, real funds, real transactions.

For agents built outside MCP-compatible frameworks, the OpenClaw plugin provides 5 tool categories (wallet, transfer, DeFi, NFT, utility) for integration with external AI agent frameworks.

Quick Start: From Zero to Agent Wallet in Five Minutes

If you want to see this working today rather than taking it on faith:

1. Start the daemon

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

2. Initialize and configure

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

3. Connect to Claude Desktop

waiaas mcp setup --all

4. Or use the SDK directly

npm install @waiaas/sdk

Point it at http://127.0.0.1:3100 with the session token from quickset, and you have a TypeScript client that can check balances, send tokens, and execute DeFi actions.

The daemon runs on 2 chains (Solana and EVM) across 18 networks. It exposes 39 REST API route modules, has 684+ test files, and ships as a Docker image with auto-provision, Docker Secrets support, and a non-root UID 1001 for production security hygiene.

The Bigger Picture

The conversation about AI agents usually focuses on capability: can the agent reason well, plan ahead, use tools effectively? Economic infrastructure is the missing dimension. An agent that can reason but can't transact is fundamentally limited — dependent on humans to mediate every economic interaction.

The infrastructure to change that exists today. Wallets with scoped session tokens. Policy engines that define exactly what an agent is permitted to do. x402 payment protocol support for paying API calls automatically. DeFi protocol access for agents that need to do more than just send tokens. Human approval workflows for the transactions that warrant oversight.

This isn't a vision of the future. It's working code you can run this afternoon.

What's Next

The full documentation, architecture overview, and contribution guide are on GitHub: https://github.com/waiaas/WAIaaS. If you want to understand the policy engine in depth before deploying — particularly the DeFi-specific policy types and how the 4-tier security model works in practice — the official site at https://waiaas.ai is the right starting point. The OpenAPI interactive reference at /reference on any running instance is also worth exploring — it documents all 39 route modules with live examples you can execute against your own daemon.

Dual-Language AI Agent SDK: TypeScript + Python Async APIs with Zero Dependencies

Wallet Guy — Tue, 06 Oct 2026 18:54:03 +0000

Your AI Agent Can Browse the Web. Can It Swap Tokens?

Your AI agent can write code, search the internet, and draft emails — but the moment it needs to touch money, it hits a wall. WAIaaS is an open-source, self-hosted Wallet-as-a-Service that hands your agent a real crypto wallet, with a TypeScript SDK and a Python async SDK that both carry zero external dependencies. Whether you're building with LangChain, CrewAI, AutoGPT, or Claude via MCP, this is the missing piece: your agent can finally pay for things, swap tokens, and interact with DeFi protocols on its own.

The Problem Is Simpler Than You Think

Most AI agent frameworks are great at reasoning and tool use. They're not built to hold keys, sign transactions, or manage blockchain state. So developers end up bolting on custom signing code, managing RPC connections by hand, and writing their own retry logic for on-chain confirmations. That's not the interesting part of building an AI agent — it's infrastructure plumbing.

What you actually want is a clean SDK call: "send 0.1 SOL to this address," and then get back a transaction ID. Everything else — the pipeline, the policy engine, the signing — should be someone else's problem.

WAIaaS handles exactly that. You self-host a daemon (one Docker container), point your SDK at it, and your agent gets a fully featured wallet API with spending policies, security tiers, and DeFi integrations already wired up.

Two SDKs, One API

WAIaaS ships two official SDKs:

@waiaas/sdk — TypeScript/Node.js, for agents built with JS-based frameworks or running in serverless environments
waiaas — Python, async/await native, for LangChain, CrewAI, AutoGPT, and anything else in the Python AI ecosystem

Both SDKs have zero external dependencies. There's nothing to audit beyond the SDK itself, no transitive supply-chain surprises.

TypeScript SDK

npm install @waiaas/sdk

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

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

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

// Send native token
const tx = await client.sendToken({
  to: 'recipient-address...',
  amount: '0.1',
});
console.log(`Transaction: ${tx.id}`);

That's it. No provider setup, no ABI loading, no gas estimation boilerplate. The daemon handles all of that.

Python SDK

pip install waiaas

from waiaas import WAIaaSClient

async with WAIaaSClient("http://localhost:3100", "wai_sess_xxx") as client:
    balance = await client.get_balance()
    print(balance.balance, balance.symbol)

The Python SDK is async-native, which means it drops cleanly into any asyncio-based agent framework. The context manager handles session lifecycle for you.

What Your Agent Can Actually Do

The TypeScript SDK exposes these methods directly:

getBalance()         — Get wallet native token balance
getAddress()         — Get wallet address
getAssets()          — Get all token balances
sendToken()          — Send native or token transfer
getTransaction()     — Get transaction by ID
listTransactions()   — List transaction history
signTransaction()    — Sign arbitrary transaction
x402Fetch()          — HTTP fetch with automatic 402 payment

That last one — x402Fetch() — is worth pausing on. WAIaaS supports the x402 HTTP payment protocol, which means your agent can make HTTP requests that automatically pay for themselves when the server returns a 402. If you're building an agent that consumes paid APIs, it can fund its own tool calls without any human in the loop.

Behind the scenes, the daemon has 39 REST API route modules and supports 7 transaction types: Transfer, TokenTransfer, ContractCall, Approve, Batch, NftTransfer, and ContractDeploy. Your SDK calls map to these routes — you're not losing anything by going through the SDK layer.

Building a Real Agent: End-to-End Example

Here's a complete TypeScript example showing how an agent would check its balance, send tokens, and wait for confirmation:

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

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

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

This is real agent code. The polling loop is exactly what you'd write inside a LangChain tool or a CrewAI task. The agent submits the transaction, waits for chain confirmation, and branches on the result — all without knowing anything about RPC nodes or block finality.

Error Handling That Actually Helps

Agent frameworks need structured errors they can reason about. WAIaaS errors carry machine-readable codes:

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

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 is particularly useful: it means the spending policy on this wallet blocked the transaction. Your agent can catch this, log the reason, and decide whether to request a smaller amount or escalate to a human. This is how you build safe autonomous agents — the safety layer is at the infrastructure level, not in your agent's prompt.

The Policy Layer: Safety by Default

Before your agent can spend anything, the wallet has a policy engine with 21 policy types and 4 security tiers: INSTANT, NOTIFY, DELAY, and APPROVAL.

You configure policies once, at setup time, using the master password:

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

With this policy in place: transactions under $100 go through instantly, transactions between $100–$500 notify you but still execute, transactions between $500–$2,000 are delayed 15 minutes (cancellable), and anything over $2,000 requires your manual approval.

Your agent's session token only has sessionAuth privileges — it can sign and submit transactions, but it cannot create wallets, modify policies, or approve held transactions. That's reserved for masterAuth (you, the operator) and ownerAuth (the wallet owner, via WalletConnect or Telegram). Three authentication layers, cleanly separated.

The policy engine is also default-deny: if you haven't configured ALLOWED_TOKENS or CONTRACT_WHITELIST, those transaction types are blocked. Your agent can't accidentally drain a wallet into an unknown contract.

DeFi Actions: Beyond Simple Transfers

The daemon integrates 15 DeFi protocol providers. Your agent can call them via the REST API directly, or you can wrap the API call as a tool in your agent framework.

Here's a Jupiter swap on 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"
  }'

The full list of integrated protocols includes Aave v3, Across, D'CENT Swap, Drift, Hyperliquid, Jito Staking, Jupiter Swap, Kamino, Lido Staking, LI.FI, Pendle, Polymarket, XRPL DEX, and 0x Swap. Liquid staking, cross-chain bridging, perpetual futures, prediction markets — all callable from your agent's session token, subject to whatever policies you've set.

Quick Start: Running the Daemon in 5 Minutes

You don't need to deploy anything complex. The whole thing runs in a single Docker container.

Step 1: Install the CLI and initialize

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

Step 2: Create a wallet and session in one command

waiaas quickset --mode mainnet

This prints a session token and an MCP config JSON you can paste directly into Claude Desktop.

Step 3: Or use Docker directly with auto-provision

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

Step 4: Install your SDK

npm install @waiaas/sdk
# or
pip install waiaas

Step 5: Set your environment variables and start building

export WAIAAS_BASE_URL=http://127.0.0.1:3100
export WAIAAS_SESSION_TOKEN=wai_sess_<from-quickset>

Your agent is now funded and policy-protected. The interactive API reference is available at http://127.0.0.1:3100/reference if you want to explore all 39 route modules before writing code.

Test Before You Send

One more thing worth knowing before you ship your agent: there's a dry-run mode. You can simulate any transaction before it actually 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
  }'

Add "dryRun": true to any transaction request and the daemon will run it through the full 7-stage pipeline — validation, auth, policy check — and return what would happen, without touching the chain. This is useful during development and as a pre-flight check inside your agent's decision loop.

What's Next

The SDKs are the entry point, but WAIaaS has a lot more surface area once your agent needs it: 45 MCP tools for Claude Desktop integration, ERC-4337 account abstraction for gasless transactions, and an admin Web UI at /admin for monitoring what your agents are doing in production. The codebase is open-source and the daemon is self-hosted — your keys never leave your infrastructure.

Explore the full project on GitHub at https://github.com/waiaas/WAIaaS, or visit https://waiaas.ai for documentation and getting-started guides. If you're building an agent that needs to interact with blockchains, this is the infrastructure layer you've been missing.

21 Ways to Control Your AI Trading Bot: Complete Policy Engine Risk Management

Wallet Guy — Tue, 06 Oct 2026 13:26:41 +0000

21 Ways to Control Your AI Trading Bot: Complete Policy Engine Risk Management

AI trading bots with unrestricted wallet access are a liability waiting to happen — one misconfigured agent or compromised session token away from draining everything you've built. If you're giving an AI agent access to real funds, you need more than good intentions and crossed fingers. You need explicit, auditable, code-enforced guardrails between your agent and your money.

The Real Risk: Autonomous Agents With Wallets

Here's the uncomfortable truth about AI agents and crypto wallets: most implementations treat authorization as a binary. Either the agent has access or it doesn't. That's fine for toy projects. It's dangerous for anything running on mainnet with real capital.

The threat surface is larger than most developers account for. It's not just "what happens if the AI makes a bad trade." It's: what happens when the session token leaks? What if the model hallucinates a recipient address? What if a protocol gets exploited and the agent keeps interacting with it? What if you want your bot to handle small rebalancing operations autonomously but need human sign-off on anything over $500?

These aren't edge cases. They're the questions that determine whether you can actually trust an autonomous system with funds.

3 Layers Between Your Agent and Your Money

WAIaaS is built around a layered security model that doesn't require you to choose between autonomy and safety. The architecture provides three distinct control layers:

Layer 1 — Session authentication. Every AI agent operates on a scoped session token. Sessions have TTL, maxRenewals, and absoluteLifetime controls. A compromised token has a bounded blast radius.

Layer 2 — Policy engine with time delays and approval gates. This is where most of the risk management lives. 21 policy types, 4 security tiers, and a default-deny posture means your agent literally cannot do things you haven't explicitly permitted.

Layer 3 — Monitoring and kill switch. Incoming transaction monitoring with real-time notifications, plus WalletConnect-based owner approval for high-risk actions.

Three auth methods serve three different roles: masterAuth (Argon2id) for system administration like creating wallets and sessions, ownerAuth (SIWS/SIWE signature) for the fund owner approving or rejecting transactions, and sessionAuth (JWT HS256) for the AI agent's day-to-day operations.

# 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 agent never touches masterAuth credentials. The owner never needs to run the agent. These roles are cleanly separated by design.

Default-Deny: The Most Important Security Property

Before walking through all 21 policy types, the most important thing to understand is the default-deny posture. If you don't configure ALLOWED_TOKENS, your agent cannot transfer tokens. If you don't configure CONTRACT_WHITELIST, your agent cannot call contracts. No whitelist means no access — not "access to everything."

This inverts the typical developer instinct. Most systems are permissive by default and you add restrictions. WAIaaS is restrictive by default and you add permissions. That distinction matters enormously when something goes wrong.

The 4 Security Tiers

Every transaction that passes through WAIaaS gets classified into one of four tiers:

INSTANT   — Execute immediately, no notification
NOTIFY    — Execute immediately, send notification to owner
DELAY     — Queue for N seconds, then execute (cancellable during window)
APPROVAL  — Require explicit human approval via WalletConnect/Telegram/Push

The tier assignment is policy-driven and amount-aware. You define the thresholds. Here's what a realistic SPENDING_LIMIT policy looks like:

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

With this config: under $100 executes immediately and silently, $100-$500 executes immediately but pings you, $500-$2000 goes into a 15-minute holding queue you can cancel, and anything over $2000 requires your explicit approval. Your agent can be fully autonomous for small rebalancing ops while you stay in the loop for anything significant.

All 21 Policy Types

Here's the complete picture. These aren't marketing categories — these are the actual policy types enforced in the transaction pipeline.

Spending and Limits

SPENDING_LIMIT — The primary amount-based control. 4-tier security based on USD value. Supports daily and monthly caps, plus per-token limits for granular control.

APPROVE_AMOUNT_LIMIT — Caps how large a token approval can be. Blocks unlimited approvals (uint256 max). Critical for DeFi safety — unlimited approvals to compromised protocols have caused massive losses in the past.

APPROVE_TIER_OVERRIDE — Force a specific security tier for all APPROVE transactions regardless of amount. If you want every approval to require human sign-off no matter what, this is how you enforce it.

ACTION_CATEGORY_LIMIT — Set spending limits per category of DeFi action. You can cap how much your agent allocates to lending separately from how much it allocates to perpetual futures.

Allowlists (All Default-Deny)

ALLOWED_TOKENS — Define exactly which tokens the agent can transfer. Anything not on the list is blocked, full stop.

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

CONTRACT_WHITELIST — Define which smart contracts the agent can interact with. Your agent cannot call Jupiter if Jupiter isn't on this list.

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

APPROVED_SPENDERS — Control which addresses can be granted token approvals, with optional max amounts per spender.

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

METHOD_WHITELIST — Allowlist specific function selectors. If your agent should only be able to call swap() and not withdraw(), this is how you encode that.

WHITELIST — Recipient address allowlist. Your agent can only send funds to addresses you've pre-approved.

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

VENUE_WHITELIST — Allowlist specific trading venues. Restrict which DEXes or protocols the agent can use.

Rate and Time Controls

RATE_LIMIT — Maximum number of transactions per hour or per day. Useful for detecting runaway agent behavior and capping the damage from a misbehaving model.

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

TIME_RESTRICTION — Restrict transaction execution to specific hours. If your trading strategy only makes sense during market hours, enforce that at the infrastructure level.

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

ALLOWED_NETWORKS — Restrict the agent to specific chains. An agent configured for Solana mainnet operations shouldn't be able to send transactions on Ethereum.

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

DeFi-Specific Controls

LENDING_LTV_LIMIT — Maximum loan-to-value ratio for DeFi lending positions. Prevents your agent from over-leveraging into liquidation territory.

LENDING_ASSET_WHITELIST — Which assets the agent is allowed to supply or borrow. You can allow USDC borrowing without allowing your agent to touch riskier assets.

PERP_MAX_LEVERAGE — Hard cap on perpetual futures leverage. A leveraged trading bot without this is a liquidation waiting to happen.

PERP_MAX_POSITION_USD — Maximum position size in USD for perp trades. Caps the worst-case loss from a single bad trade.

PERP_ALLOWED_MARKETS — Which perpetual markets the agent can trade. If your strategy is SOL-PERP only, enforce that explicitly.

Protocol and Agent Controls

X402_ALLOWED_DOMAINS — Allowlist for x402 HTTP payment protocol. WAIaaS supports automatic API payment for AI agents via x402; this policy controls which domains the agent is allowed to pay automatically.

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

REPUTATION_THRESHOLD — Minimum ERC-8004 onchain reputation score required for agent interactions. Enables trustless agent validation.

ERC8128_ALLOWED_DOMAINS — Controls which domains the agent can sign HTTP requests for using the ERC-8128 protocol.

The 7-Stage Transaction Pipeline

Policies don't run as an afterthought — they're embedded in a 7-stage pipeline that every transaction passes through: validate → auth → policy → wait → execute → confirm. The wait stage is where DELAY-tier transactions sit in the cancellable queue. Nothing executes until it clears every preceding stage.

This means you can simulate a transaction before it ever hits the pipeline. The dry-run API lets you validate against the full policy stack without committing to execution:

curl -X POST http://127.0.0.1:3100/v1/transactions/send \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer wai_sess_<token>" \
  -d '{
    "type": "TRANSFER",
    "to": "recipient-address",
    "amount": "0.1",
    "dryRun": true
  }'

This is useful during development to verify that your policy configuration actually behaves the way you expect before you run anything on mainnet.

And when a policy blocks a transaction, the error response tells you exactly why:

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

No ambiguity. The agent — and you — know precisely what rule was triggered.

Human Approval in the Loop

APPROVAL-tier transactions require a human response before anything executes. WAIaaS supports three signing channels for delivering approval requests: push relay, Telegram, and WalletConnect. Once you approve, the transaction proceeds. If you reject or let it time out, it doesn't.

The owner approval endpoint uses a signed message for authentication — your wallet signs, not a password:

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

This is the kill switch pattern. Even if every other layer were compromised, transactions requiring owner approval can't execute without a cryptographic signature from the controlling wallet.

Quick Start: Setting Up Your First Policy Stack

Here's the minimum viable security setup for a Solana trading agent:

Step 1: Install and initialize WAIaaS.

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

Step 2: Create a wallet and session for your agent.

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

Step 4: Add an allowed tokens policy (default-deny enforcement).

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

Step 5: Verify a transaction against your policies using dry-run before going live.

Your agent now operates with bounded autonomy: it can move funds within your defined limits, it's blocked from touching anything not explicitly permitted, and anything over your DELAY threshold requires your active involvement.

What's Next

The policy engine is one part of the WAIaaS security model. Explore the full interactive API reference at http://127.0.0.1:3100/reference once your daemon is running — it's auto-generated from the codebase and covers all 39 API route modules. For production deployments, review the Docker Secrets integration and the secrets overlay pattern in docker-compose.secrets.yml to keep your master password out of environment variables entirely.

The source code, full documentation, and deployment guides are at https://github.com/waiaas/WAIaaS. If you're building AI agents that handle real capital, start there. The project site with additional resources is at https://waiaas.ai.