DEV Community: Wallet Guy

Self-Documenting Economic Agents: OpenAPI 3.0 for Autonomous Commerce

Wallet Guy — Mon, 21 Sep 2026 18:38:48 +0000

Self-Documenting Economic Agents: OpenAPI 3.0 for Autonomous Commerce

AI agents will need to pay for compute, data, and API calls — and the infrastructure to make that happen exists today, not in some speculative roadmap. If you're building agents that operate autonomously, you've probably already hit the wall: your agent can reason, plan, and act, but the moment it needs to move money, you're back to human-in-the-loop plumbing. This post is about closing that gap with real, working infrastructure.

The Problem No One Talks About at AI Conferences

There's a lot of conversation about reasoning capabilities, context windows, and tool use. Considerably less conversation about the boring but critical question: how does an agent pay for things?

Think through the lifecycle of an autonomous agent doing something genuinely useful — say, a research agent that monitors market conditions, queries premium data APIs, executes trades, and rebalances a portfolio overnight. Every one of those steps involves either a cost or a value transfer:

Querying a premium data feed costs money (someone has to pay the API provider)
Executing a swap on-chain requires gas
Moving funds between protocols requires signing transactions
Reporting results might involve paying for a delivery channel

Today, most teams handle this by giving the agent access to a human-controlled wallet with full permissions, or by hard-coding payment credentials that get rotated manually. Neither approach scales, and neither is safe. What's actually needed is wallet infrastructure designed for agents from the ground up — with policy enforcement, audit trails, and the kind of self-documentation that lets agents (and developers) discover capabilities at runtime.

Wallets That Speak HTTP

WAIaaS (Wallet-as-a-Service for AI agents) is an open-source, self-hosted daemon that treats wallet operations as a REST API. Instead of your agent importing a private key and calling a library directly, it makes HTTP calls to a local service that handles key management, transaction signing, policy enforcement, and multi-chain routing.

The architecture is deliberately simple: you run the daemon, create a wallet, issue a session token to your agent, and the agent operates within the boundaries you set. The daemon exposes 39 REST API route modules covering everything from balance queries to DeFi actions to NFT transfers.

What makes this relevant to the "autonomous commerce" question is the combination of two things: a machine-readable OpenAPI 3.0 spec and native x402 HTTP payment support. Together, they mean an agent can discover what a wallet service can do and automatically pay for API calls that require payment — without a human in the loop for either step.

OpenAPI as Agent Infrastructure

When WAIaaS is running, you get a self-documenting API at two endpoints:

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

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

The /doc endpoint returns a machine-readable OpenAPI 3.0 specification. The /reference endpoint serves an interactive Scalar UI for human exploration. This matters more than it might seem at first glance.

An OpenAPI spec is a contract. It describes every endpoint, every required parameter, every possible response code. For a human developer, that's useful documentation. For an agent — especially one using an LLM with tool-calling capabilities — it's a capability manifest that can be parsed, indexed, and acted on at runtime.

Consider what this enables: an orchestrator agent could fetch the spec from a WAIaaS instance, understand that the wallet supports token transfers, contract calls, DeFi actions across 15 integrated protocols, and NFT operations — then route sub-tasks to the appropriate endpoints without any hardcoded knowledge of the API surface. The agent discovers capabilities the same way a developer does, just programmatically.

The x402 Layer: Agents That Pay for What They Use

The x402 HTTP payment protocol is the piece that makes autonomous economic participation concrete. When an agent calls an API that returns HTTP 402 (Payment Required), the x402 protocol defines a standard handshake: the server declares what it wants, the client pays, the server fulfills the request.

WAIaaS has native x402 support built in. From the agent's perspective, this is just a fetch call:

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

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

The TypeScript SDK includes x402Fetch() — a drop-in replacement for standard HTTP fetch that automatically handles 402 responses by paying from the agent's wallet and retrying the request. The agent doesn't need to know whether a given API costs money; it just makes requests and the payment layer handles the rest.

This is the "machines that pay for what they use" model made operational. A premium data API, a compute provider, a specialized model endpoint — any service implementing x402 becomes something agents can consume autonomously, with payment flowing automatically and every transaction recorded in the wallet's audit trail.

To control which domains an agent can pay automatically, you configure the X402_ALLOWED_DOMAINS policy:

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

The agent can only auto-pay domains you've explicitly whitelisted. This is the policy engine enforcing boundaries — the agent operates autonomously within a defined permission set, not without constraints.

The Policy Engine: Autonomy With Guardrails

Autonomous doesn't mean uncontrolled. WAIaaS ships with a policy engine that has 21 policy types and 4 security tiers: INSTANT, NOTIFY, DELAY, and APPROVAL.

The four tiers map directly to how much trust you're extending to the agent for a given operation:

INSTANT — Execute immediately, no notification
NOTIFY — Execute immediately, send you a notification
DELAY — Queue for N seconds, then execute (cancellable)
APPROVAL — Require explicit human approval before anything moves

A spending limit policy ties the tier to 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
    }
  }'

With this configuration, your agent can move up to $100 instantly (appropriate for x402 micro-payments and small operational costs), handle up to $500 with a notification sent to you, queue up to $2,000 with a 15-minute cancellation window, and anything larger requires your explicit sign-off. The policy system follows default-deny: transactions are blocked unless explicitly permitted.

The other 20 policy types cover things like token whitelists, contract whitelists, rate limits, time restrictions, DeFi-specific limits (max leverage for perpetuals, max loan-to-value for lending), and reputation thresholds for agent-to-agent interactions via ERC-8004. The full list is extensive precisely because real economic agents face a wide surface of risk.

Multi-Chain, Multi-Protocol DeFi Access

An agent operating in the token economy isn't just sending transfers. It might need to swap assets, provide liquidity, stake for yield, or take positions in prediction markets. WAIaaS integrates 15 DeFi protocol providers across 18 networks (2 chain types: EVM and Solana).

A Jupiter swap on Solana looks like this:

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

The agent authenticates with a session token, specifies the action and protocol, and the daemon handles routing, signing, and submission. The integrated protocols include Jupiter (Solana DEX aggregation), Aave V3 (lending), Hyperliquid (perpetual futures), Lido and Jito (liquid staking), LI.FI and Across (cross-chain bridging), Polymarket (prediction markets), and more. An agent with access to this surface can participate in DeFi markets as a first-class economic actor.

Before any of this executes against real funds, there's a dry-run mode:

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 and you get a simulation of the outcome without committing anything on-chain. For agents that need to reason about consequences before acting, this is the equivalent of a read-only preview of the world state post-action.

Transactions flow through a 7-stage pipeline: validate → auth → policy → wait → execute → confirm. Every stage is a checkpoint, and the gas condition feature means transactions can be queued to execute only when gas prices fall below a threshold — useful for an agent managing costs autonomously.

Getting a Self-Documenting Agent Wallet Running

Here's the minimal path from zero to a working agent wallet with API discovery enabled:

Step 1: Install and start

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

Step 2: Create a wallet and session

curl -X POST http://127.0.0.1:3100/v1/wallets \
  -H "Content-Type: application/json" \
  -H "X-Master-Password: my-secret-password" \
  -d '{"name": "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: Explore the API spec

curl http://127.0.0.1:3100/doc -o openapi.json
open http://127.0.0.1:3100/reference

Step 4: Configure policies before funding

Set at minimum a SPENDING_LIMIT and an ALLOWED_TOKENS whitelist (which is default-deny — the agent can't move tokens you haven't explicitly permitted).

Step 5: Connect to your agent framework

Use the TypeScript SDK (npm install @waiaas/sdk), the Python SDK (pip install waiaas), or the 45-tool MCP server (waiaas mcp setup --all) depending on how your agent is built. If you're using Claude Desktop, the MCP setup command auto-registers the wallet and generates the configuration JSON for you.

The Architecture Argument

There's a broader point here worth making explicit. The design decision to expose wallet operations as a self-documenting HTTP API — rather than a library or SDK that agents import directly — has meaningful consequences for how agent economies can scale.

A library coupling means every agent implementation needs to speak the same language, import the same dependencies, and handle key material directly. An HTTP service with an OpenAPI spec means any agent, in any language, built on any framework, can discover and use the wallet's capabilities through a standard interface. The spec becomes the contract. Discovery becomes runtime, not build-time.

This is the same architectural shift the web made from tight client-server coupling to REST. It's the same shift that made microservices composable. Applied to agent wallet infrastructure, it means the economic layer of agent systems can evolve independently of the agents themselves — new protocols, new chains, new policy types can be added to the daemon and immediately become discoverable to any connected agent.

The OpenAPI spec at /doc isn't just developer convenience. It's the mechanism by which autonomous agents can reason about what economic actions are available to them at any given moment.

What's Next

If you're building agents that need to operate economically — paying for APIs, managing DeFi positions, executing trades, or participating in agent-to-agent commerce — the infrastructure is here and working today. Start with the GitHub repository for the full codebase and self-hosting instructions, and visit the official site for documentation on the policy engine and SDK references.

The open question isn't whether agents will need wallets. It's whether the wallet infrastructure will be designed for agents or retrofitted from human-facing tools. WAIaaS is an answer to that question built from first principles.

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

Lock Down Your DeFi Bot: METHOD_WHITELIST for Smart Contract Security

Wallet Guy — Mon, 21 Sep 2026 13:00:21 +0000

Lock Down Your DeFi Bot: METHOD_WHITELIST and Smart Contract Security with WAIaaS

Your DeFi trading bot has a problem: it holds private keys, executes transactions autonomously, and interacts with smart contracts — and if something goes wrong, there's no undo button. Whether you're running an arb bot, a liquidity manager, or an automated hedging strategy, the attack surface is real. A compromised session token, a buggy strategy loop, or a malicious contract call can drain your wallet in a single block. METHOD_WHITELIST is one of the tools that closes that gap, and in this post we'll look at how WAIaaS builds it into a broader security architecture designed specifically for autonomous agents.

Why Contract-Level Restrictions Actually Matter

Most wallet security discussions stop at "protect your private key." That's necessary but not sufficient when you have a bot running 24/7 with signing authority. The real risk surface for an automated trading system looks like this:

Your bot's session token is stolen or leaked
A bug in your strategy logic calls the wrong function on the wrong contract
A dependency in your pipeline gets compromised and injects a malicious payload
A smart contract you've whitelisted gets upgraded to a honeypot

In each of these cases, you want a layer of defense that sits between the session token and the blockchain — something that says "even if this token is fully authenticated, it can only call these specific functions on these specific contracts." That's exactly what METHOD_WHITELIST and CONTRACT_WHITELIST do in WAIaaS.

WAIaaS is an open-source, self-hosted Wallet-as-a-Service built for AI agents and automated systems. It runs as a local daemon (or Docker container), your bot talks to it over HTTP, and it handles signing, policy enforcement, and transaction execution. The policy engine sits in the middle of a 7-stage transaction pipeline — validate, auth, policy, wait, execute, confirm — so every transaction is checked before it touches a private key.

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

Before diving into METHOD_WHITELIST specifically, it's worth understanding the full policy architecture, because METHOD_WHITELIST is most effective as part of a layered configuration.

WAIaaS has 21 policy types across 4 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

The critical detail is default-deny: if you haven't configured ALLOWED_TOKENS, transactions involving that token are blocked. If you haven't configured CONTRACT_WHITELIST, contract calls are blocked. Your bot doesn't accidentally call something it shouldn't — it's blocked by default.

For a trading bot, a minimal hardened configuration typically combines:

CONTRACT_WHITELIST — only the specific contracts your strategy touches
METHOD_WHITELIST — only the function selectors those contracts expose
SPENDING_LIMIT — 4-tier amount-based controls
ALLOWED_TOKENS — only the tokens your strategy trades
ALLOWED_NETWORKS — restrict to the chains you actually use

Let's set these up.

Step 1: Deploy WAIaaS and Create a Trading Wallet

If you're running locally, the quickest path is Docker:

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

The daemon binds to 127.0.0.1:3100 by default — not publicly exposed. Now create a wallet for your trading bot:

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

Then create a session token — this is what your bot will use at runtime:

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

The session token (wai_sess_...) goes into your bot's environment. The master password stays locked away — your bot never touches it.

Step 2: Configure CONTRACT_WHITELIST

Before METHOD_WHITELIST, you need to whitelist the contracts themselves. For a Jupiter swap bot on Solana:

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

Any call to a contract not on this list is rejected before signing. Your bot physically cannot interact with a contract you haven't explicitly approved — even if a compromised dependency tries to construct a malicious payload.

Step 3: Add METHOD_WHITELIST for Function-Level Control

CONTRACT_WHITELIST tells WAIaaS which contracts are allowed. METHOD_WHITELIST goes one level deeper: it restricts which function selectors can be called on those contracts. On EVM chains, function selectors are the 4-byte prefixes of the keccak256 hash of the function signature — transfer(address,uint256) maps to 0xa9059cbb, for example.

This matters because smart contracts often expose administrative or dangerous functions alongside their public trading interface. Even if your strategy only needs swap(), a compromised session could theoretically call emergencyWithdraw() or an admin function if you haven't locked it down. METHOD_WHITELIST prevents that:

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": "METHOD_WHITELIST",
    "rules": {
      "selectors": ["0xa9059cbb", "0x23b872dd"]
    }
  }'

The exact structure of METHOD_WHITELIST rules follows the pattern of the WAIaaS policy engine. The principle: your bot signs only the function calls you explicitly enumerated. Nothing else.

Step 4: Lock Down Tokens and Spending

For a USDC/SOL arb bot, you don't want the session token to be able to move arbitrary tokens. Add ALLOWED_TOKENS:

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

And a SPENDING_LIMIT to cap damage from any single runaway transaction:

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

With this configuration, a single transaction under $100 executes immediately. $100–$500 triggers a notification. $500–$2,000 is delayed 15 minutes (giving you a window to cancel). Above $2,000 requires your explicit approval.

Step 5: Always Dry-Run Before You Execute

Before your bot goes live, simulate transactions through the full policy pipeline:

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

The dryRun: true flag runs the full 7-stage pipeline — validation, auth, all policy checks — without submitting anything to the chain. If your METHOD_WHITELIST or CONTRACT_WHITELIST is misconfigured, you'll see a POLICY_DENIED error response in test, not on mainnet:

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

This is how you verify your policy configuration before deploying capital.

Your Bot's Runtime Loop

At runtime, your bot authenticates with the session token only. Here's what a basic trading loop looks like using the TypeScript SDK:

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

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

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

// Submit a swap through the policy pipeline
try {
  const sendResult = await client.sendToken({
    type: 'TRANSFER',
    to: 'recipient-address',
    amount: '0.001',
  });
  console.log(`Transaction submitted: ${sendResult.id} (status: ${sendResult.status})`);

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

The session token in WAIAAS_SESSION_TOKEN has its entire behavior constrained by the policies you configured above. Even if this token is stolen, the attacker can only call the functions you've whitelisted, on the contracts you've whitelisted, up to the spending limits you've set.

Gas Conditional Execution

WAIaaS also supports gas conditional execution — transactions execute only when the gas price meets a threshold you define. For bots where gas costs directly affect profitability, this means you can submit a transaction and let WAIaaS wait for favorable conditions rather than polling and resubmitting yourself.

This is built into the transaction pipeline at the stage level, not bolted on after the fact.

Multi-Protocol Access

The 15 integrated DeFi protocol providers — including Jupiter swap, Drift (perpetual futures), LI.FI (cross-chain bridging), Aave V3, Hyperliquid, and Across — are accessible through the same session-authenticated API. Your bot can:

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

All of these go through the same policy pipeline. Your CONTRACT_WHITELIST, METHOD_WHITELIST, and SPENDING_LIMIT apply to DeFi action calls just as they apply to raw contract calls.

Quick Start Summary

Here's the minimal path to a hardened trading bot setup:

Start the daemon — docker compose up -d or waiaas start
Create a wallet — POST /v1/wallets with masterAuth
Issue a session token — POST /v1/sessions with masterAuth
Configure policies — CONTRACT_WHITELIST, METHOD_WHITELIST, ALLOWED_TOKENS, SPENDING_LIMIT, ALLOWED_NETWORKS
Dry-run your first transaction — verify policy configuration with dryRun: true
Deploy your bot — session token in environment, master password locked away

The OpenAPI spec is available at http://127.0.0.1:3100/doc and the interactive API reference at http://127.0.0.1:3100/reference — useful for exploring all 39 API route modules before writing your integration.

What's Next

The policy system has 21 types covering scenarios from DeFi-specific limits (PERP_MAX_LEVERAGE, LENDING_LTV_LIMIT) to reputation thresholds (REPUTATION_THRESHOLD for ERC-8004 agents) — worth reviewing the full list as your strategy grows more complex. If you're building on EVM, the ERC-4337 Account Abstraction support with gasless transactions and UserOp build/sign API opens up additional execution patterns. Start with the codebase and documentation:

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

18-Network Docker Setup: Deploy Multi-Chain AI Agent Infrastructure

Wallet Guy — Sun, 20 Sep 2026 16:46:48 +0000

Self-Hosted Multi-Chain AI Agent Infrastructure: Deploy WAIaaS Across 18 Networks with Docker

Docker makes it surprisingly straightforward to run your own multi-chain AI agent wallet infrastructure — but most developers don't realize they can have the whole thing running locally in under five minutes, with no third-party custody of their keys. If you've ever felt uneasy handing an AI agent's private keys to a hosted service, or hit rate limits on a managed wallet API at the worst possible moment, this post is for you.

Would You Trust a Third Party With Your Agent's Private Keys?

It's a fair question. When you use a hosted wallet-as-a-service, you're typically making a deal: convenience in exchange for custody. Someone else's server holds the keys, processes the transactions, and sits between your AI agent and the blockchain. For personal projects or low-stakes experiments, that trade-off is fine. But as soon as real funds are involved — or you need predictable uptime, custom policies, or just don't want to explain your agent's trading activity to a third-party compliance team — the hosted model starts to feel like running your own email but using Gmail to store the messages.

The alternative is self-hosting. Your server, your keys, your rules.

WAIaaS is an open-source, self-hosted Wallet-as-a-Service built specifically for AI agents. It runs in Docker, covers 18 networks across EVM chains and Solana, integrates with 15 DeFi protocols, and ships with a policy engine that puts you — not the platform — in control of what your agents can and can't do.

Why Self-Hosting Actually Makes Sense Here

The crypto self-hosting instinct is well-established. People run their own nodes, their own validators, their own RPC endpoints. The reasons are always the same: privacy, reliability, and sovereignty. WAIaaS extends that philosophy to the wallet infrastructure layer.

When your AI agent needs to swap tokens, check a balance, or execute a DeFi position, it's talking to your local daemon — not an external API with its own rate limits, terms of service, or downtime schedule. You configure which RPC endpoints to use. You decide which networks are active. You set the policies that govern what the agent is allowed to spend, where it can send funds, and which contracts it can interact with. None of that configuration lives on someone else's server.

There's also a practical engineering argument: the hosted model means your agent's behavior is coupled to external API availability. A self-hosted daemon bound to 127.0.0.1:3100 is a dependency you control entirely.

What You're Actually Deploying

WAIaaS ships as a 15-package monorepo with two Docker images: the main daemon and a push-relay for notifications. The daemon exposes 39 REST API route modules, supports 45 MCP tools for AI agent integration, and implements a 7-stage transaction pipeline that handles validation, policy checks, gas conditions, execution, and confirmation.

The network coverage is broad: 18 networks across two chain types (EVM and Solana). You point each network at your own RPC endpoint using environment variables, so you're never dependent on WAIaaS's infrastructure for chain connectivity.

The 15 DeFi protocol integrations — covering lending (Aave v3, Kamino), swaps (Jupiter, 0x, LI.FI, D'CENT), staking (Lido, Jito), perpetuals (Hyperliquid, Drift), prediction markets (Polymarket), bridging (Across), and more — run through the same local daemon. Your agent's DeFi activity stays between your server and the chain.

Getting the Daemon Running

The simplest path to a running instance is three commands:

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

That's it for a development setup. The Docker Compose file binds to 127.0.0.1:3100 by default, so the daemon is only accessible from localhost unless you explicitly change that.

For a more self-contained start — useful if you want to skip cloning the repo entirely — you can use docker run 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

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

WAIAAS_AUTO_PROVISION=true generates a random master password on first start and writes it to /data/recovery.key inside the container. You retrieve it once, store it somewhere safe, and then delete the recovery file. The data persists in a named Docker volume, so docker compose down without -v preserves everything.

Configuring Your RPC Endpoints

This is the part that actually makes self-hosting meaningful. WAIaaS lets you specify RPC endpoints per network via environment variables:

WAIAAS_RPC_SOLANA_MAINNET=<url>
WAIAAS_RPC_EVM_ETHEREUM_MAINNET=<url>

You can point these at your own node, a private RPC provider you already pay for, or a public endpoint — your choice. The daemon doesn't phone home for chain connectivity.

The full Docker Compose configuration gives you a clear picture of what's configurable:

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

Put your RPC URLs and other configuration in a .env file in the same directory. The env_file stanza picks it up automatically, and required: false means the daemon starts fine without it if you're just exploring.

Hardening for Production: Docker Secrets

If you're running this on a homelab server or a VPS you control, environment variables in a .env file are convenient but not ideal for sensitive values. WAIaaS supports Docker Secrets for production deployments via a secrets overlay file:

# 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 reads secrets from the Docker Secrets mechanism, which mounts them as files in /run/secrets/ rather than exposing them as environment variables. For a homelab setup where you care about not having credentials in docker inspect output, this is worth the extra step.

The daemon also runs as a non-root user (UID 1001) by default, which is one of those small things that matters when you're thinking about container security seriously.

Creating Wallets and Issuing Agent Sessions

Once the daemon is running, you interact with it through its REST API. Three authentication headers cover different roles: X-Master-Password for system administration (wallet creation, session management, policies), Authorization: Bearer for AI agent sessions, and X-Owner-Signature for fund-owner approval of high-value transactions.

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 session token is what your agent actually uses. It's scoped to a specific wallet, and its capabilities are bounded by whatever policies you've attached to that wallet. The master password never leaves your environment.

If you prefer the CLI, waiaas quickset --mode mainnet creates wallets and MCP sessions in a single command.

The Policy Engine: Defining What Your Agent Can Do

Self-hosting is only half the sovereignty story. The other half is controlling what your agent is actually allowed to do with the funds you've given it access to.

WAIaaS implements a policy engine with 21 policy types and 4 security tiers: INSTANT (execute immediately), NOTIFY (execute and notify you), DELAY (queue for a configurable number of seconds, cancellable), and APPROVAL (require explicit human sign-off). The engine is default-deny: transactions involving tokens not on the ALLOWED_TOKENS whitelist, or contracts not on the CONTRACT_WHITELIST, are blocked.

A spending limit policy that tiers transactions by USD value 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. Transactions between $100 and $500 trigger a notification. Transactions between $500 and $2,000 are queued for 15 minutes before execution, giving you a window to cancel. Anything over $2,000 requires your explicit approval — delivered via WalletConnect, Telegram, or push notification, depending on how you've configured signing channels.

The full list of 21 policy types covers DeFi-specific constraints too: LENDING_LTV_LIMIT caps loan-to-value ratios, PERP_MAX_LEVERAGE limits futures leverage, PERP_MAX_POSITION_USD caps position sizes, and X402_ALLOWED_DOMAINS controls which APIs your agent can pay for automatically via the x402 HTTP payment protocol.

Connecting AI Agents via MCP

The most practical integration path for LLM-based agents is MCP (Model Context Protocol). WAIaaS ships 45 MCP tools covering wallet operations, transfers, DeFi actions, NFT management, and x402 payments.

After running waiaas mcp setup --all, you get a configuration block to paste into Claude Desktop:

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

WAIAAS_BASE_URL points at your local daemon. The agent session token scopes what the agent can do. Everything stays local — Claude's tool calls go to 127.0.0.1:3100, which means your wallet interactions never pass through any external MCP relay.

For multi-agent setups, you can run one MCP server entry per wallet, each with its own session token and policy set.

Simulating Before Executing

One useful capability for self-hosters who are still tuning their agent's behavior: dry-run simulation. Before any real transaction hits the chain, 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 pipeline runs through all its stages — validation, policy checks, gas condition evaluation — without submitting anything on-chain. Useful for verifying that your policy configuration is doing what you think it's doing before you let the agent loose.

Quick Start Summary

Five steps from zero to running multi-chain agent infrastructure:

Clone and start: git clone https://github.com/waiaas/WAIaaS.git && cd WAIaaS && docker compose up -d
Create a wallet: POST to /v1/wallets with your master password
Set policies: POST to /v1/policies to define spending limits and token whitelists
Create an agent session: POST to /v1/sessions to get a scoped session token
Connect your agent: Run waiaas mcp setup --all and paste the output into Claude Desktop config

The interactive API reference at http://127.0.0.1:3100/reference documents every endpoint. The OpenAPI 3.0 spec is downloadable at /doc if you want to generate client code or import it into Postman.

What's Next

The 684+ test files in the codebase mean the daemon is genuinely production-ready for homelab and small-scale production use, not just a demo. The GitHub repository at https://github.com/waiaas/WAIaaS has the full setup documentation, and https://waiaas.ai covers the broader ecosystem including SDK references and protocol integration details. If you're already running your own RPC nodes and want to close the loop on self-hosted agent infrastructure, the Docker setup is the natural next step.

True Economic Autonomy: How AI Agents Use x402 to Buy Their Own Resources

Wallet Guy — Sun, 20 Sep 2026 11:35:47 +0000

True Economic Autonomy: How AI Agents Use x402 to Buy Their Own Resources

AI agents will need to pay for compute, data, and API calls — and the infrastructure to make that happen exists today. The x402 HTTP payment protocol, combined with autonomous wallet infrastructure, gives agents the ability to transact independently without a human managing every payment. This isn't a whitepaper concept or a research preview. It's running code you can deploy this afternoon.

The Problem With "Human in the Loop" Payments

Think about what an AI agent actually needs to do its job. It calls APIs. It fetches data. It spins up compute. Every one of those operations costs money. Right now, the way most people solve this is simple: give the agent an API key backed by a human's credit card, and hope nothing goes wrong.

That works fine for demos. It falls apart at scale.

The agent has no awareness of what it's spending. There's no budget enforcement at the infrastructure level. If the agent misbehaves — or gets compromised — there's nothing stopping it from draining your card. And if you want to run hundreds of agents, you're now managing hundreds of billing relationships, manually.

What you actually want is agents that have their own wallets, their own budgets, and their own ability to make payments — with the humans who deploy them retaining meaningful oversight without babysitting every transaction.

That's the gap x402 fills, and it's the gap WAIaaS was built to close.

What x402 Actually Is

x402 is an HTTP payment protocol. The idea is simple: when a client requests a resource that costs money, the server responds with HTTP 402 — "Payment Required" — along with payment details. The client pays, includes proof of payment in a retry request, and the server responds with the actual resource.

From the server's perspective, it's standard HTTP. From the agent's perspective, it's invisible: the payment happens automatically as part of the request cycle.

WAIaaS exposes this as a native tool in both its MCP integration and its TypeScript SDK. An agent configured with a WAIaaS session token can call x402Fetch() exactly like it would call a normal fetch() — and the payment handling is automatic.

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

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

// Agent fetches a paid API endpoint — payment handled automatically
const response = await client.x402Fetch('https://api.example.com/market-data');

No manual payment flow. No human approval required for every call (unless you configure one). The agent pays for what it uses, from its own wallet, within the limits you set.

The Missing Infrastructure Layer: Wallets for Agents

For x402 to work, the agent needs a wallet with funds and the ability to sign transactions. WAIaaS provides exactly that — a self-hosted, open-source Wallet-as-a-Service that's designed from the ground up for AI agents, not humans.

When you create a wallet in WAIaaS, you get:

A wallet address on any supported chain (WAIaaS supports 2 chain types — EVM and Solana — across 18 networks)
A session token the agent uses for all API calls
A policy engine that enforces spending rules without human intervention

That last part is important. Autonomous doesn't mean uncontrolled.

# Create a wallet for your agent (masterAuth — this is you, the operator)
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 the agent will use
curl -X POST http://127.0.0.1:3100/v1/sessions \
  -H "Content-Type: application/json" \
  -H "X-Master-Password: my-secret-password" \
  -d '{"walletId": "<wallet-uuid>"}'

The session token goes to the agent. The master password stays with you. The agent can transact within its policy bounds — it cannot create new wallets, cannot elevate its own permissions, cannot touch master-level operations.

Policy Engine: Autonomy With Guardrails

This is where WAIaaS gets interesting for anyone thinking seriously about agent economic autonomy.

Pure autonomy — an agent that can spend without limits — is dangerous. But pure human control — requiring approval for every payment — eliminates the value of autonomous agents. WAIaaS resolves this tension with a 21-type policy engine and 4 security tiers.

The four tiers are:

INSTANT — Execute immediately, no notification
NOTIFY — Execute immediately, send notification to owner
DELAY — Queue for a configurable delay, then execute (cancellable)
APPROVAL — Require human approval before execution

For x402 payments specifically, there's a dedicated policy type: X402_ALLOWED_DOMAINS. You whitelist the domains your agent is allowed to pay automatically, and everything else gets blocked or escalated.

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

A realistic setup for an autonomous agent might look like this: small x402 API payments (under $1) execute instantly. Larger transactions trigger a notification. Anything over a threshold requires your approval via WalletConnect or Telegram before it goes through.

The policy engine is default-deny. If you haven't explicitly whitelisted a token or contract, the transaction is blocked. This means a misconfigured or compromised agent can't spontaneously start doing things it was never authorized to do.

The Full Picture: 45 MCP Tools, Today

If you're using Claude or another MCP-compatible AI assistant, WAIaaS exposes 45 MCP tools covering wallet operations, transactions, DeFi, NFTs, and x402. Setup is two commands:

npm install -g @waiaas/cli
waiaas mcp setup --all    # Auto-register all wallets with Claude Desktop

After that, your Claude instance can check balances, send tokens, query DeFi positions, and make x402 payments — all through natural language, with every transaction passing through the policy engine before execution.

The x402-fetch tool is one of those 45. When Claude encounters a 402 response, it can call that tool directly. The payment happens, the resource is retrieved, and Claude continues its task. From the user's perspective, the agent just... got the data it needed. The economic machinery underneath is invisible.

DeFi Integration: Agents That Manage Their Own Treasury

x402 micro-payments are one side of agent economic autonomy. The other side is what agents do with funds they're not spending on API calls.

WAIaaS integrates 15 DeFi protocol providers, including Aave v3, Jupiter, Lido, Jito, Hyperliquid, Kamino, and Pendle. An agent with the right session permissions and policies configured can:

Swap tokens on Jupiter (Solana) or 0x (EVM)
Supply assets to Aave for yield while idle
Stake SOL via Jito or ETH via Lido
Trade perpetual futures on Hyperliquid
Bridge funds across chains via LI.FI or Across

# Agent executes a Jupiter swap autonomously
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"
  }'

This is treasury management at the agent level. An agent that earns revenue (via x402 or other means) can park idle funds in yield-bearing positions, rebalance based on market conditions, and manage its own economic sustainability — within whatever constraints its operator configured.

Before the Agent Spends: Dry-Run Simulation

One feature worth calling out explicitly for autonomous agent contexts: the dry-run API. Before any transaction executes, you can simulate it against the full policy engine and get back the expected outcome — without actually sending anything.

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

For agents making decisions about whether to proceed with a payment, this is genuinely useful. The agent can check whether a proposed transaction would be allowed — and what tier it would trigger — before committing. It's the difference between an agent that tries to spend and gets blocked, versus an agent that checks its constraints before acting.

Getting Started in Under 10 Minutes

The fastest path from zero to a working autonomous agent wallet:

Step 1: Install the CLI and start WAIaaS

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

Step 2: Create a wallet and session in one command

waiaas quickset --mode mainnet

Step 3: Configure your agent's MCP connection

The quickset command prints a JSON config block. Paste it into your Claude Desktop config file, or run:

waiaas mcp setup --all

Step 4: Set spending policies

Use the REST API or the Admin Web UI at /admin to configure SPENDING_LIMIT and X402_ALLOWED_DOMAINS policies for your agent's wallet.

Step 5: Fund the wallet and let the agent work

Send funds to the wallet address. Your agent now has autonomous payment capability, bounded by the policies you set.

If you prefer Docker:

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

The Docker image runs as a non-root user (UID 1001), includes a healthcheck, and supports auto-provisioning for unattended deployments.

Why This Matters Beyond the Demo

The conversation about AI agents tends to get stuck on capabilities — what the agent can do. The economic layer tends to get treated as a solved problem, or kicked down the road.

It isn't solved. Right now, most agent deployments are economically dependent on their operators in ways that limit what they can actually do autonomously. Every payment requires a human-managed credential. Every API call is billed to a human's account. The agent is autonomous in reasoning but dependent in resources.

x402 changes that relationship. An agent with its own wallet, its own budget, and the ability to make payments autonomously isn't just a more capable agent — it's a different kind of entity. One that can operate at scale, across multiple instances, paying for exactly what it uses, without a human manually managing billing for each one.

WAIaaS is the infrastructure layer that makes that possible today, not in some hypothetical future. The 7-stage transaction pipeline, the 21-type policy engine, the 45 MCP tools, the 15 DeFi integrations — these exist, they're tested (684+ test files across the monorepo), and they're open source.

The agent economy isn't coming. It's here. The question is whether the agents you're building have the wallet infrastructure to participate in it.

What's Next

The WAIaaS documentation and interactive API reference are available at /reference once you have the daemon running — the OpenAPI 3.0 spec is auto-generated at /doc. For a deeper look at how the policy engine works and how to configure it for production agent deployments, the GitHub repository at https://github.com/waiaas/WAIaaS is the authoritative source. The official site at https://waiaas.ai has additional context on use cases and deployment patterns.

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

Wallet Guy — Sat, 19 Sep 2026 16:24:43 +0000

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

DeFi trading bots that can't prove their identity are a liability — and if you're building automated strategies across Jupiter, Aave, Hyperliquid, or Lido, you already know the pain of stitching together 13 different SDKs just to get one bot talking to multiple protocols. There's a better way: a single unified API layer with built-in onchain reputation so your bot isn't just capable — it's verifiable.

The Real Problem: Fragmentation and Trust

If you've ever built a multi-protocol DeFi bot, you've lived the integration nightmare. Jupiter has its own SDK. Aave has another. Hyperliquid is a completely different beast. Drift, Kamino, Pendle, Polymarket — each one requires its own authentication logic, its own transaction construction, and its own error handling. By the time you've wired all of that together, you've written more glue code than actual trading logic.

But there's a deeper issue that doesn't get talked about enough: trust. When your bot executes autonomously — swapping, lending, staking, opening perp positions — how does anyone know it's behaving within sanctioned parameters? How do you prove, on-chain, that your agent has a track record of legitimate operation? ERC-8004 is designed to answer exactly that question, and WAIaaS has it built in.

What ERC-8004 Actually Does

ERC-8004 is an onchain agent reputation and validation standard. It lets a smart contract or protocol check whether an agent has an established reputation before allowing it to interact. Think of it as a credit score for bots — except it lives on-chain and can't be faked.

WAIaaS integrates ERC-8004 directly through its action provider system. The erc8004 provider is one of 15 DeFi protocol integrations baked into the platform, and there are dedicated MCP tools for it: erc8004-get-agent-info, erc8004-get-reputation, and erc8004-get-validation-status. You can query reputation, validate an agent's standing, and enforce a REPUTATION_THRESHOLD policy — all through the same API your bot already uses for swaps and lending.

This matters because DeFi protocols increasingly want to know who (or what) is calling them. An agent with a proven on-chain track record is fundamentally different from an anonymous wallet that just appeared. ERC-8004 gives your bot a verifiable identity that compounds over time.

One API Across 15 Protocols

Before diving into reputation mechanics, let's be concrete about what "unified API" actually means here. WAIaaS integrates 15 DeFi protocol providers:

Solana: Jupiter (swap), Jito (staking), Kamino, Drift, Hyperliquid

EVM: Aave v3, Lido (staking), Pendle, Zerox, D'CENT

Cross-chain: LI.FI, Across

Other: Polymarket, XRPL DEX, ERC-8004

Every single one of these is accessible through the same REST API pattern. Your bot authenticates once with a session token, and then calls whichever protocol it needs. Here's what a Jupiter swap looks like:

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

That's it. No Jupiter SDK. No custom RPC handling. No transaction serialization. The same pattern applies whether you're calling Aave, Lido, or Hyperliquid. Your bot sends a JSON payload with the action parameters; WAIaaS handles protocol-specific construction, signing, and submission.

Building a Reputation-Aware Trading Bot

Here's where it gets interesting from a design perspective. A reputation-aware bot isn't just one that has a good reputation — it's one that enforces reputation checks before interacting with counterparties, and builds its own reputation through consistent, policy-compliant behavior.

Step 1: Set Up the Bot's Identity

Start with the WAIaaS CLI to provision a wallet and create a session for your trading bot:

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

quickset creates wallets and MCP sessions in one step. For a trading bot, you'd then create a dedicated session with constrained permissions — your bot gets its own JWT session token (wai_sess_...) that defines exactly what it can do.

Step 2: Configure Policies That Build Reputation

ERC-8004 reputation is built through consistent, bounded behavior. WAIaaS's policy engine enforces those bounds automatically. With 21 policy types and 4 security tiers (INSTANT, NOTIFY, DELAY, APPROVAL), you define guardrails once and the system enforces them on every transaction.

For a DeFi trading bot, a typical policy stack looks like this:

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

You'd layer this with ALLOWED_TOKENS (default-deny token whitelist), CONTRACT_WHITELIST (only your known protocol contracts), PERP_MAX_LEVERAGE (cap leverage for Hyperliquid or Drift), and VENUE_WHITELIST (restrict which DEXes the bot can touch).

The REPUTATION_THRESHOLD policy is the ERC-8004 integration point: it blocks transactions from agents whose on-chain reputation score falls below a configured minimum. If your bot is interacting with a counterparty agent, you can require that agent to meet a reputation threshold before the trade proceeds.

Step 3: Check Reputation Before Trading

Through the MCP interface, your AI agent can query reputation state before executing. The 45 MCP tools include three specifically for ERC-8004:

erc8004-get-agent-info — retrieve agent metadata and registration status
erc8004-get-reputation — get the current reputation score
erc8004-get-validation-status — check whether an agent passes validation

In practice, a Claude-based trading agent configured via MCP can run a check like "verify the counterparty agent's reputation before executing this trade" as a natural language instruction. Claude calls the appropriate MCP tool, gets the validation status, and proceeds (or doesn't) based on the result.

Step 4: Simulate Before You Execute

Reputation isn't just about who your bot interacts with — it's about your bot's own track record. A bot that never fails policy checks and never reverts transactions builds reputation faster. WAIaaS's dry-run API lets you validate every trade before committing:

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

Run this before every execution. If the simulation fails — policy denial, insufficient balance, gas condition not met — you learn that without burning gas or generating a failed transaction on-chain. Fewer failed transactions means cleaner reputation growth.

Step 5: Gas-Conditional Execution

DeFi bots that execute at bad gas prices get crushed on EVM chains. WAIaaS has a gas condition stage in its 7-stage transaction pipeline: transactions execute only when gas price meets your configured threshold. This isn't something you need to implement — it's built into the pipeline at stage level. Your bot submits the transaction; the pipeline handles gas gating automatically.

The TypeScript SDK Path

If you prefer SDK over raw REST calls, the TypeScript SDK gives you the same access with type safety:

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

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

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

// Execute action and poll for confirmation
const sendResult = await client.sendToken({
  type: 'TRANSFER',
  to: 'recipient-address',
  amount: '0.001',
});

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

Handle policy denials explicitly — your bot's error handling should distinguish between retryable errors and hard policy blocks:

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

A POLICY_DENIED error is not retryable — don't hammer the API. Log it, alert, and wait for human review via the APPROVAL flow.

Approval Flow for High-Stakes Trades

When a trade exceeds your DELAY tier threshold, it goes into a queue. The human owner receives a notification and must approve via WalletConnect or Telegram before execution. This is the APPROVAL security tier in action:

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

For a DeFi bot, this is the right behavior for large positions. Your bot proposes the trade; a human reviews and signs off. The ERC-8004 angle here is that consistent use of proper approval flows — rather than trying to circumvent limits — is exactly the kind of on-chain behavior that builds long-term reputation.

Quick Start: DeFi Bot in 5 Steps

Install and start:

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

Configure policies via the REST API — at minimum: SPENDING_LIMIT, ALLOWED_TOKENS, CONTRACT_WHITELIST
Set up MCP for AI agent access:

   waiaas mcp setup --all

Install the TypeScript SDK and wire up your trading logic:

   npm install @waiaas/sdk

Deploy with Docker for production:

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

What's Next

The combination of 15 integrated DeFi protocols, a 21-policy enforcement engine, and ERC-8004 onchain reputation means you can build bots that are not just capable but auditable and trustworthy by design. Every trade within policy bounds, every simulation before execution, every approval for high-stakes positions — it all compounds into a verifiable track record.

Explore the full codebase and self-host your own instance at https://github.com/waiaas/WAIaaS, or check the documentation and hosted options at https://waiaas.ai. The OpenAPI spec is available at /doc and the interactive reference UI at /reference once your daemon is running — start there to understand the full surface area before wiring up your strategy.

Tags: #defi #web3 #blockchain #tutorial

Production AI Wallet Deployment: GHCR Image with Auto-Provision and Secrets

Wallet Guy — Sat, 19 Sep 2026 11:11:11 +0000

Production AI Wallet Deployment: Self-Hosting WAIaaS with Docker, Auto-Provision, and Secrets

Deploying a self-hosted AI wallet means your agent's private keys never leave your server — and with WAIaaS's Docker image on GHCR, you can have the whole stack running in a single command. If you've ever asked yourself whether you'd hand over signing authority for an autonomous agent to a third-party service you don't control, this post is for you. We'll walk through exactly how to get WAIaaS running in production on your own hardware, with proper secret management and automatic provisioning from the start.

Why Self-Hosting an AI Wallet Actually Matters

There's a philosophical argument and a practical one. The philosophical argument is simple: private keys are the root of custody. If someone else holds them — even behind a well-intentioned API — they hold the assets. For autonomous AI agents that sign transactions without human approval for every action, that's a significant trust delegation.

The practical argument is about control over your own infrastructure. Self-hosting means you define the network exposure, the security policies, the update schedule, and the backup strategy. There are no rate limits imposed by a third party on your wallet operations. You're not subject to a remote service going down during a critical trading window. Your agent's transaction history stays on your server. For developers building serious agent infrastructure, or privacy-conscious enthusiasts running homelab setups, that level of ownership matters a lot.

WAIaaS is an open-source, self-hosted Wallet-as-a-Service designed specifically for AI agents. It runs as a Docker container, exposes a REST API your agents call, and never requires your keys to leave the machine. Let's get it running properly.

The WAIaaS Docker Image

WAIaaS publishes a Docker image at ghcr.io/waiaas/waiaas:latest. There are actually two Docker images in the project — the main WAIaaS daemon and a push-relay service for notifications — but for the core wallet infrastructure, you're working with the daemon image.

The daemon listens on port 3100 by default, bound to 127.0.0.1 so it's not exposed to the network unless you explicitly configure that. The data directory at /data is where everything persistent lives — wallets, sessions, policy configuration, and the SQLite database.

Here's the simplest possible production-ready deployment:

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

The WAIAAS_AUTO_PROVISION=true flag is important. On first start, instead of blocking and waiting for you to set a master password interactively, the container generates a cryptographically random password and writes it to /data/recovery.key. You retrieve it once, store it somewhere safe, and the daemon is running without any manual intervention. This is the pattern that makes WAIaaS deployable in automated infrastructure — no interactive prompts blocking your container startup.

A Proper Docker Compose Setup

For anything beyond a quick test, you want a Compose file. Here's the production-ready version:

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

Port binding: 127.0.0.1:3100:3100 means the API is only reachable from localhost. If your AI agent runs on the same machine, this is correct. If you're putting a reverse proxy in front (nginx, Caddy, Traefik), the proxy connects to this port locally and you expose TLS externally. Never bind to 0.0.0.0:3100 in production without a firewall rule or auth layer in front.

Named volume: Using waiaas-data as a named volume rather than a bind mount gives Docker responsibility for managing the data path. docker compose down preserves the volume. docker compose down -v removes it. Be aware of that difference when running maintenance commands.

Healthcheck: The built-in healthcheck polls /health every 30 seconds. This integrates with Docker's health status, which means orchestrators and monitoring tools can detect when the daemon is actually ready rather than just when the container process has started.

restart: unless-stopped: The daemon comes back automatically after a server reboot, which is what you want for anything running agents that need to be continuously available.

Managing Secrets in Production

The auto-provision flow is great for getting started, but in production you want secrets managed properly — not sitting in environment variables that show up in docker inspect output or in your shell history.

WAIaaS supports Docker Secrets through a docker-compose.secrets.yml overlay file. The pattern is to create secret files with restricted permissions, then deploy with both compose files:

# 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 overlay approach is deliberate — your base docker-compose.yml can be committed to version control without secrets, and docker-compose.secrets.yml stays out of git (add it to .gitignore). This is a cleaner separation than environment variable files and fits well with secret management tools like Vault or cloud-provider secret stores that can write files to the secrets directory.

Key Environment Variables

Once you're past the initial setup, you'll want to configure RPC endpoints and other runtime parameters. The most important ones:

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

The RPC endpoint variables are important for self-hosters. WAIaaS supports 18 networks across EVM and Solana chain types, and you'll want to point to your own RPC nodes or a service where you control the API key. Running your own agents against a shared public RPC endpoint under load is a recipe for rate limiting at the worst possible moment.

From Zero to Running Agent: The Full Sequence

If you're starting fresh on a machine with Docker installed, here's the complete path from nothing to a wallet your agent can use:

Step 1: Clone and start

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

Step 2: Retrieve your master password

docker exec waiaas cat /data/recovery.key

Store this somewhere safe. This is your masterAuth credential — it controls wallet creation, session management, and policy configuration.

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

Step 4: Create a session for your agent

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

The session token you get back is what your agent uses. It authenticates as sessionAuth — a JWT the agent includes as a Bearer token. The master password never goes anywhere near your agent code.

Step 5: Set a policy before funding

Before you put real funds in, set a spending limit:

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

WAIaaS has a default-deny policy model: transactions are blocked unless you've explicitly configured what's allowed. The policy engine has 21 policy types covering everything from spending limits to DeFi-specific guardrails like maximum perpetual futures leverage and loan-to-value limits for lending positions. Getting at least a SPENDING_LIMIT and ALLOWED_TOKENS policy in place before funding is the self-hoster equivalent of configuring your firewall before opening ports.

The Three-Layer Authentication Model

One thing that surprises people coming from simpler wallet setups is that WAIaaS has three distinct authentication layers, each with a different principal:

masterAuth — The system administrator layer. Uses Argon2id password hashing. Controls wallet creation, session management, and policy configuration. Your agent code should never have this credential.
sessionAuth — The agent layer. JWT tokens (HS256) scoped to a specific wallet. This is what goes in your agent's environment variables. Tokens have configurable TTL, max renewals, and absolute lifetime.
ownerAuth — The fund owner layer. Signs with ed25519 or secp256k1 (SIWS/SIWE). Used for approving high-value transactions that the policy engine has flagged for human review, and for kill-switch recovery.

This separation means that even if an agent's session token is compromised, an attacker can't create new wallets, modify policies, or bypass the approval flow for large transactions. The policy engine sits in the middle — a 7-stage transaction pipeline that every outgoing transaction passes through regardless of which API path initiated it.

Checking Everything Is Running

The API has 39 REST route modules and a full OpenAPI 3.0 spec auto-generated at /doc, with an interactive Scalar reference UI at /reference:

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

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

For day-to-day operations, the useful Docker commands are:

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

The -v flag on down is the one to be careful about. It's there when you need it, but you don't want to run it reflexively during a restart.

The Philosophy Behind Self-Hosting This Stack

Running your own email server used to be the canonical example of self-hosting done right — full control, but genuinely complicated to operate. The knock against it was always the operational burden.

WAIaaS is built to avoid that tradeoff. The Docker image handles auto-provision, Docker Secrets, healthchecks, and runs as a non-root user (UID 1001). The CLI has 20 commands covering everything from initial setup (waiaas init, waiaas start) to backup management (waiaas backup create, waiaas backup list, waiaas backup inspect) to owner key management (waiaas owner connect, waiaas owner disconnect). The waiaas quickset command creates wallets and MCP sessions in one step.

For a homelab running AI agents with real assets, self-hosting this way is meaningfully different from using a hosted wallet service. Your transaction data doesn't leave your server. Your private keys are generated and stored on hardware you control. The policy engine runs locally. If the WAIaaS project went offline tomorrow, your self-hosted instance would keep running indefinitely — there's no cloud dependency in the critical path.

Your keys, your server, your rules. That's not just a slogan when the alternative is autonomous agents signing transactions against keys held by a third party.

What's Next

Once your daemon is running, the next natural step is connecting your AI agents — either through the MCP integration for Claude and other MCP-compatible frameworks, or directly via the TypeScript or Python SDK. The policy engine deserves dedicated time: with 21 policy types covering spending, token whitelists, DeFi position limits, and network restrictions, configuring it properly is what separates a wallet that's safe to leave running overnight from one that isn't.

Explore the full project at https://github.com/waiaas/WAIaaS and the official site at https://waiaas.ai. The codebase is open source, the Docker image is on GHCR, and the 684+ test files give you a reasonable level of confidence in what you're running on your own hardware.

7 Transaction Types in Claude Desktop: Complete MCP Transaction Reference

Wallet Guy — Fri, 18 Sep 2026 17:04:38 +0000

7 Transaction Types in Claude Desktop: Complete MCP Transaction Reference

MCP developers who want to give Claude onchain capabilities have a surprisingly complete toolkit available today — WAIaaS is an MCP server that exposes 45 tools to Claude Desktop, covering every transaction type your agent might need. Add one JSON block to your claude_desktop_config.json, and your Claude agent goes from conversational to onchain in minutes. This post walks through all 7 supported transaction types, shows you exactly what Claude calls under the hood, and gets you running with a working config.

Why Transaction Type Coverage Matters

When you're building an AI agent that touches real money, vague abstractions are dangerous. An agent that can "send stuff" isn't the same as an agent that understands the difference between a raw native transfer, a token approval, and an NFT move. Each of those operations carries different risk profiles, different policy rules, and different confirmation requirements.

WAIaaS models this explicitly. The transaction schema uses a discriminated union of exactly 7 types: Transfer, TokenTransfer, ContractCall, Approve, Batch, NftTransfer, and ContractDeploy. Claude doesn't need to guess what kind of transaction to construct — it picks the right shape, every time, because the MCP tool definitions enforce the schema.

Step 0: Get the MCP Server Running

Before any of the transaction types below work, you need two things: a running WAIaaS daemon and a session token scoped to a wallet.

The fastest path is the CLI quickstart:

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

quickset creates your wallets, generates session tokens, and prints the exact JSON block to paste into Claude Desktop. If you want to register manually, the config looks like this:

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

Or use the auto-register shortcut:

waiaas mcp setup --all

That's it. Restart Claude Desktop, and you'll see the WAIaaS tools available in the tool panel. Now let's look at what Claude can actually do.

The 7 Transaction Types

1. Transfer (Native Token)

The simplest type: send the chain's native token (SOL, ETH, etc.) from the agent's wallet to an address.

When you say "Send 0.1 SOL to this address," Claude calls the send_token MCP tool, which maps to this REST call under the hood:

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

The transaction goes through the 7-stage pipeline: validate → auth → policy → wait → execute → confirm. If your SPENDING_LIMIT policy has a notify_max_usd threshold, you'll get a notification but the transaction still executes. If it hits delay_max_usd, it queues for the delay window. Above that, it requires your explicit approval.

2. TokenTransfer (ERC-20 / SPL Token)

When Claude needs to send a specific token — USDC, WETH, an SPL token — it uses TokenTransfer. The type distinction matters for policy: ALLOWED_TOKENS policy is evaluated against the token address here, and it's default-deny. If you haven't whitelisted the token, the transaction is blocked.

This is why the policy setup matters before you let an agent loose. A minimal USDC whitelist on Solana 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": "ALLOWED_TOKENS",
    "rules": {
      "tokens": [{"address": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v", "symbol": "USDC", "chain": "solana"}]
    }
  }'

Without this, Claude trying to move USDC hits POLICY_DENIED and gets back a structured error it can explain to you.

3. ContractCall (Arbitrary Smart Contract Interaction)

This is the workhorse for DeFi. When Claude calls the execute_action MCP tool for a Jupiter swap, an Aave deposit, or any of the 15 integrated DeFi protocols, it ultimately resolves to a ContractCall transaction type.

The REST layer for a Jupiter swap looks like this:

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

ContractCall transactions are governed by the CONTRACT_WHITELIST policy — also default-deny. You need to explicitly whitelist Jupiter's router address before Claude can swap. This is intentional: an agent that can call arbitrary contracts without restriction is a significant security surface.

The 15 DeFi protocol providers available via action-provider MCP tool include: aave-v3, across, dcent-swap, drift, erc8004, hyperliquid, jito-staking, jupiter-swap, kamino, lido-staking, lifi, pendle, polymarket, xrpl-dex, and zerox-swap.

4. Approve (Token Approvals)

Token approvals are a distinct transaction type in WAIaaS, not just another ContractCall. This matters because approvals have their own policy types: APPROVED_SPENDERS (default-deny whitelist of addresses that can receive approvals), APPROVE_AMOUNT_LIMIT (blocks unlimited approvals), and APPROVE_TIER_OVERRIDE (forces a specific security tier for all approval transactions regardless of amount).

If Claude is preparing a DeFi position that requires approving a DEX router to spend your USDC, it will first construct an Approve transaction. Without APPROVED_SPENDERS configured, this is blocked. This prevents a class of attacks where an agent could be tricked into approving a malicious contract.

Before running an agent that interacts with DeFi, add:

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": "APPROVED_SPENDERS",
    "rules": {
      "spenders": [{"address": "JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4", "name": "Jupiter", "maxAmount": "1000000000"}]
    }
  }'

5. Batch (Atomic Multi-Step Transactions)

Batch lets Claude bundle multiple operations into a single atomic transaction. This is useful for approve+swap in one step, or multi-token portfolio rebalancing. The send_batch MCP tool maps to this type.

On EVM chains with ERC-4337 Account Abstraction enabled, batches execute as a single UserOperation — one signature, one gas payment, atomic success or failure. On Solana, batch transactions use native instruction bundling.

Before executing a batch, Claude 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 simulate-transaction MCP tool and the dryRun flag let Claude reason about what a transaction will do before committing. For batch operations especially, this is worth building into your agent's workflow.

6. NftTransfer

NFT moves are a distinct type with their own resolution path. WAIaaS supports ERC-721 and ERC-1155 on EVM chains and Metaplex NFTs on Solana, with metadata caching so Claude can tell you what you're actually moving before it moves it.

The transfer_nft and list_nfts MCP tools let Claude inventory your NFTs and execute transfers. From Claude Desktop:

User: "Show me my NFTs"
→ Claude calls list_nfts → returns collection with metadata

User: "Transfer the Solana Monkey #4231 to this address"
→ Claude calls transfer_nft with the mint address and recipient

The get_nft_metadata tool resolves metadata before the transfer, so Claude can confirm with you: "This will transfer Solana Monkey #4231 (floor price: X SOL) to address Y. Confirm?" — before the NftTransfer transaction hits the pipeline.

7. ContractDeploy

The seventh type is ContractDeploy — deploying a new smart contract from the agent's wallet. This is the highest-risk transaction type by nature and will almost always land in the APPROVAL security tier under a SPENDING_LIMIT policy given the gas costs involved.

This type is available for agents building onchain systems programmatically — deploying escrow contracts, token contracts, or agent-owned infrastructure. It follows the same pipeline as every other type: validate → auth → policy → wait → execute → confirm.

Security Tiers in Practice

Every one of these 7 types flows through the policy engine with 4 possible outcomes: INSTANT (execute now, no notification), NOTIFY (execute now, notify you), DELAY (queue it, cancellable window), or APPROVAL (you must sign off via WalletConnect, Telegram, or Push).

A realistic policy setup for an agent you trust with small amounts but want oversight on larger moves:

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: Claude acts immediately. $100-$500: acts immediately, you get notified. $500-$2000: queues for 15 minutes, you can cancel. Over $2000: stops and waits for your wallet signature.

When Claude's transaction is blocked by policy, it receives a structured error it can explain:

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

Claude can surface this to you as "This transfer exceeds your daily limit — do you want to approve it manually?" rather than silently failing.

Quick Start: From Zero to All 7 Types in 5 Steps

1. Install the CLI and start the daemon:

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

2. Create wallets and sessions:

waiaas quickset --mode mainnet

3. Paste the printed config into Claude Desktop's config file (or run waiaas mcp setup --all to auto-register).

4. Set up your policies (at minimum: SPENDING_LIMIT, ALLOWED_TOKENS, CONTRACT_WHITELIST, APPROVED_SPENDERS).

5. Open Claude Desktop and try:

"What's my wallet balance?"
"Swap 0.01 SOL for USDC on Jupiter"
"Show my DeFi positions"

Claude will call get_balance, then execute_action with the jupiter-swap provider, then get_defi_positions — all from natural language, all going through your policy rules.

Multi-Wallet Setup

If you're running separate agents for different strategies, you can run multiple MCP server instances, each scoped to a different wallet and session token:

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

Each wallet gets its own policy set, its own session limits, and its own spending controls. Claude Desktop will show both as separate tool namespaces.

Exploring the OpenAPI Reference

The 39 REST API route modules behind all of this are documented at /reference on your running daemon:

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

# Open the interactive Scalar reference UI
open http://127.0.0.1:3100/reference

Every MCP tool has a corresponding REST endpoint — useful if you're debugging what Claude is actually calling, or building your own integration alongside the MCP server.

What's Next

If you're already using Claude Desktop and want to go further, the next step is setting up incoming transaction monitoring so your agent gets notified of deposits, and configuring WalletConnect so you can approve high-value transactions from your phone. The full 45-tool MCP reference and all policy types are documented in the WAIaaS repo.

GitHub: https://github.com/waiaas/WAIaaS — self-host, browse the source, open issues
Official site: https://waiaas.ai — docs, guides, and release notes

20 CLI Commands for Complete Self-Hosted Wallet Management: From Setup to Backup

Wallet Guy — Fri, 18 Sep 2026 11:27:47 +0000

20 CLI Commands for Complete Self-Hosted Wallet Management: From Setup to Backup

Self-hosted wallet management for AI agents means your private keys never leave your server — and WAIaaS gives you a full CLI with 20 commands to set up, operate, and back up your entire wallet infrastructure without trusting a single third party. If you've ever run your own email server, your own VPN, or your own Nextcloud instance, you already understand the philosophy: ownership is worth the extra ten minutes of setup.

Why Self-Hosting Your Agent's Wallet Actually Matters

Here's the uncomfortable question: would you hand your private keys to a hosted service you don't control, just because it's convenient? For personal wallets, most people already know the answer. For AI agent wallets, the question is even sharper. An agent wallet isn't just holding funds — it's actively executing transactions, interacting with DeFi protocols, and potentially moving significant value on your behalf.

Hosted wallet services come with trade-offs that are easy to overlook: rate limits that can stop your agent mid-task, API terms that can change overnight, custody arrangements where someone else technically controls your keys, and privacy implications around transaction metadata. Self-hosting eliminates all of that. WAIaaS runs entirely on your hardware, behind your firewall, with your keys in your encrypted data directory. No phone-home, no usage telemetry you didn't consent to, no third-party rate limits.

The CLI is how you manage all of it from the terminal — which is exactly where self-hosters want to be.

The 20 Commands, Organized by What You're Actually Doing

WAIaaS ships a CLI with exactly 20 commands (fact CLI-01). Rather than dumping them as a flat list, here's how they map to the actual lifecycle of running your own wallet infrastructure.

Getting Started: `init`, `start`, `stop`, `status`, `quickstart`, `quickset`

Everything begins with init. This creates your data directory and config.toml. It's the git init of your wallet infrastructure.

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

quickstart gets you running with sensible defaults in the least number of steps. quickset is slightly more deliberate — it creates wallets and MCP sessions for you but lets you specify a mode. For self-hosters who want to automate first-run provisioning (say, in a Docker entrypoint or an Ansible playbook), there's an auto-provision flag:

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

That pattern — auto-provision for first boot, set-master to harden later — is exactly what you want for unattended server deployments. The recovery.key file holds your auto-generated master password. Lock it down, back it up, then replace it with something you've chosen yourself once you're ready.

stop and status are exactly what they sound like. status is particularly useful for health-checking from a monitoring script or a cron job.

Wallet Operations: `wallet create`, `wallet info`

Once your daemon is running, you create wallets:

waiaas wallet create   # Interactive wallet creation
waiaas wallet info     # Show wallet details, address, chain

Under the hood, wallet creation is also exposed via the REST API if you want to script it:

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

The CLI wraps this in an interactive flow, which is friendlier for manual setup. For automation, the API is the right tool. Both paths lead to the same place: a wallet whose keys live in your encrypted local data directory, on hardware you control.

WAIaaS supports 2 chain types (EVM and Solana) across 18 networks (fact NET-01). That covers the chains where most real AI agent activity happens today.

Session Management: `session prompt`, `set-master`

Sessions are how AI agents authenticate. You create a session token, hand it to your agent (via environment variable, MCP config, or SDK constructor), and the agent uses it to sign transactions, check balances, and execute DeFi actions — all scoped to a specific wallet.

session prompt generates a session token interactively. set-master lets you change or harden your master password — the root credential that protects everything else.

WAIaaS uses three distinct auth layers (fact SEC-02):

masterAuth (Argon2id) — system administrator operations like wallet creation and policy management
ownerAuth (SIWS/SIWE) — fund owner approval for sensitive transactions
sessionAuth (JWT HS256) — day-to-day agent operations

This separation matters for self-hosters. Your master password stays on the server. Your session tokens are scoped and can be rotated without touching your keys. Your owner auth is a signature from a wallet you control independently — it's the kill switch that doesn't depend on the server at all.

Owner Control: `owner connect`, `owner disconnect`, `owner status`

The owner commands hook into WalletConnect (fact FEAT-WC), letting you connect your personal wallet as the fund owner. This is how you approve transactions that exceed your policy thresholds — the agent submits a transaction, the policy engine routes it to APPROVAL tier, and you get a notification to your connected wallet app.

waiaas owner connect    # Connect owner wallet via WalletConnect
waiaas owner status     # Check connected owner wallet
waiaas owner disconnect # Disconnect owner wallet

For self-hosters, this is the human-in-the-loop bridge. Your AI agent can operate autonomously within the spending limits and whitelists you've defined, but anything that exceeds those limits requires your explicit cryptographic approval. No third party can approve transactions on your behalf — that's the point.

Notifications: `notification setup`

waiaas notification setup   # Configure notification channels

WAIaaS supports multiple signing channels including push relay, Telegram, and wallet notification channels (fact SIGN-01). notification setup walks you through connecting one of them. Self-hosters who run their own Telegram bots or push notification infrastructure can route alerts through those.

MCP Integration: `mcp setup`

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

This is the command that takes your self-hosted daemon and wires it into AI agent frameworks like Claude Desktop. It writes the MCP server configuration JSON that Claude (or any MCP-compatible client) reads at startup. The --all flag registers every wallet you've created as a separate MCP server entry.

The MCP package (@waiaas/mcp) exposes 45 tools (fact MCP-01) covering wallet queries, transactions, DeFi actions, NFT operations, and x402 payment handling. After running mcp setup, your AI agent can check balances, swap tokens, query DeFi positions, and more — all authenticated through the session token scoped to the wallet you've configured.

A typical multi-wallet MCP config looks like this:

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

The daemon is running locally, the base URL points to 127.0.0.1:3100, and no traffic goes to an external service. That's self-hosted MCP wallet infrastructure in the most literal sense.

Backup and Restore: `backup create`, `backup inspect`, `backup list`, `restore`

This is where self-hosting gets serious. If you're running your own infrastructure, you're responsible for your own backups. WAIaaS gives you four commands to manage this properly.

waiaas backup create   # Create an encrypted backup of wallet data
waiaas backup list     # List available backups
waiaas backup inspect  # Inspect a specific backup file
waiaas restore         # Restore from a backup

The backup create command should be part of your regular cron schedule. Backup to an encrypted external drive, an S3-compatible bucket you control (MinIO on your NAS works perfectly), or an off-site server you manage. backup inspect lets you verify a backup before you need it — not after. restore gets you back to a known-good state if your server dies.

This is the self-hosted responsibility that hosted services hide from you. It's also the self-hosted superpower: you have the backup, on your hardware, in your custody. Nobody can lose it for you.

Updates: `update`

waiaas update   # Update the WAIaaS daemon to the latest version

If you're running via Docker (more on that below), Watchtower can handle this automatically. If you're running the CLI-managed daemon directly, update is your command for pulling the latest version.

Running It All in Docker

For homelab setups, Docker is often the cleaner path. WAIaaS ships a production-ready Docker image (fact DOCKER-01):

# Clone and start — that's it
git clone https://github.com/waiaas/WAIaaS.git
cd WAIaaS
docker compose up -d

The default port binding is 127.0.0.1:3100:3100 (fact DOCKER-02) — localhost only, not exposed to the network by default. That's a sensible security default for a service that manages private keys.

For a single-container start with auto-provisioning:

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

For production, use Docker Secrets instead of environment variables for your master password (fact DOCKER-03):

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

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

The secrets overlay (docker-compose.secrets.yml, fact DOCKER-04) keeps your credentials out of environment variables and process lists. Healthcheck is built in, the container runs as a non-root user (UID 1001, fact FEAT-DOCKER), and you can wire up Watchtower for automatic updates.

The Policy Layer: Why Your Self-Hosted Agent Isn't Just a Hot Wallet

Running your own wallet infrastructure doesn't mean running without guardrails. WAIaaS includes a policy engine with 21 policy types and 4 security tiers (fact POLICY-01, POLICY-02).

The most important thing to understand about the policy engine is that it's default-deny (fact SEC-03). If you haven't explicitly whitelisted a token or contract, transactions involving it are blocked. This is the right default for an autonomous agent — restrict first, expand as needed.

A basic spending limit 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
    }
  }'

Under \$100: executes immediately. \$100–\$500: executes and notifies you. \$500–\$2,000: queues for 15 minutes (cancellable). Over \$2,000: requires your explicit approval. You set these thresholds. They live on your server. No hosted service is enforcing them on your behalf — you are.

Quick Start: Five Steps to a Running Self-Hosted Setup

Install the CLI: npm install -g @waiaas/cli
Initialize and start: waiaas init --auto-provision && waiaas start
Create wallets and sessions: waiaas quickset --mode mainnet
Wire up MCP: waiaas mcp setup --all → paste config into Claude Desktop
Schedule backups: waiaas backup create in a daily cron job

That's the full path from zero to a running self-hosted AI agent wallet, with MCP integration and backups in place.

What's Next

The CLI gives you the operational layer — starting, stopping, creating wallets, managing sessions, and keeping backups. The REST API (39 route modules, fact API-01) gives you the programmable layer for integrating WAIaaS into your own tooling and agents. Between the two, you have everything you need to run production wallet infrastructure on hardware you own.

Start with the GitHub repository at https://github.com/waiaas/WAIaaS, or visit https://waiaas.ai for documentation and the full list of supported chains and DeFi protocols. Your keys, your server, your rules.

Trustless AI Commerce: How ERC-8004 Reputation Enables Autonomous Economic Agents

Wallet Guy — Thu, 17 Sep 2026 17:36:57 +0000

Trustless AI Commerce: How ERC-8004 Reputation Enables Autonomous Economic Agents

AI agents will need to pay for compute, data, and API calls — and right now, the infrastructure to let them do that autonomously barely exists. We talk endlessly about agents that can reason, plan, and act, but the moment one of those agents needs to spend money, we fall back to humans holding the keys. That gap between "autonomous agent" and "agent that can actually participate in economic activity" is exactly what trustless wallet infrastructure is built to close.

The Problem Nobody Talks About at the AGI Conference

Here's a scenario that plays out constantly in production AI systems today: an agent needs to call a paid API, execute a trade, or pay for inference compute. So what happens? A human pre-loads a balance into some custodied account, the agent draws from it, and a human periodically reviews the spending.

That's not autonomous economic activity. That's a very complicated expense account.

The deeper issue is trust — specifically, the lack of a mechanism for counterparties to verify that an agent is what it claims to be, that it will honor its obligations, and that it has the authority to spend the funds it's trying to spend. In human commerce, we have credit scores, corporate registration, banking relationships, and legal liability. For AI agents, we have... vibes.

ERC-8004 is an attempt to change that. It's a standard for onchain agent reputation and validation — a way to assign verifiable identity and track record to an autonomous agent so that other parties in a transaction can make informed decisions about whether to transact with it. And WAIaaS, an open-source self-hosted Wallet-as-a-Service for AI agents, ships with ERC-8004 support built in.

This isn't vaporware. It exists today. Let's talk about what that actually means.

What ERC-8004 Actually Does

The concept is straightforward even if the implementation is not. An AI agent — or rather, the wallet infrastructure backing that agent — registers an onchain identity. Over time, as the agent completes transactions, fulfills obligations, and operates within defined parameters, that identity accumulates a reputation score. Other parties can query that reputation before deciding whether to transact.

Think of it like a credit score for machines, except it's transparent, onchain, and queryable by any counterparty without a centralized bureau acting as gatekeeper.

WAIaaS exposes this through two MCP tools that Claude and other AI frameworks can call directly:

erc8004-get-agent-info — retrieve the registered identity and metadata for an agent
erc8004-get-reputation — query the current reputation score
erc8004-get-validation-status — check whether an agent passes validation thresholds

The policy engine also has a corresponding REPUTATION_THRESHOLD policy type. This means you can configure a wallet so that it will only transact with counterparties whose onchain reputation meets a minimum bar. Default-deny applies here too: if the counterparty doesn't have a verifiable reputation, the transaction doesn't go through.

This is the foundation of trustless AI commerce — not a pinky promise that an agent is well-behaved, but a cryptographically verifiable track record that any party in the system can inspect.

The Infrastructure Layer: Wallets for Autonomous Agents

Before we get further into reputation, it's worth being precise about what "autonomous wallet infrastructure" means in practice, because it's doing a lot of work.

WAIaaS is a 15-package monorepo that you self-host. The core component is a daemon that exposes 39 REST API routes and communicates with AI agents through 45 MCP tools. It supports 18 networks across EVM and Solana. It has a 7-stage transaction pipeline. It integrates with 15 DeFi protocols.

None of that is relevant if the mental model is wrong. So here's the mental model:

There are three principals in the system, and they have different levels of trust.

The owner — the human (or organization) that funds the wallet. They authenticate with ownerAuth using SIWE or SIWS signatures. They set policy, approve high-value transactions, and hold the kill switch.
The master — the system administrator role that creates wallets and sessions. Authenticates with masterAuth using Argon2id. This is typically infrastructure automation, not a human sitting at a keyboard.
The session — the AI agent. It gets a JWT that scopes what it can do. It authenticates with sessionAuth. It operates entirely within the policy envelope the owner and master have defined.

The agent never holds the private key. It holds a session token that lets it request transactions. The daemon handles signing. This is the critical architectural choice that makes autonomous operation safe: the agent has economic agency (it can initiate spending decisions) without having custody (it can't drain the wallet by bypassing controls).

A Policy Engine That Actually Enforces Rules

The policy engine is where the rubber meets the road on autonomous operation. WAIaaS has 21 policy types and 4 security tiers: INSTANT, NOTIFY, DELAY, and APPROVAL.

Here's what a 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
    }
  }'

That's not pseudocode. That's the actual API call. A transaction under $100 executes immediately. Between $100 and $500, it executes immediately but the owner gets notified. Between $500 and $2,000, it gets queued for 15 minutes — enough time for the owner to cancel if something looks wrong. Over $2,000, it requires explicit owner approval through WalletConnect, Telegram, or a push notification.

The REPUTATION_THRESHOLD policy type fits into the same framework. You set a minimum reputation score, and the policy engine enforces it at transaction time. If the counterparty doesn't meet the threshold, the transaction is denied with a POLICY_DENIED error — the same structured error format used throughout the system:

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

Other policy types relevant to autonomous agent operation include CONTRACT_WHITELIST (the agent can only interact with pre-approved contracts), ALLOWED_TOKENS (default-deny token whitelist), X402_ALLOWED_DOMAINS (more on this in a moment), and VENUE_WHITELIST (allowed trading venues).

Default-deny is not a configuration option. It's the baseline. An agent operating without explicit allowlists set cannot move tokens to arbitrary addresses or call arbitrary contracts. You grant permissions explicitly; you don't restrict from an open default.

x402: The HTTP Payment Layer for Machine Commerce

ERC-8004 reputation handles identity and trust. But how does an agent actually pay for things at the HTTP layer?

The x402 protocol is a proposed extension to HTTP where a server responds with HTTP 402 (Payment Required) and an attached payment claim. The client — in this case, an AI agent — pays the claim and resubmits the request. The whole thing happens in-band with the HTTP request, without any human in the loop.

WAIaaS has native x402 support. The MCP tool is called x402-fetch, and the TypeScript SDK exposes it as client.x402Fetch(). The policy engine has X402_ALLOWED_DOMAINS so you can restrict which domains the agent is permitted to pay automatically.

The practical implication: an AI agent can call a paid API, receive a 402 response, pay it from its wallet, and complete the request — all autonomously, all within the spending limits and domain restrictions you've configured. No human clicks "approve payment." The policy envelope does that work.

This is what machine-to-machine commerce actually looks like. Not a billing portal. Not a human reviewing invoices. An agent with a wallet, a reputation, and a set of rules it operates within.

Getting Something Running

If you want to see this in practice rather than read about it, here's the minimal path:

Step 1: Start the daemon

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.

Step 2: Create a wallet and session

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

Step 3: Set a spending policy

Before your agent touches real funds, set a spending limit. The example from earlier — $100 instant, $500 notify, $2,000 delay with 15-minute queue, $5,000 daily cap — is a reasonable starting point for a trading agent.

Step 4: Connect to Claude via MCP

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

Or use the CLI shortcut:

npm install -g @waiaas/cli
waiaas mcp setup --all

From there, Claude has access to 45 MCP tools covering wallet operations, transactions, DeFi positions, NFTs, and x402 payments. It can check balances, execute swaps on Jupiter, query DeFi positions across 15 integrated protocols, and pay for API calls via x402 — all within the policy constraints you've defined.

The Bigger Picture

The reason this matters beyond the technical specifics is that we're at an inflection point. The question of whether AI agents will participate in economic activity is largely settled — of course they will. The open question is whether that participation will be trustless and transparent, or whether it will require humans as intermediaries at every step.

Trustless doesn't mean unsupervised. The policy engine, the security tiers, the owner approval flow, the WalletConnect integration for human-in-the-loop signing — all of that exists precisely because autonomous operation needs guard rails. The goal isn't to remove humans from the picture. It's to make human oversight scalable — to let an owner set policy once and then have the system enforce it consistently across thousands of agent transactions, surfacing only the exceptions that genuinely require human judgment.

ERC-8004 reputation is one piece of that puzzle. It gives agents verifiable identity that accumulates over time. Combined with the x402 payment layer, the policy engine, and the session-based auth model, it starts to look like the infrastructure layer that autonomous economic agents actually need.

That infrastructure exists today. It's open-source. You can run it on your own hardware. The 684+ test files suggest the team takes correctness seriously. The interactive API reference at /reference means you don't have to guess at the API shape.

What's Next

If you're building agents that need economic autonomy, the place to start is the WAIaaS GitHub repository — the README has the quickstart path, and the codebase is the authoritative source on what's actually implemented. For a broader overview of capabilities and deployment options, waiaas.ai has the documentation. The most productive next step is probably standing up a local instance with Docker Compose, creating a test wallet, and seeing what the policy engine actually enforces — reading about default-deny is less convincing than watching a transaction get blocked because you forgot to configure ALLOWED_TOKENS.

Self-Hosted Crypto Infrastructure Monitoring: Docker Healthcheck + Service Recovery

Wallet Guy — Thu, 17 Sep 2026 11:52:03 +0000

Self-Hosted Crypto Infrastructure Monitoring: Docker Healthcheck + Service Recovery

Running your own self-hosted crypto infrastructure means you're the one accountable when something goes wrong at 2 AM — no support ticket, no status page to refresh, just you and your logs. If your AI agent's wallet daemon goes down mid-trade or during an automated DeFi rebalance, you want to know immediately and recover fast. This post walks through how WAIaaS is built for exactly that scenario: a self-hosted wallet service you can monitor, heal, and operate with full sovereignty over your keys and your server.

Why Self-Hosting Your Agent's Wallet Matters

There's a philosophical question hiding inside every "just use the hosted API" pitch: who actually controls the keys?

When your AI agent executes a token swap, approves a spend, or pays for an API call via the x402 protocol, it's signing transactions. That signing requires private key material. If a third-party service holds those keys, you've introduced custody risk, rate limit risk, and — critically for privacy-conscious operators — a full transaction history that lives on someone else's server.

The alternative is running your own wallet infrastructure. The tradeoff is real: you own the operational burden. But with modern Docker tooling, that burden is much lower than it used to be. WAIaaS ships as a self-contained Docker image with healthchecks, secret management, and a recovery model baked in. The goal of this post is to show you how those pieces fit together so your self-hosted setup stays online and recovers gracefully when it doesn't.

What WAIaaS Ships With, Out of the Box

WAIaaS is a 15-package monorepo that deploys as two Docker images: the main daemon and a push-relay service for notifications. The daemon is the one you'll spend most of your time thinking about — it's the process that holds wallet state, processes transactions through a 7-stage pipeline, and serves a REST API across 39 route modules.

For self-hosters, the relevant defaults are already sensible:

Default port binding: 127.0.0.1:3100:3100 — localhost-only by default, so you're not accidentally exposing the API to the network
Non-root process: runs as UID 1001 inside the container
Built-in healthcheck in the Docker Compose file
Auto-provision mode for first-run password generation
Docker Secrets support for production credential management

Here's the full Compose file WAIaaS ships with:

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 highlighting here for anyone running production homelab services:

restart: unless-stopped — Docker will automatically restart the container after crashes or host reboots. The exception is if you explicitly stop it with docker compose down, which is the right behavior: you don't want Docker fighting you when you intentionally bring the service down for maintenance.

Named volume (waiaas-data) — Wallet state, encrypted keys, and transaction history persist in a named volume independent of the container lifecycle. Running docker compose down preserves your data. You'd need docker compose down -v to actually delete it, which is a safe default that protects against accidental data loss.

Healthcheck with start_period: 10s — The daemon gets 10 seconds to initialize before Docker starts counting health failures. This prevents restart loops on slower hardware where startup takes a moment.

First-Run Setup: Auto-Provision and Recovery Keys

The most friction in self-hosted services is usually the first run. WAIaaS solves this with auto-provision mode, which 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

This is the crypto equivalent of a router generating a random WiFi password on first boot — you get something secure immediately, and you can harden it later. The CLI workflow for this is:

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 set-master step is important. Once you've rotated to a password you control and stored securely (a password manager, not a plaintext file), delete recovery.key. The auto-provision key is a bootstrap mechanism, not a permanent credential.

Secrets Management for Production

For anyone running this on a VPS or home server with more than one user account, environment variables in .env files are a step up from hardcoding credentials, but Docker Secrets is the right answer for production.

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

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

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

The secrets overlay pattern means your actual credentials never appear in environment variables that show up in docker inspect output or process listings. This matters if you're running on shared infrastructure or if you're security-conscious about what ends up in container metadata.

Monitoring: What to Watch

The healthcheck gives Docker the signal it needs to restart unhealthy containers, but for actual observability you want more than "is the process alive." Here are the three things worth monitoring on a self-hosted WAIaaS instance:

1. The Health Endpoint

curl http://127.0.0.1:3100/health

This is what the Docker healthcheck pings. Wire this into whatever uptime monitoring you use — Uptime Kuma, Healthchecks.io, a simple cron that sends you a Telegram message. The point is that the daemon's liveness is externally observable without any special credentials.

2. Log Streaming

docker compose logs -f

WAIaaS has configurable log levels via WAIAAS_DAEMON_LOG_LEVEL. For normal operation, info is fine. When you're debugging a transaction that got stuck in the pipeline, dropping to debug gives you stage-by-stage visibility through the 7-stage transaction pipeline (validate → auth → policy → wait → execute → confirm).

For persistent log storage, pipe to a file or use Docker's logging driver:

docker compose logs -f >> /var/log/waiaas/daemon.log 2>&1 &

3. Incoming Transaction Monitoring

WAIaaS has built-in incoming transaction monitoring with real-time notifications for deposits. This means you don't need a separate indexer watching your wallet addresses — the daemon handles it. Pair this with the notification setup CLI command (waiaas notification setup) and you'll get alerts when funds arrive, not just when your agent sends them.

Service Recovery: What Happens When Things Go Wrong

Let's walk through the failure scenarios you actually care about:

Container Crash

restart: unless-stopped handles this automatically. Docker detects the container exit, waits briefly, and restarts it. The named volume means wallet state is intact. The daemon reinitializes, the healthcheck passes, and your AI agent's next API call succeeds. You'll see the restart in docker compose logs and in docker ps output (the "Restarts" column).

Host Reboot

Same story — Docker's restart policy fires on daemon startup. If you're on a system where Docker starts automatically (most Linux distros with systemctl enable docker), WAIaaS comes back up without manual intervention.

Stuck Transaction in the Pipeline

This is the more interesting failure mode. A transaction can get stuck in the DELAY or APPROVAL tier if it's waiting for human approval that never comes, or if the gas condition stage (which checks that gas price meets your threshold before executing) is holding a transaction while gas is elevated.

The CLI gives you visibility here:

waiaas status    # Daemon status

From the API side, you can check pending transactions directly:

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

For transactions in the APPROVAL tier, the owner approval flow uses WalletConnect or your configured signing channel — push relay or Telegram — so you can approve from your phone without being at your server.

Policy Denial Loops

If your AI agent is getting transactions denied repeatedly, you'll see error responses like:

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

The retryable: false flag tells a well-behaved agent not to hammer the endpoint. The fix is either adjusting the policy (via masterAuth) or using the dry-run API to understand exactly what the policy engine sees before making changes:

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

Dry-run runs the full pipeline including policy evaluation, without submitting the transaction on-chain. It's the fastest way to understand why something is being blocked.

Backup and Restore

The CLI ships with backup create, backup inspect, and backup list commands — 3 of the 20 CLI commands in the WAIaaS CLI. For a self-hosted setup, a sensible backup schedule is:

waiaas backup create before any configuration changes
Automated daily backup to a location outside the Docker volume (external drive, encrypted remote storage)
Periodic waiaas backup inspect to verify backup integrity

The restore path is waiaas restore, which means you can recover from a corrupted volume without losing wallet state — as long as your backups are current.

RPC Endpoints: The Other Dependency You Control

One thing that often gets overlooked in self-hosted crypto infrastructure: even if you control the wallet daemon, you're still dependent on RPC endpoints for reading chain state and submitting transactions. WAIaaS lets you configure your own:

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

For full sovereignty, point these at your own node, a private RPC provider, or a self-hosted RPC proxy. WAIaaS supports 18 networks across EVM and Solana chain types, so you can configure custom RPC endpoints per-network as needed.

Quick Start: Self-Hosted WAIaaS in Five Minutes

Here's the minimal path to a running, monitored instance:

# 1. Clone and start
git clone https://github.com/waiaas/WAIaaS.git
cd WAIaaS
docker compose up -d

# 2. Check it's healthy
curl http://127.0.0.1:3100/health

# 3. Follow logs
docker compose logs -f

Then, install the CLI and run quickset to create wallets and sessions:

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

For MCP integration with Claude Desktop (so your AI agent can actually use the wallet):

waiaas mcp setup --all

That registers all your wallets with Claude Desktop automatically, writing the configuration JSON you'd otherwise have to craft by hand.

What's Next

The monitoring and recovery patterns here are the operational foundation. Once your instance is stable, the natural next step is tightening your policy configuration — understanding the 21 policy types, setting spending limits, and configuring the 4 security tiers so your AI agent operates within the boundaries you've defined without requiring constant approval. The OpenAPI spec at http://127.0.0.1:3100/reference gives you an interactive UI to explore every endpoint, which is useful when you're building custom monitoring scripts or integrating WAIaaS into a broader homelab automation stack.

The full source, Dockerfiles, and documentation are at https://github.com/waiaas/WAIaaS. If you want to understand the project before deploying anything, the official site at https://waiaas.ai has the overview. Your keys, your server, your rules — that's the point.

Admin Dashboard in Claude Desktop: Monitor Your AI Agent's DeFi Portfolio with MCP Tools

Wallet Guy — Wed, 16 Sep 2026 17:37:10 +0000

Admin Dashboard in Claude Desktop: Monitor Your AI Agent's DeFi Portfolio with MCP Tools

MCP tools for DeFi are here — and if you're already using Claude Desktop, you're one config block away from giving your agent a live onchain wallet with the ability to swap, lend, stake, bridge, and monitor positions across 15 integrated protocols. No custom API wiring. No bespoke tool definitions. Just add WAIaaS as an MCP server and Claude inherits 45 ready-made wallet tools the moment it starts.

Why This Actually Matters

Most developers who reach for MCP do so because they want Claude to do things, not just talk about them. Fetching a webpage, running a shell command, querying a database — these are the classic use cases. But onchain actions are a different beast. Signing a transaction requires key management. DeFi positions span multiple protocols and chains. Approvals need to go through a human before real money moves. Wiring all of that up yourself, safely, is weeks of work.

The stakes are also higher than a failed shell command. A misconfigured DeFi action can drain a wallet. An agent with unbounded spending authority is a liability. What you actually need is a wallet layer that's already solved key custody, policy enforcement, and human-in-the-loop approval — and exposes all of it through MCP so Claude can drive it naturally. That's the gap WAIaaS fills.

What WAIaaS Is

WAIaaS is an open-source, self-hosted Wallet-as-a-Service for AI agents. You run it locally (or on a server), it manages wallets across EVM and Solana networks, and it exposes everything through a REST API and — critically for this post — an MCP server.

The MCP server ships as @waiaas/mcp on npm. It registers 45 tools covering wallet queries, token transfers, DeFi actions, NFT operations, and the x402 HTTP payment protocol. When Claude connects to it, those tools appear in Claude's tool list exactly like any other MCP capability. Claude doesn't need to know anything about transaction signing, gas, or RPC nodes. WAIaaS handles all of that under the hood.

The daemon itself is a 15-package monorepo with a 7-stage transaction pipeline (validate → auth → policy → wait → execute → confirm), a policy engine with 21 policy types across 4 security tiers, and 15 integrated DeFi protocol providers. It's not a toy.

The One-Line Config

Here's what the setup looks like in claude_desktop_config.json:

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

That's it. Restart Claude Desktop, and the next conversation has access to all 45 MCP tools. No build step, no SDK to initialize, no WebSocket server to manage. npx pulls the package on demand.

The WAIAAS_SESSION_TOKEN is a JWT scoped to a specific wallet — it's what the WAIaaS policy engine uses to apply spending limits, token whitelists, and approval requirements to every action Claude takes. The agent gets real capabilities, but bounded ones.

The 45 MCP Tools — What Claude Can Actually Do

Once connected, Claude can call tools across five categories:

Wallet & balance

get_balance — native token balance
get_assets — all token balances in the wallet
get_wallet_info — wallet metadata, address, chain
get_address — just the wallet address
get_nonce — current transaction nonce

Transactions

send_token — native or ERC-20/SPL token transfer
send_batch — multiple transfers in one atomic call
sign_message — arbitrary message signing
sign_transaction — sign without broadcasting
simulate_transaction — dry-run before execution
list_transactions — transaction history
get_transaction — single transaction by ID

DeFi

get_defi_positions — lending/staking positions across all protocols
get_health_factor — lending health factor (Aave-style)
action_provider — generic DeFi action dispatcher
hyperliquid — perpetuals, spot, sub-accounts
polymarket — prediction market positions

NFT

list_nfts — all NFTs in the wallet
get_nft_metadata — token metadata with caching
transfer_nft — ERC-721, ERC-1155, or Metaplex transfer

Infrastructure & utility

x402_fetch — HTTP fetch with automatic 402 payment
wc_connect / wc_disconnect / wc_status — WalletConnect session management
get_policies — inspect active policies
list_sessions — active agent sessions
resolve_asset — resolve token symbol to on-chain address
get_tokens — supported token list for a network
get_rpc_proxy_url — proxied RPC endpoint for chain queries

And more — ERC-8004 reputation tools, ERC-8128 signing, UserOp build/sign for Account Abstraction, credential management. The full list of 45 is in the WAIaaS MCP package.

Monitoring Your DeFi Portfolio From Claude Desktop

Let's make this concrete. After connecting WAIaaS as an MCP server, you can open Claude Desktop and ask:

"Show me my DeFi positions across all protocols"

Claude calls get_defi_positions, which queries WAIaaS across all 15 integrated protocol providers — Aave v3, Kamino, Lido, Jito, Pendle, and others — and returns a structured summary of your lending positions, staked assets, and liquidity. You can then ask follow-up questions and Claude will call get_health_factor to check your lending safety margin, or get_assets to compare your liquid balance against locked positions.

This is a genuine admin dashboard experience, except the "dashboard" is a conversation and the "widgets" are tool calls.

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

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

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

The Jupiter swap example above goes through the full WAIaaS transaction pipeline. If you've set a SPENDING_LIMIT policy with an instant_max_usd of $10, a small swap executes immediately. A larger one triggers NOTIFY or DELAY depending on your thresholds, and anything above delay_max_usd requires explicit owner approval via WalletConnect or Telegram before it executes.

Running Multiple Wallets as Separate MCP Servers

If you're running multiple agents — say, a trading wallet on Solana and a separate EVM wallet for Ethereum DeFi — you can register each as its own MCP server with its own session token and policy set:

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

Claude Desktop will show both as distinct tool namespaces. Each wallet has its own session, its own policy set, and its own transaction history. The daemon is a single process managing both.

The Policy Layer — Why This Is Safe to Actually Use

The thing that makes 45 MCP tools pointed at a live wallet usable rather than terrifying is WAIaaS's policy engine. Every transaction Claude initiates goes through a 7-stage pipeline, and the policy stage runs before anything touches the chain.

The engine supports 21 policy types. The most important ones for an MCP-connected agent:

SPENDING_LIMIT — 4-tier security: INSTANT (execute immediately), NOTIFY (execute + alert you), DELAY (queue for N seconds, cancellable), APPROVAL (require your explicit sign-off)
ALLOWED_TOKENS — default-deny token whitelist; Claude can only transfer tokens you've explicitly listed
CONTRACT_WHITELIST — Claude can only call contracts on this list
X402_ALLOWED_DOMAINS — Claude can only auto-pay 402 responses from domains you've approved
PERP_MAX_LEVERAGE — caps the leverage Claude can use on Hyperliquid positions

Default-deny is the key property here. If you haven't configured ALLOWED_TOKENS, token transfers are blocked. If you haven't configured CONTRACT_WHITELIST, contract calls are blocked. Claude can ask for things; the policy engine decides whether they happen.

You configure policies via the REST API:

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

That policy says: under $100, Claude acts instantly. $100–$500, Claude acts and you get a notification. $500–$2,000, Claude waits 15 minutes before executing (giving you time to cancel). Over $2,000, nothing moves without your approval.

Quick Start: From Zero to Claude + Wallet in 5 Steps

Step 1 — Install the CLI and start the daemon

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

Step 2 — Create a wallet and session

waiaas quickset --mode mainnet

quickset creates wallets and MCP sessions in one step and prints the config JSON you need.

Step 3 — Or use the auto-provision Docker path

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 — Register WAIaaS as an MCP server in Claude Desktop

Paste the config block from Step 2 into ~/Library/Application Support/Claude/claude_desktop_config.json. Or run:

waiaas mcp setup --all

Step 5 — Set a spending policy, then open Claude

Create at least a SPENDING_LIMIT policy (see the curl example above), restart Claude Desktop, and start a conversation. Ask Claude to check your balance — it will call get_balance and return a real answer.

What's Next

The 45 MCP tools are the surface layer. Underneath is a daemon with 39 REST API route modules, a TypeScript SDK (@waiaas/sdk) with 40+ methods, and a Python SDK — so you can build agents that use WAIaaS programmatically, not just through Claude. The OpenAPI 3.0 spec auto-generates at /doc and there's an interactive reference UI at /reference if you want to explore the full API before writing any code.

If you hit a transaction that needs human approval, WAIaaS routes it through WalletConnect, Telegram, or a push notification — your choice — so you can approve from your phone without leaving the app you're already using.

The source is at github.com/waiaas/WAIaaS and the project site is waiaas.ai. Both are worth bookmarking: the GitHub repo has the full list of supported networks, protocol providers, and policy types, and the site has deployment guides for production setups with Docker Secrets and Watchtower auto-updates.

AI Agents That Pay for Compute: The x402 Payment Protocol Revolution

Wallet Guy — Wed, 16 Sep 2026 11:48:04 +0000

AI Agents That Pay for Compute: The x402 Payment Protocol Revolution

AI agents will need to pay for compute, data, and API calls — and the infrastructure to make that happen exists today. The x402 HTTP payment protocol, combined with autonomous wallet infrastructure, closes the loop between agents that consume resources and the economic systems that price those resources. This isn't a roadmap item. It's running code you can deploy this afternoon.

The Problem with Agent Economics Today

Here's what happens right now when an AI agent needs to call a paid API: a human set up a credit card, got an API key, hardcoded it into an environment variable, and prayed the billing doesn't explode. The agent itself has no economic agency. It's a passenger. Someone else handles the money.

That model breaks down fast when you have hundreds of agents, or agents that need to make micropayment decisions at runtime, or agents that operate across different contexts with different budget constraints. The human-in-the-loop for every payment isn't a feature — it's a scaling ceiling.

The vision of autonomous agents participating in economic activity requires wallets those agents can actually use. Not custodied accounts where a human controls all the keys. Wallet infrastructure designed from the ground up for programmatic access, with safety rails that let humans stay in control without becoming bottlenecks for every transaction.

What x402 Actually Is

The HTTP 402 status code has existed since 1991. It was reserved for "Payment Required." For decades, nothing used it. Then the rise of stablecoins and crypto payment networks made it practical: a server can now return a 402 response with machine-readable payment instructions, a client pays, and the server retries the request with proof of payment. The whole thing happens in one HTTP round-trip.

For AI agents, this is significant. An agent making an API call doesn't need to know in advance whether that call costs money. It makes the request. If it gets a 402 back, it pays and retries. No human involvement. No pre-registration. No API key management. The payment is the authentication.

WAIaaS supports the x402 HTTP payment protocol natively — AI agents can pay for API calls automatically, with the economic logic built into the wallet layer rather than the agent itself.

The Wallet Infrastructure Agents Actually Need

WAIaaS is an open-source, self-hosted Wallet-as-a-Service designed specifically for AI agents. The design separates three roles that are often conflated:

The agent gets a session token and can transact within defined limits — this is sessionAuth via JWT HS256
The administrator controls wallet creation, policies, and session management — this is masterAuth via Argon2id
The fund owner can approve high-value transactions or trigger a kill switch — this is ownerAuth via SIWS/SIWE signatures

An agent never touches the master password. It can't create new wallets or modify its own spending limits. It operates within a policy cage that a human configured, but it can act autonomously within that cage — including making x402 payments.

Policy Cages: How You Stay in Control

The policy engine is what makes autonomous agent wallets viable rather than terrifying. WAIaaS implements 21 policy types with 4 security tiers.

The tiers work like this: INSTANT (execute immediately, no notification), NOTIFY (execute immediately, send notification), DELAY (queue for a configured delay, then execute — cancellable by the owner), and APPROVAL (require human approval before anything happens). Every transaction routes through this system.

For x402 payments specifically, there's a dedicated policy type:

X402_ALLOWED_DOMAINS    — x402 payment domain whitelist

This means an agent can only make x402 payments to domains you've explicitly allowed. It can't start paying arbitrary endpoints on the internet. Combined with spending limits, you get an agent that can autonomously pay for API calls on a whitelist of trusted providers, up to a daily budget, with notifications if it hits certain thresholds.

Here's what a spending limit policy looks like in practice:

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 pays immediately. Between $100 and $500? Pays immediately, you get notified. Between $500 and $2000? Goes into a 15-minute delay queue you can cancel. Over $2000? Requires your explicit approval. The agent doesn't need to know any of this logic — it just submits transactions and the pipeline handles the rest.

The x402Fetch Method

From the TypeScript SDK, the interface for x402 payments is a single method that wraps standard fetch behavior:

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

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

The SDK provides an x402Fetch() method — HTTP fetch with automatic 402 payment handling. The agent calls an endpoint, gets a 402 if there's a payment required, the SDK handles the payment using the wallet, and the request completes. From the agent code's perspective, it's just an HTTP call.

This is the right level of abstraction. The agent's reasoning layer shouldn't be thinking about payment channels and transaction confirmations. It should be thinking about the task. The wallet infrastructure handles the economic plumbing.

Not Just Payments: A Full Financial Layer

x402 is one slice of what agent wallets need to support. The broader picture includes:

Token management — Agents need to know their balance, receive funds, and send tokens. The SDK's getBalance(), getAssets(), and sendToken() methods cover this. Incoming transaction monitoring with real-time notifications for deposits means agents can react when they receive funds.

DeFi access — WAIaaS integrates 15 DeFi protocol providers, including Jupiter swap on Solana, Uniswap via 0x, Aave v3 for lending, Hyperliquid for perpetual futures, Lido and Jito for liquid staking, and cross-chain bridging via LI.FI and Across. An agent managing a portfolio can lend idle funds to Aave, take a leveraged position on Hyperliquid, and bridge assets across chains — all through the same wallet interface.

NFT operations — ERC-721/ERC-1155 on EVM and Metaplex on Solana with metadata caching. Agents can hold and transfer NFTs.

Account abstraction — ERC-4337 support means gasless transactions and smart account capabilities for EVM chains.

Simulation before execution — Before any transaction commits, agents can dry-run it:

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

This is particularly valuable for agents operating on unfamiliar contracts or in high-stakes scenarios — simulate first, execute if clean.

MCP: Connecting Agents to Wallets Without Custom Code

For agent frameworks that support the Model Context Protocol, WAIaaS exposes 45 MCP tools covering wallet operations, transactions, DeFi, NFTs, and x402. The x402-fetch tool is explicitly included.

Setup is a CLI command:

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

The resulting Claude Desktop configuration points an MCP server at your running WAIaaS daemon. Claude (or any MCP-compatible agent) can then check balances, send tokens, execute swaps, and make x402 payments through natural language requests. The agent doesn't need to understand the payment protocol internals — it just calls the tool.

7-Stage Transaction Pipeline

Every transaction — including x402 payments — runs through a 7-stage pipeline: validate, auth, policy, wait, execute, confirm. The policy stage is where spending limits and x402 domain whitelists are enforced. The wait stage is where DELAY-tier transactions sit until the timer expires or the owner cancels. The confirm stage handles on-chain confirmation and receipt.

This means the safety model isn't bolted on — it's structural. You can't route around it from the agent side because the agent never touches the execution layer directly.

Getting Started in 10 Minutes

Here's the minimal path to an agent with x402 payment capability:

Step 1: Start the daemon

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

docker exec waiaas cat /data/recovery.key

Step 2: Create a wallet and session

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

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

Step 3: Configure spending limits and x402 domain whitelist (create policies as shown above)

Step 4: Fund the wallet and give the session token to your agent

Step 5: Agent checks balance and starts operating

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

The agent now has an independently funded wallet, a session token scoped to what you've allowed, and the ability to make x402 payments to domains on your whitelist — without ever touching your master password or requiring your approval for transactions below your configured threshold.

The Onchain Reputation Layer

One piece of this ecosystem worth noting: WAIaaS includes ERC-8004 support — onchain agent reputation and validation. The REPUTATION_THRESHOLD policy type lets you enforce that agents your wallet interacts with meet a minimum reputation score. As agent-to-agent economic activity grows, reputation becomes a meaningful signal. An agent paying another agent for compute capacity will eventually want to verify that the recipient isn't a scam. Onchain reputation provides that.

The Bigger Picture

The infrastructure layer for the agent economy is being built right now. x402 provides the payment protocol. Stablecoins provide the rails. Policy engines provide the safety constraints that make autonomous agent wallets viable for humans to deploy. The MCP ecosystem connects this infrastructure to the agent frameworks people are actually building with.

The question isn't whether AI agents will participate in economic activity. They already do, imperfectly, through human-managed API keys and credit cards. The question is whether that economic participation will be autonomous, auditable, and controllable — or chaotic and opaque.

Wallet infrastructure designed for agents, with policy engines that encode human intent and safety rails that don't require humans to approve every micropayment, is what makes the difference.

What's Next

The full documentation, including the OpenAPI 3.0 spec (available at /reference when you're running locally), covers all 39 REST API route modules and the complete policy configuration options. The monorepo includes a TypeScript SDK with 40+ methods and a Python SDK for teams working in that ecosystem.

Explore the codebase and deploy your own instance at https://github.com/waiaas/WAIaaS, or learn more about the project at https://waiaas.ai.