Forem: Wallet Guy

Python SDK for AI Agents: Async Wallet Control with Zero Dependencies

Wallet Guy — Wed, 15 Apr 2026 08:09:35 +0000

Your AI agents can browse the web, write code, and manage files—but can they control a crypto wallet? Most AI agent frameworks stop at the edge of financial transactions, leaving a critical gap for agents that need to interact with DeFi protocols, pay for API calls with crypto, or manage digital assets autonomously.

Why Wallet Integration Matters for AI Agents

AI agents are becoming increasingly autonomous, but they hit a wall when they need to handle money. Whether it's an agent that needs to:

Pay for premium API calls using crypto micropayments
Execute DeFi strategies based on market conditions
Manage NFT portfolios automatically
Bridge assets between different blockchain networks

The missing piece has always been secure, programmable wallet access. Traditional wallet solutions require manual approval for every transaction, breaking the autonomous flow that makes AI agents powerful.

Python SDK: Zero Dependencies, Maximum Control

WAIaaS provides a Python SDK (waiaas) with async/await support and zero external dependencies. This means your AI agents can control wallets without bloating your dependency tree or introducing security vulnerabilities from third-party packages.

The Python SDK gives your agents access to 18 networks across 2 chain types (solana, evm), with built-in support for 15 DeFi protocol providers integrated including Jupiter swap, Lido staking, Hyperliquid perpetual futures, and Polymarket prediction markets.

Getting Started with the Python SDK

Here's how to give your AI agent wallet superpowers:

pip install waiaas

First, you'll need a running WAIaaS daemon. The fastest way is with Docker:

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

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

Now your agent can interact with the wallet:

from waiaas import WAIaaSClient

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

Real-World Agent Integration Example

Let's build an agent that can autonomously manage a DeFi portfolio. This example shows how an AI agent can check balances, execute swaps, and monitor positions:

from waiaas import WAIaaSClient
import asyncio

class DeFiAgent:
    def __init__(self, session_token):
        self.client = WAIaaSClient("http://localhost:3100", session_token)

    async def rebalance_portfolio(self, target_usdc_ratio=0.5):
        """Rebalance portfolio to maintain target USDC ratio"""

        # Check current positions
        balance = await self.client.get_balance()
        assets = await self.client.get_assets()

        print(f"Current balance: {balance.balance} {balance.symbol}")

        # Calculate if rebalancing is needed
        total_value_usd = float(balance.balance) * balance.price_usd
        usdc_balance = next((a for a in assets if a.symbol == "USDC"), None)
        current_usdc_ratio = (usdc_balance.balance_usd / total_value_usd) if usdc_balance else 0

        if abs(current_usdc_ratio - target_usdc_ratio) > 0.05:  # 5% threshold
            # Execute rebalancing trade
            if current_usdc_ratio < target_usdc_ratio:
                # Need more USDC - sell SOL for USDC
                amount_to_swap = (target_usdc_ratio - current_usdc_ratio) * float(balance.balance)
                await self.swap_tokens("SOL", "USDC", str(amount_to_swap))
            else:
                # Need less USDC - buy SOL with USDC  
                amount_to_swap = (current_usdc_ratio - target_usdc_ratio) * usdc_balance.balance_usd
                await self.swap_tokens("USDC", "SOL", str(amount_to_swap))

    async def swap_tokens(self, from_token, to_token, amount):
        """Execute token swap via Jupiter"""
        try:
            result = await self.client.execute_action(
                "jupiter-swap", 
                "swap",
                {
                    "inputMint": self.get_token_mint(from_token),
                    "outputMint": self.get_token_mint(to_token), 
                    "amount": amount
                }
            )
            print(f"Swap executed: {result.id}")
            return result
        except Exception as e:
            print(f"Swap failed: {e}")
            return None

    async def monitor_positions(self):
        """Monitor DeFi positions across protocols"""
        positions = await self.client.get_defi_positions()

        for position in positions:
            if position.health_factor and position.health_factor < 1.2:
                print(f"WARNING: Low health factor on {position.protocol}: {position.health_factor}")
                # Agent could automatically add collateral or reduce leverage here

    def get_token_mint(self, symbol):
        """Get token mint address for common tokens"""
        mints = {
            "SOL": "So11111111111111111111111111111111111111112",
            "USDC": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v"
        }
        return mints.get(symbol)

# Usage
async def main():
    agent = DeFiAgent("wai_sess_your_token_here")

    # Run autonomous rebalancing
    await agent.rebalance_portfolio(target_usdc_ratio=0.6)

    # Monitor positions for risk
    await agent.monitor_positions()

if __name__ == "__main__":
    asyncio.run(main())

Security Through Policy Engine

The key to safe autonomous operation is WAIaaS's policy engine with 21 policy types and 4 security tiers: INSTANT, NOTIFY, DELAY, APPROVAL. You can configure policies that allow your agent to operate within safe boundaries:

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

This creates a 4-tier security system where small transactions execute instantly, medium amounts trigger notifications, larger amounts have a time delay for review, and the largest amounts require explicit human approval via WalletConnect integration for owner approval of agent transactions.

Advanced Features for AI Agents

x402 HTTP Payment Protocol

Your agents can automatically pay for API calls using the x402 HTTP payment protocol support:

# Agent pays for premium API access automatically
response = await client.x402_fetch("https://api.premium-service.com/data")

Multi-Chain Operation

The Python SDK supports 18 networks across Ethereum, Solana, and other chains. Your agent can bridge assets automatically:

# Bridge from Ethereum to Solana via LI.FI
await client.execute_action("lifi", "bridge", {
    "fromChain": "ethereum",
    "toChain": "solana", 
    "amount": "100.0",
    "token": "USDC"
})

NFT Operations

Agents can manage NFT portfolios with NFT support for EVM (ERC-721/ERC-1155) and Solana (Metaplex) with metadata caching:

# List agent's NFT collection
nfts = await client.list_nfts()

# Transfer NFT to another address  
await client.transfer_nft({
    "to": "recipient-address",
    "tokenId": "123",
    "contractAddress": "0x..."
})

Quick Start: Agent-Ready Wallet in 5 Minutes

Start WAIaaS daemon:

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

Get the master password:

docker exec waiaas cat /data/recovery.key

Create wallet and session (using CLI for convenience):

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

Install Python SDK:

pip install waiaas

Test agent wallet access:

from waiaas import WAIaaSClient

async with WAIaaSClient("http://localhost:3100", "your_session_token") as client:
    balance = await client.get_balance()
    print(f"Agent wallet ready! Balance: {balance.balance} {balance.symbol}")

MCP Integration for Claude and Other AI Frameworks

If you're building with Claude Desktop, LangChain, or other MCP-compatible frameworks, WAIaaS provides 45 MCP tools for AI agent integration. The MCP server can be configured alongside the Python SDK for maximum flexibility:

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

This gives your Claude agent direct access to wallet operations through natural language commands, while your Python agents can use the SDK for programmatic control.

The Python SDK's async/await design makes it perfect for building reactive agents that respond to market conditions, user requests, or scheduled tasks without blocking execution. Combined with the policy engine's safety guarantees, you can deploy autonomous financial agents with confidence.

Ready to give your AI agents financial superpowers? Check out the full documentation and examples on GitHub or explore more advanced integrations at waiaas.ai.

What's next? Try integrating WAIaaS with your existing AI agent framework, set up some basic spending policies, and watch your agents start interacting with DeFi protocols autonomously. The combination of zero-dependency architecture and comprehensive blockchain support makes it the fastest path from idea to autonomous financial agent.

Production Docker Setup: Healthcheck, Auto-Updates, and Non-Root Security

Wallet Guy — Tue, 14 Apr 2026 14:56:37 +0000

Setting up production Docker infrastructure for AI agents requires careful attention to security, monitoring, and maintenance. WAIaaS provides a hardened Docker deployment with healthchecks, automatic updates, and non-root containers to keep your wallet infrastructure running reliably in production environments.

Why Production Docker Setup Matters

When AI agents handle real cryptocurrency transactions, infrastructure reliability becomes critical. A crashed container means stuck transactions, missed trading opportunities, or worse — agents that can't respond to market conditions. Production setups need automated health monitoring, security isolation, and hands-off maintenance to minimize operational overhead while maximizing uptime.

WAIaaS Production-Ready Docker Features

WAIaaS includes several production-hardened Docker features out of the box:

Built-in Healthcheck

The Docker container includes a native healthcheck that monitors the API endpoint:

healthcheck:
  test: ["CMD", "curl", "-f", "http://localhost:3100/health"]
  interval: 30s
  timeout: 5s
  start_period: 10s
  retries: 3

This configuration checks the /health endpoint every 30 seconds. If three consecutive checks fail, Docker marks the container as unhealthy, enabling orchestration systems to restart or replace it automatically.

Non-Root Security

The WAIaaS Docker image runs as UID 1001, not root:

# From the Dockerfile
USER 1001

This follows security best practices by limiting container privileges. Even if an attacker compromises the application, they can't escalate to root or modify system files.

Auto-Provisioning for Unattended Deployment

For production deployments where manual password entry isn't practical, enable 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/minhoyoo-iotrust/waiaas:latest

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

The auto-provision feature generates a cryptographically secure master password and saves it to /data/recovery.key for later retrieval.

Docker Compose Production Configuration

For production deployments, use the complete Docker Compose setup with monitoring and restart policies:

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

  # Watchtower for automatic updates
  watchtower:
    image: containrrr/watchtower
    container_name: waiaas-watchtower
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - WATCHTOWER_POLL_INTERVAL=3600
      - WATCHTOWER_CLEANUP=true
      - WATCHTOWER_INCLUDE_STOPPED=true
    restart: unless-stopped

volumes:
  waiaas-data:
    driver: local

This configuration includes Watchtower for automatic container updates, ensuring your wallet infrastructure stays current with security patches and feature updates.

Secrets Management for Production

For production environments with sensitive configuration, use Docker Secrets to avoid exposing credentials in environment variables:

# Create secret files
mkdir -p secrets
echo "your-secure-master-password" > secrets/master_password.txt
echo "your-rpc-endpoint" > secrets/solana_rpc.txt
chmod 600 secrets/*.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) mounts secret files as read-only volumes, keeping sensitive data out of process environments where it might leak in logs or crash dumps.

Monitoring and Logging

Set up comprehensive logging for production troubleshooting:

# Follow logs from all services
docker compose logs -f

# Check container health status
docker ps --format "table {{.Names}}\t{{.Status}}"

# Monitor resource usage
docker stats waiaas-daemon

For structured logging, configure the log level via environment variable:

environment:
  - WAIAAS_DAEMON_LOG_LEVEL=info  # trace/debug/info/warn/error

Network Security Configuration

Bind the service to localhost only for security:

ports:
  - "127.0.0.1:3100:3100"  # Only accessible from localhost

If you need external access, use a reverse proxy like nginx with TLS termination rather than exposing the container port directly. This provides an additional security layer and enables features like rate limiting and authentication at the proxy level.

Backup and Data Persistence

The named volume waiaas-data persists wallet keys, transaction history, and configuration across container restarts:

# Create backup of wallet data
docker run --rm -v waiaas-data:/source -v $(pwd):/backup \
  ubuntu tar czf /backup/waiaas-backup-$(date +%Y%m%d).tar.gz -C /source .

# Restore from backup
docker run --rm -v waiaas-data:/target -v $(pwd):/backup \
  ubuntu tar xzf /backup/waiaas-backup-20240314.tar.gz -C /target

Resource Limits and Performance

Set resource constraints to prevent runaway resource usage:

services:
  daemon:
    # ... other config
    deploy:
      resources:
        limits:
          memory: 512M
          cpus: '1.0'
        reservations:
          memory: 256M
          cpus: '0.5'

WAIaaS is designed to be lightweight, typically using under 100MB RAM for normal operations.

Quick Production Deployment

Here's a complete 5-step production setup:

Clone and prepare configuration:

   git clone https://github.com/minhoyoo-iotrust/WAIaaS.git
   cd WAIaaS
   cp .env.example .env

Configure secrets (optional but recommended):

   mkdir secrets
   echo "$(openssl rand -base64 32)" > secrets/master_password.txt
   chmod 600 secrets/master_password.txt

Deploy with auto-provisioning:

   docker compose up -d

Retrieve credentials:

   docker exec waiaas-daemon cat /data/recovery.key

Verify deployment:

   curl http://127.0.0.1:3100/health
   docker compose logs daemon

Maintenance and Updates

The Watchtower integration automatically pulls new images and restarts containers when updates are available. To manually update:

docker compose pull    # Pull latest images
docker compose up -d   # Restart with new images

WAIaaS uses semantic versioning. Patch updates (1.0.1 → 1.0.2) are automatically applied via Watchtower. For major version updates, review the changelog before upgrading.

What's Next

With your production Docker infrastructure running, you're ready to create wallets and deploy AI agents with confidence. The hardened container setup provides the reliability foundation needed for autonomous trading systems and DeFi protocols.

Check out the WAIaaS GitHub repository for the latest Docker configurations and visit waiaas.ai for comprehensive deployment guides and production best practices.

Building Trustworthy AI Agents: ERC-8004 Onchain Reputation System

Wallet Guy — Tue, 14 Apr 2026 08:08:15 +0000

AI agents need reputation systems to operate safely in economic environments, but traditional web2 ratings are siloed and gameable. ERC-8004 brings onchain reputation to AI agents, creating a trustless system where autonomous agents can build and verify their track record across protocols. WAIaaS implements the complete ERC-8004 specification, letting you deploy agents with verifiable onchain reputation from day one.

Why Onchain Reputation Matters for AI Agents

As AI agents become economic actors — trading tokens, providing services, managing DeFi positions — we need systems to evaluate their trustworthiness. A trading agent with a proven track record should command higher trust than a newly deployed agent with no history.

Traditional reputation systems fail in multi-agent environments. Centralized ratings are platform-locked. An agent's stellar performance on one protocol doesn't transfer to another. Worse, these systems are vulnerable to manipulation through fake reviews or wash trading.

ERC-8004 solves this by moving reputation onchain. When an agent completes actions, other protocols can attest to their performance directly on the blockchain. This creates a portable, tamper-proof reputation score that follows the agent across all protocols and applications.

ERC-8004: Trustless Agents Standard

ERC-8004 defines how AI agents register, accumulate reputation, and prove their identity onchain. The standard includes three core components:

Agent Registration: Each agent gets a unique onchain identity tied to their wallet address. This prevents agents from abandoning bad reputations and starting fresh with new addresses.

Attestation System: Protocols can submit positive or negative attestations about an agent's performance. These attestations are weighted based on the attester's own reputation, preventing spam attacks.

Validation Queries: Any protocol can query an agent's reputation score, validation status, and attestation history before allowing the agent to participate.

WAIaaS provides 15 DeFi protocol providers integrated with this reputation system. When your agent trades on Jupiter, lends on Aave, or provides liquidity on Kamino, these actions can generate reputation attestations automatically.

How WAIaaS Implements ERC-8004

WAIaaS includes a complete ERC-8004 provider that handles agent registration, attestation management, and reputation queries. Here's how to register an agent and start building onchain reputation:

# Register your agent onchain
curl -X POST http://127.0.0.1:3100/v1/actions/erc8004/register \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer wai_sess_<token>" \
  -d '{
    "agentName": "trading-bot-v2",
    "agentType": "TRADING",
    "metadata": {
      "description": "Automated arbitrage trader",
      "version": "2.1.0",
      "strategies": ["arbitrage", "market-making"]
    }
  }'

The registration creates an onchain record linking your agent's wallet address to its identity and capabilities. Other protocols can now track this agent's performance and submit attestations.

To check an agent's current reputation:

# Get agent reputation data
curl http://127.0.0.1:3100/v1/actions/erc8004/reputation/<agent-address> \
  -H "Authorization: Bearer wai_sess_<token>"

This returns the agent's reputation score, validation status, total attestations, and performance metrics across different categories.

Policy Integration: Reputation-Based Access Control

WAIaaS policy engine includes REPUTATION_THRESHOLD policies that restrict actions based on onchain reputation scores. This lets you create agent hierarchies where higher-reputation agents get more privileges:

# Create reputation-based policy
curl -X POST http://127.0.0.1:3100/v1/policies \
  -H "Content-Type: application/json" \
  -H "X-Master-Password: my-secret-password" \
  -d '{
    "walletId": "<wallet-uuid>",
    "type": "REPUTATION_THRESHOLD",
    "rules": {
      "minimum_score": 750,
      "required_attestations": 10,
      "max_negative_ratio": 0.1
    }
  }'

This policy blocks actions unless the agent has a reputation score above 750, at least 10 attestations, and negative attestations below 10% of total attestations. You can use different thresholds for different action types — requiring higher reputation for large trades but allowing smaller operations for newer agents.

Building Multi-Agent Systems with Reputation

ERC-8004's power emerges when multiple agents interact. Here's a pattern for creating agent hierarchies:

Supervisor Agent: High-reputation agent that coordinates strategy and risk management. Has broad permissions and can approve actions by subordinate agents.

Specialist Agents: Medium-reputation agents focused on specific tasks (arbitrage, yield farming, NFT trading). Can execute actions within their specialty but require supervisor approval for cross-domain operations.

Scout Agents: Low-reputation agents that gather market data and identify opportunities. Cannot execute trades but can submit recommendations to specialist agents.

The MCP integration makes this pattern natural. Each agent gets its own MCP server instance with different reputation thresholds and policy configurations:

{
  "mcpServers": {
    "supervisor-agent": {
      "command": "npx",
      "args": ["-y", "@waiaas/mcp"],
      "env": {
        "WAIAAS_AGENT_ID": "019c47d6-51ef-7f43-a76b-d50e875d95f4",
        "WAIAAS_AGENT_NAME": "supervisor"
      }
    },
    "arbitrage-specialist": {
      "command": "npx",
      "args": ["-y", "@waiaas/mcp"],
      "env": {
        "WAIAAS_AGENT_ID": "019c4cd2-86e8-758f-a61e-9c560307c788",
        "WAIAAS_AGENT_NAME": "arbitrage-bot"
      }
    }
  }
}

The supervisor can query subordinate agents' reputation and performance before delegating tasks or approving their proposed actions.

Real-Time Reputation Monitoring

WAIaaS provides MCP tools for agents to monitor their own reputation and respond to changes:

// Agent checks its own reputation before major actions
const reputation = await client.executeAction('erc8004', 'get-reputation', {
  agentAddress: await client.getAddress()
});

if (reputation.score < 800) {
  console.log('Reputation below threshold, reducing position sizes');
  maxTradeSize = maxTradeSize * 0.5;
}

// Check if recent attestations indicate performance issues
const recentNegative = reputation.attestations
  .filter(a => a.timestamp > Date.now() - 86400000) // Last 24h
  .filter(a => a.score < 0);

if (recentNegative.length > 3) {
  console.log('Multiple negative attestations, entering conservative mode');
  pauseHighRiskStrategies();
}

This self-monitoring creates a feedback loop where agents automatically adjust their behavior based on reputation changes, reducing risk when their standing drops.

Cross-Protocol Reputation Portability

Unlike platform-specific ratings, ERC-8004 reputation follows agents across all protocols. An agent that performs well on Aave lending carries that reputation to Jupiter trading or Polymarket prediction markets.

This portability accelerates agent adoption. New protocols can bootstrap trust by accepting agents with strong reputation from other protocols, while agents can leverage their track record to access new opportunities immediately.

WAIaaS tracks attestations across all 15 integrated DeFi protocols, creating a unified reputation profile that reflects the agent's performance across lending, trading, staking, and prediction markets.

Quick Start: Deploy a Reputation-Enabled Agent

Here's how to launch an AI agent with onchain reputation in under 10 minutes:

Deploy WAIaaS: docker run -d -p 3100:3100 ghcr.io/minhoyoo-iotrust/waiaas:latest
Create agent wallet: waiaas wallet create --chain ethereum --name reputation-agent
Register agent onchain: Use the ERC-8004 provider to register your agent with its identity and capabilities
Configure reputation policies: Set minimum reputation thresholds for different action categories
Start building reputation: Execute small, low-risk actions to begin accumulating positive attestations

Your agent now has verifiable onchain identity and can begin building reputation across protocols. As it performs successful actions, other protocols will attest to its performance, gradually increasing its trustworthiness and access to higher-value opportunities.

The key insight is starting with conservative actions to build initial reputation, then expanding capabilities as trust increases. This mirrors how humans build professional reputations — proving competence in small tasks before being trusted with larger responsibilities.

Looking ahead, onchain reputation systems like ERC-8004 will become critical infrastructure as AI agents become more autonomous and economically active. The agents that establish strong reputations early will have significant advantages in accessing protocols, securing favorable terms, and participating in high-value opportunities.

Ready to build trustworthy AI agents with onchain reputation? Start with the WAIaaS repository or explore more at waiaas.ai.

UserOp Build and Sign: ERC-4337 Account Abstraction API for AI Agents

Wallet Guy — Mon, 13 Apr 2026 08:26:01 +0000

ERC-4337 Account Abstraction transforms how DeFi applications handle transactions, but building and signing UserOps manually is complex and error-prone. WAIaaS provides a simple REST API that abstracts the entire UserOp lifecycle — from building to signing to submission — letting your AI agents and DeFi applications focus on strategy rather than ERC-4337 implementation details.

Why Account Abstraction Matters for DeFi

Traditional externally owned accounts (EOAs) create friction in DeFi applications. Every transaction requires gas in ETH, users must manage private keys, and batch operations need complex coordination. ERC-4337 Account Abstraction solves these problems by introducing smart contract wallets that can:

Execute gasless transactions (gas sponsored by paymasters)
Batch multiple operations into a single UserOp
Implement custom validation logic and spending policies
Support social recovery and multi-signature schemes

However, ERC-4337's complexity has limited adoption. Building UserOps requires understanding the spec's intricate details, managing multiple contracts (EntryPoint, Account Factory, Paymaster), and handling gas estimation across different networks. WAIaaS eliminates this complexity with a unified API that works across all EVM chains.

The WAIaaS UserOp API

WAIaaS provides three endpoints that handle the complete UserOp lifecycle:

1. Build UserOp

The /v1/userop/build endpoint constructs a UserOperation from your transaction intent:

curl -X POST http://127.0.0.1:3100/v1/userop/build \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer wai_sess_<token>" \
  -d '{
    "transactions": [
      {
        "type": "ContractCall",
        "to": "0xA0b86a33E6441d78abf57Fe4e5dA14A6e7F8b57C",
        "data": "0xa9059cbb000000000000000000000000742b35Cc6Cf16CCBb0c5db86c5E5D12b06d67f2E0000000000000000000000000000000000000000000000000de0b6b3a7640000"
      }
    ],
    "gasOptions": {
      "maxFeePerGas": "20000000000",
      "maxPriorityFeePerGas": "1000000000"
    }
  }'

The API automatically:

Estimates gas limits using simulation
Sets nonce from the smart account state
Configures paymaster data if available
Validates the UserOp structure

2. Sign UserOp

The /v1/userop/sign endpoint signs the UserOperation hash:

curl -X POST http://127.0.0.1:3100/v1/userop/sign \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer wai_sess_<token>" \
  -d '{
    "userOp": {
      "sender": "0x1234...",
      "nonce": "0x1",
      "initCode": "0x",
      "callData": "0xa9059cbb...",
      "callGasLimit": "0x5208",
      "verificationGasLimit": "0x5208",
      "preVerificationGas": "0x5208",
      "maxFeePerGas": "0x4a817c800",
      "maxPriorityFeePerGas": "0x3b9aca00",
      "paymasterAndData": "0x",
      "signature": "0x"
    }
  }'

WAIaaS handles signature generation based on your smart account's validation scheme — whether it's ECDSA, multi-sig, or custom validation logic.

3. Combined Build and Sign

For convenience, you can build and sign in a single request:

curl -X POST http://127.0.0.1:3100/v1/userop/build-and-sign \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer wai_sess_<token>" \
  -d '{
    "transactions": [
      {
        "type": "TokenTransfer",
        "token": "0xA0b86a33E6441d78abf57Fe4e5dA14A6e7F8b57C",
        "to": "0x742b35Cc6Cf16CCBb0c5db86c5E5D12b06d67f2E",
        "amount": "1000000000000000000"
      }
    ],
    "submitToMempool": true
  }'

Setting submitToMempool: true automatically submits the signed UserOp to the bundler network.

Batch Operations Made Simple

One of ERC-4337's key benefits is batching multiple operations into a single UserOp. WAIaaS makes this trivial:

curl -X POST http://127.0.0.1:3100/v1/userop/build-and-sign \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer wai_sess_<token>" \
  -d '{
    "transactions": [
      {
        "type": "Approve",
        "token": "0xA0b86a33E6441d78abf57Fe4e5dA14A6e7F8b57C",
        "spender": "0x7a250d5630B4cF539739dF2C5dAcb4c659F2488D",
        "amount": "1000000000000000000000000"
      },
      {
        "type": "ContractCall",
        "to": "0x7a250d5630B4cF539739dF2C5dAcb4c659F2488D",
        "data": "0x791ac947..."
      }
    ],
    "submitToMempool": true
  }'

This example batches a token approval with a Uniswap swap, executing both operations atomically in a single UserOp.

Integration with WAIaaS Policy Engine

UserOps flow through WAIaaS's 7-stage transaction pipeline, including policy validation. You can configure ERC-4337-specific policies:

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

The policy engine evaluates UserOps just like regular transactions, enabling sophisticated risk management for smart contract wallets.

Real-World DeFi Example: Automated Yield Strategy

Here's how a yield farming bot might use the UserOp API to execute a complex strategy:

# Step 1: Build a multi-step yield strategy UserOp
curl -X POST http://127.0.0.1:3100/v1/userop/build-and-sign \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer wai_sess_<token>" \
  -d '{
    "transactions": [
      {
        "type": "Approve",
        "token": "0xA0b86a33E6441d78abf57Fe4e5dA14A6e7F8b57C",
        "spender": "0x7d2768dE32b0b80b7a3454c06BdAc94A69DDc7A9",
        "amount": "1000000000"
      },
      {
        "type": "ContractCall",
        "to": "0x7d2768dE32b0b80b7a3454c06BdAc94A69DDc7A9",
        "data": "0xe8eda9df000000000000000000000000a0b86a33e6441d78abf57fe4e5da14a6e7f8b57c000000000000000000000000000000000000000000000000000000003b9aca000000000000000000000000001234567890123456789012345678901234567890000000000000000000000000000000000000000000000000000000000000000000"
      }
    ],
    "submitToMempool": true,
    "gasOptions": {
      "maxFeePerGas": "30000000000",
      "maxPriorityFeePerGas": "2000000000"
    }
  }'

This UserOp approves USDC for Aave and supplies it to earn yield, all in a single atomic operation.

Quick Start with ERC-4337

Install WAIaaS CLI:

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

Create an EVM wallet:

   curl -X POST http://127.0.0.1:3100/v1/wallets \
     -H "Content-Type: application/json" \
     -H "X-Master-Password: <password>" \
     -d '{"name": "aa-wallet", "chain": "evm", "environment": "mainnet"}'

Create a session for your application:

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

Test UserOp building:

   curl -X POST http://127.0.0.1:3100/v1/userop/build \
     -H "Authorization: Bearer <session-token>" \
     -d '{"transactions": [{"type": "Transfer", "to": "0x...", "amount": "0.01"}]}'

Check the interactive API docs: Open http://127.0.0.1:3100/reference to explore all UserOp endpoints.

The WAIaaS UserOp API eliminates the complexity of ERC-4337 Account Abstraction, letting you focus on building innovative DeFi applications rather than wrestling with UserOperation construction and signing. With support for batching, policy enforcement, and automatic gas estimation, it's the simplest way to add smart contract wallet capabilities to your AI agents and DeFi protocols.

Ready to simplify your ERC-4337 integration? Check out the full documentation at GitHub and start building with smart contract wallets at waiaas.ai.

API Key Security for AI Agents: Credential Management in Self-Hosted Wallets

Wallet Guy — Sun, 12 Apr 2026 14:03:50 +0000

API key security for AI agents becomes critical when those agents control cryptocurrency wallets — one leaked credential or compromised system could drain entire treasury balances. Unlike traditional API keys that might expose data or incur service charges, wallet credentials give direct access to irreversible financial transactions.

Why This Matters More Than Traditional API Security

Traditional API security focuses on rate limiting, token expiration, and access logging. But when AI agents hold wallet private keys, the stakes escalate dramatically. A compromised trading bot doesn't just leak your customer database — it can transfer your entire SOL balance to an attacker's address in seconds.

The challenge multiplies with autonomous agents. While a human developer might notice suspicious API activity, AI agents operate continuously, making thousands of micro-decisions without human oversight. Standard security practices like "rotate keys monthly" become meaningless when the key unlocks actual money.

The Three-Layer Security Model

WAIaaS addresses these risks through layered defense: session authentication controls what agents can access, policy engines enforce spending rules, and human approval channels provide final oversight for high-risk transactions.

Layer 1: Session-Based Authentication

Instead of giving AI agents direct wallet access, WAIaaS uses session tokens with limited scope and automatic expiration:

# Create a session for AI agent (masterAuth required)
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>"}'

Sessions use JWT HS256 tokens with configurable TTL, maximum renewals, and absolute lifetime limits. Even if an agent's session token leaks, the exposure window is bounded. The agent never sees the actual private key — only a time-limited session that can be revoked instantly.

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

const client = new WAIaaSClient({
  baseUrl: 'http://127.0.0.1:3100',
  sessionToken: process.env.WAIAAS_SESSION_TOKEN, // Limited-scope token, not private key
});

// Agent can check balance
const balance = await client.getBalance();

// But transactions require policy approval
const tx = await client.sendToken({
  to: 'recipient-address',
  amount: '0.1',
});

Layer 2: Default-Deny Policy Engine

WAIaaS implements 21 policy types across 4 security tiers (INSTANT, NOTIFY, DELAY, APPROVAL). The critical principle: transactions are denied unless explicitly allowed by policy configuration.

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

This spending policy creates a security gradient: small amounts execute instantly, medium amounts trigger notifications, larger amounts wait 15 minutes (allowing cancellation), and amounts above $1000 require explicit human approval.

The default-deny approach prevents the classic attack vector where agents interact with malicious contracts not anticipated during development. Without CONTRACT_WHITELIST and ALLOWED_TOKENS policies, the agent simply cannot execute those transactions:

# Whitelist specific tokens only
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"}
      ]
    }
  }'

Layer 3: Human Approval Channels

For high-value transactions exceeding policy thresholds, WAIaaS routes approval requests through 3 signing channels: push notifications, Telegram bots, and WalletConnect integration.

# Transaction exceeding limits gets queued for approval
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": "5.0"
  }'

# Returns: {"id": "tx-uuid", "status": "PENDING_APPROVAL"}

The human owner receives push notification with transaction details and can approve/deny through their preferred channel. This creates an air gap between the AI agent and high-value transactions while maintaining operational efficiency for routine activities.

Credential Isolation and Recovery

WAIaaS separates three distinct credential types with different privilege levels:

masterAuth (Argon2id): System administration — wallet creation, policy configuration, session management
sessionAuth (JWT HS256): AI agent operations — balance queries, small transactions, DeFi interactions
ownerAuth (SIWS/SIWE): Fund owner control — transaction approval, emergency kill switch

This separation means compromising one credential doesn't grant access to others. An agent's leaked session token cannot modify spending policies or create new wallets. A compromised master password cannot approve pending transactions — that requires cryptographic signatures from the fund owner.

# Different auth for different operations
# AI agent checks balance (sessionAuth)
curl http://127.0.0.1:3100/v1/wallet/balance \
  -H "Authorization: Bearer wai_sess_<token>"

# Human approves large transaction (ownerAuth)
curl -X POST http://127.0.0.1:3100/v1/transactions/<tx-id>/approve \
  -H "X-Owner-Signature: <ed25519-signature>" \
  -H "X-Owner-Message: <signed-message>"

Operational Security in Practice

The 7-stage transaction pipeline validates every request through multiple checkpoints before execution:

Validate — Schema validation, parameter checking
Auth — Session token verification, scope checking
Policy — Rule evaluation, tier assignment
Wait — Delay enforcement for DELAY-tier transactions
Execute — Blockchain transaction submission
Confirm — Transaction monitoring and finalization
Log — Audit trail recording

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

The dry-run capability lets agents validate transactions against current policies without submitting to the blockchain. This prevents failed transactions and helps agents adapt their behavior to policy constraints.

Self-Hosted Control

Since WAIaaS runs entirely self-hosted, credential security doesn't depend on third-party services. Your session tokens, master passwords, and private keys never leave your infrastructure:

services:
  daemon:
    image: ghcr.io/minhoyoo-iotrust/waiaas:latest
    ports:
      - "127.0.0.1:3100:3100"  # Localhost only by default
    volumes:
      - waiaas-data:/data      # Local encrypted storage
    environment:
      - WAIAAS_DATA_DIR=/data

The Docker deployment binds to localhost by default, preventing external network exposure. All sensitive data stays encrypted in local volumes under your direct control.

Quick Start: Secure Agent Setup

Deploy with auto-provisioning:

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

Retrieve auto-generated master password:

docker exec waiaas cat /data/recovery.key

Create wallet with spending limits:

waiaas quickset --mode testnet  # Creates wallet + policies + session

Connect AI agent with session token:

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

Test with small transaction to verify policy enforcement before production use.

Understanding these security layers helps you deploy AI agents with confidence, knowing that multiple failsafes protect against both technical vulnerabilities and operational mistakes.

Self-Hosting Wallet Infrastructure: Docker Deployment Guide for AI Agents provides detailed deployment security configurations, while Policy Engine Deep Dive: 4-Tier Security for AI Agent Transactions explores advanced policy patterns for different risk profiles.

What's Next

Start with testnet deployment to experiment with policy configurations before handling real funds. The WAIaaS documentation at https://waiaas.ai covers advanced topics like multi-signature integration and custom policy development. Explore the complete implementation on GitHub at https://github.com/minhoyoo-iotrust/WAIaaS to understand the security architecture in detail.

Beyond Transactions: How AI Agents Execute Offchain Actions

Wallet Guy — Sun, 12 Apr 2026 07:47:24 +0000

Your AI agents can analyze market data, generate trading strategies, and even write smart contracts. But when it comes to actually executing transactions, they hit a wall. Most agents are stuck in read-only mode, unable to interact with DeFi protocols or handle real money. WAIaaS changes this by giving AI agents secure wallet capabilities through a self-hosted API that integrates with popular frameworks like Claude MCP.

Why Offchain Actions Matter for AI Agents

Traditional blockchain interactions focus on transactions — moving tokens, calling smart contracts, minting NFTs. But real AI agent workflows require much more. Your agent might need to check DeFi positions across multiple protocols, pay for API calls automatically using crypto, or execute complex multi-step strategies that combine onchain and offchain operations.

The challenge isn't just about having a wallet. It's about giving agents the right level of access without compromising security. You need granular policies, multi-layered approval systems, and the ability to revoke access instantly if something goes wrong.

WAIaaS Offchain Action Framework

WAIaaS provides 45 MCP tools that extend far beyond basic transactions. These tools are organized into categories that mirror how AI agents actually work:

Wallet Operations: Balance checks, address resolution, and asset management across multiple chains. Your agent can query positions across 15 DeFi protocols and get a unified view.

Transaction Pipeline: Not just sending transactions, but simulating them first, checking policy compliance, and handling multi-step approvals. Every transaction goes through a 7-stage pipeline with built-in safety checks.

DeFi Integration: Direct protocol integration means agents can interact with Aave, Jupiter, Lido, and other protocols without writing custom smart contract code.

Cross-Chain Actions: Bridge assets automatically using LI.FI and Across protocols when the agent's strategy requires tokens on different chains.

Payment Automation: The x402 HTTP payment protocol lets agents pay for API calls using crypto, enabling truly autonomous operation.

Here's how an AI agent checks DeFi positions across all protocols:

curl http://127.0.0.1:3100/v1/defi/positions \
  -H "Authorization: Bearer wai_sess_eyJhbGciOiJIUzI1NiJ9..."

The response includes lending positions, staking rewards, and LP positions with USD values calculated automatically:

{
  "positions": [
    {
      "protocol": "aave-v3",
      "type": "lending",
      "asset": "USDC",
      "amount": "1500.00",
      "apy": "4.2%",
      "health_factor": "2.1"
    },
    {
      "protocol": "lido",
      "type": "staking",
      "asset": "stETH",
      "amount": "0.5",
      "rewards_earned": "0.002"
    }
  ]
}

Policy-Driven Security for Autonomous Agents

The biggest concern with AI agents handling money is security. WAIaaS addresses this with 21 policy types and 4 security tiers. Instead of giving agents unlimited access, you define exactly what they can do:

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

This policy creates a 4-tier system:

INSTANT: Transactions under $100 execute immediately
NOTIFY: $100-500 transactions execute with notifications
DELAY: $500-2000 transactions wait 15 minutes (cancellable)
APPROVAL: Anything over $2000 requires human approval

You can also restrict which tokens, contracts, and DeFi protocols the agent can access. The default-deny approach means agents are blocked from unexpected actions unless explicitly permitted.

MCP Integration: Plug and Play AI Wallets

Model Context Protocol (MCP) makes it trivial to give existing AI frameworks wallet capabilities. WAIaaS provides an MCP server with all 45 tools pre-configured:

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

This automatically registers WAIaaS with Claude Desktop. Your Claude agent immediately gains access to wallet operations:

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

Now Claude can perform complex blockchain operations through natural language:

User: "Check my DeFi positions and rebalance if my Aave health factor is below 1.5"

Claude: Uses get_defi_positions tool → sees health factor of 1.2 → uses action_provider tool to repay some debt → confirms with get_defi_positions again.

Advanced Use Cases: x402 and ERC-8004

WAIaaS enables AI agent patterns that aren't possible with traditional wallets. The x402 HTTP payment protocol lets agents pay for API services automatically:

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

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

// Agent pays for API call automatically when service returns HTTP 402
const response = await client.x402Fetch('https://api.market-data.ai/analysis', {
  method: 'POST',
  body: JSON.stringify({ symbol: 'BTC' }),
});

console.log('Paid for analysis:', await response.json());

The agent's wallet automatically handles the payment negotiation, making API services truly frictionless.

ERC-8004 integration provides onchain agent reputation. Your agents can prove their track record and gain access to higher-value operations based on historical performance:

curl http://127.0.0.1:3100/v1/erc8004/agent-info/<agent-address> \
  -H "Authorization: Bearer wai_sess_<token>"

Multi-Chain Agent Strategies

Real AI trading agents need to work across multiple chains. WAIaaS supports 18 networks across EVM and Solana, with automatic bridging when strategies require cross-chain execution.

Here's an agent executing a cross-chain arbitrage strategy:

# 1. Check prices on both chains
curl http://127.0.0.1:3100/v1/actions/jupiter-swap/quote \
  -H "Authorization: Bearer wai_sess_<token>" \
  -d '{"inputMint": "SOL", "outputMint": "USDC", "amount": "1"}'

curl http://127.0.0.1:3100/v1/actions/zerox-swap/quote \
  -H "Authorization: Bearer wai_sess_<token>" \
  -d '{"sellToken": "ETH", "buyToken": "USDC", "sellAmount": "0.6"}'

# 2. Bridge assets to optimal chain
curl -X POST http://127.0.0.1:3100/v1/actions/lifi/bridge \
  -H "Authorization: Bearer wai_sess_<token>" \
  -d '{
    "fromChain": "solana",
    "toChain": "ethereum",
    "fromToken": "USDC",
    "toToken": "USDC",
    "amount": "1000"
  }'

# 3. Execute optimal trade
curl -X POST http://127.0.0.1:3100/v1/actions/zerox-swap/swap \
  -H "Authorization: Bearer wai_sess_<token>" \
  -d '{"sellToken": "USDC", "buyToken": "ETH", "sellAmount": "1000"}'

The agent handles all the complexity — quote comparison, bridge execution, and final trades — while WAIaaS ensures each step complies with your security policies.

Quick Start: Give Your Agent a Wallet

Step 1: Install and initialize WAIaaS

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

Step 2: Create wallets and sessions

waiaas quickset --mode mainnet

Step 3: Set up MCP integration

waiaas mcp setup --all

Step 4: Configure policies

waiaas quickstart
# Follow prompts to set spending limits and token whitelist

Step 5: Test with Claude
Open Claude Desktop and ask: "What's my wallet balance?" Your agent now has full blockchain capabilities.

What's Next

WAIaaS transforms AI agents from observers to participants in the crypto economy. Your agents can now execute complex DeFi strategies, pay for services automatically, and operate with the security controls you need for production use.

Ready to give your AI agent a wallet? Check out the WAIaaS GitHub repository for full documentation and examples. Visit waiaas.ai to explore all capabilities and join the community building the future of AI-powered finance.

Keep Your AI Agent Solvent: Health Factor Monitoring for DeFi Lending

Wallet Guy — Sat, 11 Apr 2026 14:00:47 +0000

When DeFi lending protocols liquidate positions at 1.05x health factor, your AI trading bot can lose thousands in seconds. If you're building automated yield strategies or DeFi bots, you need real-time health factor monitoring across multiple protocols — but each one has different APIs, calculation methods, and liquidation thresholds.

Why Health Factor Monitoring Is Critical

In DeFi lending, your health factor is the difference between profit and liquidation. Aave liquidates at 1.0, Kamino at 1.1, and each protocol calculates it differently. Your AI agent might be managing positions across multiple protocols simultaneously — a profitable arbitrage strategy on one platform could trigger a liquidation cascade on another if you're not monitoring cross-protocol risk.

Manual monitoring doesn't scale. By the time you check each protocol's dashboard, volatile markets have already moved. You need programmatic access to health factors, collateral ratios, and liquidation thresholds — ideally through a single API that normalizes data across protocols.

Unified Health Factor Monitoring with WAIaaS

WAIaaS provides real-time DeFi position monitoring across 15 protocols through a single REST API. Your AI agent gets normalized health factor data from Aave V3, Kamino, Drift, and other major protocols without managing multiple SDKs or RPC connections.

Here's how to check your health factor across all protocols:

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

The response includes health factors, liquidation thresholds, and collateral values in USD:

{
  "positions": [
    {
      "protocol": "aave-v3",
      "network": "ethereum-mainnet",
      "healthFactor": 1.85,
      "liquidationThreshold": 1.0,
      "totalCollateralUsd": 5420.30,
      "totalBorrowedUsd": 2930.15,
      "assets": [
        {
          "asset": "WETH",
          "type": "collateral",
          "amount": "2.1",
          "valueUsd": 4200.30,
          "apy": 0.0245
        }
      ]
    },
    {
      "protocol": "kamino",
      "network": "solana-mainnet", 
      "healthFactor": 2.34,
      "liquidationThreshold": 1.1,
      "totalCollateralUsd": 8750.25,
      "totalBorrowedUsd": 3740.10
    }
  ],
  "summary": {
    "totalCollateralUsd": 14170.55,
    "totalBorrowedUsd": 6670.25,
    "aggregateHealthFactor": 2.12,
    "lowestHealthFactor": 1.85,
    "protocolsAtRisk": 0
  }
}

Setting Up Health Factor Alerts

WAIaaS includes policy-based monitoring that can trigger notifications when health factors drop below thresholds. Create a lending policy with health factor limits:

curl -X POST http://127.0.0.1:3100/v1/policies \
  -H "Content-Type: application/json" \
  -H "X-Master-Password: my-secret-password" \
  -d '{
    "walletId": "<wallet-uuid>",
    "type": "LENDING_LTV_LIMIT",
    "rules": {
      "max_ltv_ratio": 0.75,
      "health_factor_warning": 1.5,
      "health_factor_critical": 1.2,
      "auto_deleverage_threshold": 1.1,
      "notification_channels": ["telegram", "webhook"]
    }
  }'

When your health factor drops below 1.5, WAIaaS sends a warning notification. At 1.2, it triggers a critical alert. Below 1.1, it can automatically trigger deleveraging actions to prevent liquidation.

Automated Position Management

Beyond monitoring, WAIaaS lets your AI agent automatically manage positions based on health factor changes. Here's how to set up an automated deleveraging strategy:

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

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

async function monitorAndDeleverage() {
  const positions = await client.getDeFiPositions();

  for (const position of positions.positions) {
    if (position.healthFactor < 1.3) {
      console.log(`⚠️ Health factor ${position.healthFactor} on ${position.protocol}`);

      // Calculate repayment needed to reach safe health factor (>2.0)
      const targetHealthFactor = 2.0;
      const repaymentNeeded = calculateRepayment(position, targetHealthFactor);

      // Execute repayment through WAIaaS
      const tx = await client.executeAction('aave-v3', 'repay', {
        asset: position.borrowedAsset,
        amount: repaymentNeeded.toString(),
        walletAddress: position.walletAddress
      });

      console.log(`🔧 Deleveraging tx: ${tx.id}`);
    }
  }
}

function calculateRepayment(position, targetHF) {
  // Simplified calculation - real implementation should account for
  // liquidation thresholds, price impact, and protocol-specific factors
  const currentLTV = position.totalBorrowedUsd / position.totalCollateralUsd;
  const targetLTV = currentLTV / targetHF;
  const repaymentUsd = position.totalBorrowedUsd * (currentLTV - targetLTV);
  return repaymentUsd / position.borrowAssetPrice;
}

// Run monitoring every 30 seconds
setInterval(monitorAndDeleverage, 30000);

Cross-Protocol Risk Assessment

WAIaaS aggregates positions across all protocols to give you portfolio-wide risk metrics. This prevents situations where closing a position on one protocol inadvertently triggers liquidation on another due to collateral interdependencies.

The aggregateHealthFactor in the API response considers cross-protocol correlations and shared collateral assets. If you're using the same WETH as collateral on both Aave and Compound, WAIaaS factors this into the risk calculation.

You can also set protocol-specific limits through policies:

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": "LENDING_ASSET_WHITELIST",
    "rules": {
      "allowed_collateral": [
        {"asset": "WETH", "max_ltv": 0.8},
        {"asset": "WBTC", "max_ltv": 0.75},
        {"asset": "USDC", "max_ltv": 0.9}
      ],
      "allowed_borrow": ["USDC", "DAI", "USDT"],
      "protocol_limits": {
        "aave-v3": {"max_position_usd": 50000},
        "kamino": {"max_position_usd": 25000}
      }
    }
  }'

Integration with Trading Strategies

Health factor monitoring becomes powerful when integrated with your existing trading logic. WAIaaS provides WebSocket subscriptions for real-time position updates:

// Subscribe to position updates
const ws = new WebSocket('ws://127.0.0.1:3100/v1/subscriptions/defi-positions');

ws.on('message', (data) => {
  const update = JSON.parse(data);

  if (update.type === 'health_factor_change') {
    const { protocol, oldHealthFactor, newHealthFactor, change } = update;

    if (newHealthFactor < 1.5 && change < -0.1) {
      // Health factor dropped significantly - pause new borrows
      pauseBorrowingStrategy(protocol);

      // Consider taking profits on related positions
      await reduceExposure(protocol, 0.2); // Reduce by 20%
    }
  }
});

Quick Start: Set Up Health Factor Monitoring

Here's how to get health factor monitoring running in under 5 minutes:

Start WAIaaS daemon:

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

Create a wallet and session:

waiaas quickset --mode mainnet
# Copy the session token from output

Check your current DeFi positions:

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

Set up health factor alerts:

curl -X POST http://127.0.0.1:3100/v1/policies \
  -H "Content-Type: application/json" \
  -H "X-Master-Password: <your-password>" \
  -d '{
    "walletId": "<wallet-id>",
    "type": "LENDING_LTV_LIMIT", 
    "rules": {"health_factor_warning": 1.5}
  }'

Monitor programmatically:

import { WAIaaSClient } from '@waiaas/sdk';
const client = new WAIaaSClient({
  sessionToken: 'wai_sess_<your-token>'
});
const positions = await client.getDeFiPositions();
console.log(`Lowest health factor: ${positions.summary.lowestHealthFactor}`);

Advanced: Multi-Wallet Portfolio Monitoring

For institutional strategies managing multiple wallets, WAIaaS supports portfolio-wide risk monitoring. Each wallet can have different risk profiles and health factor thresholds:

# Conservative wallet - early warnings
curl -X POST http://127.0.0.1:3100/v1/policies \
  -d '{"walletId": "conservative-wallet", "type": "LENDING_LTV_LIMIT", 
       "rules": {"health_factor_warning": 2.0, "max_ltv_ratio": 0.6}}'

# Aggressive wallet - higher risk tolerance  
curl -X POST http://127.0.0.1:3100/v1/policies \
  -d '{"walletId": "aggressive-wallet", "type": "LENDING_LTV_LIMIT",
       "rules": {"health_factor_warning": 1.3, "max_ltv_ratio": 0.85}}'

WAIaaS aggregates risk metrics across all wallets, giving you portfolio-wide health factors and correlation analysis between positions.

What's Next

Health factor monitoring is just one piece of comprehensive DeFi risk management. WAIaaS also provides cross-chain bridging, automated rebalancing, and integration with 15 DeFi protocols through a single API.

Ready to protect your DeFi positions from liquidation? Get started at GitHub or learn more at waiaas.ai. Your trading bot's survival depends on staying ahead of health factor drops — don't wait for the next market crash to find out your monitoring isn't fast enough.

Self-Hosted RPC Proxy: Why Your AI Agent Shouldn't Hit Public Endpoints

Wallet Guy — Sat, 11 Apr 2026 07:31:10 +0000

RPC proxy management becomes critical when your AI agent is hitting rate limits, burning through API credits, or leaking transaction patterns to public endpoints. Most developers start with Infura or Alchemy, but quickly discover they're paying premium prices for basic infrastructure while sacrificing privacy and control.

Why RPC Proxies Matter for AI Agents

AI agents make hundreds of blockchain queries per hour — checking balances, simulating transactions, monitoring gas prices, and validating smart contract states. Unlike human users who might check their wallet a few times per day, autonomous agents are constantly polling the network.

Public RPC endpoints throttle requests, charge per call, and log every query. Your trading strategies, wallet addresses, and transaction patterns become visible to third parties. For production agents managing real funds, this creates both cost and security concerns.

WAIaaS Built-in RPC Proxy

WAIaaS includes a self-hosted RPC proxy that sits between your AI agent and blockchain networks. Instead of your agent hitting external endpoints directly, it routes all requests through your local WAIaaS instance, which then forwards them to your configured RPC providers.

Here's how to check your RPC proxy configuration:

curl http://127.0.0.1:3100/v1/rpc-proxy-url \
  -H "Authorization: Bearer wai_sess_<your-token>"

The proxy automatically handles:

Request caching to reduce upstream calls
Failover between multiple RPC providers
Rate limiting and retry logic
Request/response logging for debugging

Setting Up Your RPC Infrastructure

WAIaaS supports 2 chain types (EVM and Solana) across 18 networks. For each network you plan to use, configure at least one RPC endpoint in your environment variables:

# Ethereum mainnet
WAIAAS_RPC_EVM_ETHEREUM_MAINNET=https://eth-mainnet.g.alchemy.com/v2/your-key

# Solana mainnet  
WAIAAS_RPC_SOLANA_MAINNET=https://api.mainnet-beta.solana.com

# Base mainnet
WAIAAS_RPC_EVM_BASE_MAINNET=https://base-mainnet.g.alchemy.com/v2/your-key

# Polygon
WAIAAS_RPC_EVM_POLYGON_MAINNET=https://polygon-rpc.com

For production setups, configure multiple RPC providers per network for redundancy:

# Multiple providers for Ethereum (comma-separated)
WAIAAS_RPC_EVM_ETHEREUM_MAINNET=https://eth.llamarpc.com,https://rpc.ankr.com/eth,https://ethereum.publicnode.com

Docker Deployment with RPC Configuration

The Docker deployment makes RPC proxy setup straightforward. Create an .env file with your RPC endpoints:

# .env file
WAIAAS_RPC_SOLANA_MAINNET=https://api.mainnet-beta.solana.com
WAIAAS_RPC_EVM_ETHEREUM_MAINNET=https://eth-mainnet.g.alchemy.com/v2/your-key
WAIAAS_RPC_EVM_BASE_MAINNET=https://base-mainnet.g.alchemy.com/v2/your-key
WAIAAS_RPC_EVM_ARBITRUM_MAINNET=https://arb1.arbitrum.io/rpc

Then start WAIaaS with Docker Compose:

services:
  daemon:
    image: ghcr.io/minhoyoo-iotrust/waiaas:latest
    container_name: waiaas-daemon
    ports:
      - "127.0.0.1:3100:3100"
    volumes:
      - waiaas-data:/data
    environment:
      - WAIAAS_DATA_DIR=/data
      - WAIAAS_DAEMON_HOSTNAME=0.0.0.0
    env_file:
      - path: .env
        required: false
    restart: unless-stopped

volumes:
  waiaas-data:
    driver: local

Why Self-Hosted Beats Managed Services

Cost Control: Instead of paying per API call, you pay your RPC provider's flat rate (or run your own nodes). For high-frequency agents, this can reduce costs by 10x.

Privacy: Your transaction patterns stay local. No third party sees which tokens you're querying, which contracts you're analyzing, or when you're preparing transactions.

Reliability: Configure multiple RPC providers with automatic failover. If one goes down, your agent keeps running.

Customization: Built-in caching, custom retry logic, and request filtering. You control how your agent interacts with the blockchain.

No Vendor Lock-in: Switch RPC providers without changing your agent code. The proxy abstracts away provider-specific quirks.

Integration with AI Agent Frameworks

The RPC proxy works seamlessly with WAIaaS's 45 MCP tools for Claude Desktop and other AI frameworks. When your AI agent calls blockchain functions, it automatically routes through your local proxy:

# Configure MCP to use your WAIaaS instance
{
  "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>"
      }
    }
  }
}

Your AI agent's blockchain queries — balance checks, transaction simulations, DeFi position monitoring — all route through your self-hosted infrastructure.

Quick Start: Self-Hosted RPC Proxy

Clone and configure:

git clone https://github.com/minhoyoo-iotrust/WAIaaS.git
cd WAIaaS
echo "WAIAAS_RPC_SOLANA_MAINNET=https://api.mainnet-beta.solana.com" > .env

Start with Docker:

docker compose up -d

Create a wallet and session:

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

Test the RPC proxy:

curl http://127.0.0.1:3100/v1/rpc-proxy-url \
  -H "Authorization: Bearer wai_sess_<your-token>"

Set up MCP integration:

waiaas mcp setup --all

Your AI agent now has a self-hosted RPC proxy handling all blockchain interactions, with full control over providers, caching, and failover logic.

For deeper integration patterns and advanced configurations, check out the GitHub repository at https://github.com/minhoyoo-iotrust/WAIaaS and explore the full documentation at https://waiaas.ai.

What's Next

Ready to eliminate RPC bottlenecks and reclaim control of your AI agent's blockchain infrastructure? The self-hosted approach gives you the privacy, reliability, and cost control that production agents demand.

Push Relay + Telegram: Real-Time Transaction Approval for AI Agents

Wallet Guy — Fri, 10 Apr 2026 14:20:12 +0000

AI agents with crypto wallets need real-time approval systems to prevent unauthorized transactions while maintaining operational speed. When your trading bot or DeFi agent encounters a high-value transaction that exceeds policy limits, you need immediate notification and the ability to approve or deny the action without compromising security or custody control.

Why Real-Time Approval Matters

The challenge with autonomous AI agents isn't just preventing them from making bad trades—it's maintaining oversight without becoming a bottleneck. Traditional crypto security assumes human-only access, but AI agents operate at machine speed across multiple protocols simultaneously. A spending limit policy might catch obvious problems, but what about edge cases? Market opportunities that exceed your daily limits? Emergency liquidations during volatile conditions?

You need a system that can instantly notify you when agent actions require approval, provide transaction context, and let you respond immediately from any device. Email notifications are too slow, SMS lacks transaction details, and checking a web dashboard isn't practical when you're away from your computer.

How WAIaaS Implements Real-Time Approval

WAIaaS provides 2 real-time approval channels specifically designed for AI agent oversight: Push Relay notifications and Telegram integration. Both work with WAIaaS's 4-tier security system (INSTANT/NOTIFY/DELAY/APPROVAL) to give you precise control over when human approval is required.

Push Relay: Native Mobile Notifications

The Push Relay service sends native push notifications to your mobile device whenever an AI agent transaction requires approval. Unlike generic notification services, Push Relay is built specifically for crypto transaction approval workflows.

Here's how to set up Push Relay for transaction approval:

# Start both daemon and push-relay services
docker compose up -d

# The push-relay service runs on port 3101 by default
# Check if it's running
curl http://127.0.0.1:3101/health

Configure your wallet policies to trigger APPROVAL tier for high-value transactions:

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

When your AI agent attempts a transaction exceeding these limits, Push Relay immediately sends a notification containing:

Transaction amount and recipient
Risk assessment and policy violation details
One-tap approve/deny buttons
Estimated gas costs and slippage
Market context (for DeFi actions)

Telegram Integration: Cross-Platform Approval

Telegram provides a more detailed approval interface with rich transaction previews and conversation history. The Telegram signing channel supports both individual and group-based approval workflows.

Set up Telegram notifications through the CLI:

waiaas notification setup --provider telegram --bot-token <your-bot-token>

Configure a policy to route APPROVAL-tier transactions to Telegram:

{
  "type": "SPENDING_LIMIT",
  "rules": {
    "instant_max_usd": 50,
    "approval_channel": "telegram",
    "delay_seconds": 300
  }
}

When an AI agent transaction requires approval, you receive a Telegram message with:

Formatted transaction details
Links to block explorers for verification
Inline buttons for approve/deny/delay
Transaction simulation results
Recent agent activity context

3-Layer Security Architecture

Push Relay and Telegram approval integrate with WAIaaS's broader security model:

Layer 1: Session Authentication - AI agents use short-lived JWT tokens with configurable TTL and renewal limits. Sessions can be instantly revoked if agent behavior becomes suspicious.

Layer 2: Policy Engine - 21 policy types provide default-deny protection. The ALLOWED_TOKENS and CONTRACT_WHITELIST policies ensure agents can only interact with pre-approved assets and protocols:

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

Layer 3: Real-Time Approval - Push Relay and Telegram provide the final human oversight layer. Even if an agent finds a way around other protections, high-value transactions still require your explicit approval.

Advanced Approval Workflows

Time-Based Delays with Cancellation

Some transactions benefit from a cooling-off period. WAIaaS's DELAY tier queues transactions for a specified time, during which you can review and cancel if needed:

{
  "type": "SPENDING_LIMIT",
  "rules": {
    "delay_max_usd": 2000,
    "delay_seconds": 900,
    "delay_cancellable": true
  }
}

Push Relay sends notifications at three stages:

Immediate: "Transaction queued for 15-minute delay"
Mid-delay: "5 minutes remaining to cancel transaction"
Pre-execution: "Transaction executing in 30 seconds"

Multi-Signature Group Approval

For institutional use cases, Telegram group integration allows multiple team members to review and approve agent transactions:

# Add Telegram group as approval channel
waiaas notification setup --provider telegram --group-id <group-id> --required-approvals 2

Emergency Kill Switch

Both Push Relay and Telegram provide instant kill switch functionality. A single tap can:

Revoke all active agent sessions
Cancel all pending/delayed transactions
Freeze wallet activity until manual review
Export transaction logs for forensic analysis

Quick Start: Set Up Real-Time Approval

Here's how to get approval notifications working in under 5 minutes:

Step 1: Deploy WAIaaS with Push Relay enabled:

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

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

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

Step 3: Set up approval policies that trigger for transactions over your comfort level:

curl -X POST http://localhost:3100/v1/policies \
  -H 'Content-Type: application/json' \
  -H 'X-Master-Password: <your-password>' \
  -d '{
    "walletId": "<wallet-uuid>",
    "type": "SPENDING_LIMIT",
    "rules": {
      "instant_max_usd": 25,
      "approval_max_usd": 500
    }
  }'

Step 4: Configure Push Relay or Telegram notifications:

# Option A: Push Relay (iOS/Android app)
waiaas notification setup --provider push-relay --device-token <token>

# Option B: Telegram bot
waiaas notification setup --provider telegram --bot-token <bot-token>

Step 5: Test the approval flow by having your agent attempt a transaction above your instant limit. You should receive a notification within seconds.

What's Next

Real-time approval bridges the gap between AI agent autonomy and security requirements, but it's just one component of comprehensive agent wallet management. For production deployments, you'll also want to explore rate limiting, contract whitelisting, and DeFi-specific policies that understand protocol risks.

Ready to implement bulletproof AI agent security? Check out the full implementation on GitHub or explore the complete security model at waiaas.ai.

ERC-8128 Message Signing: Verifiable AI Agent Communications

Wallet Guy — Fri, 10 Apr 2026 08:03:06 +0000

ERC-8128 message signing enables verifiable communications between AI agents without requiring blockchain transactions. Developers building agent-to-agent systems need cryptographic proof that messages actually came from the claimed sender, but current solutions either require expensive on-chain transactions or rely on centralized intermediaries that compromise decentralization.

Why Message Verification Matters for AI Agents

AI agents increasingly communicate with each other — coordinating trades, sharing market intelligence, or negotiating resource allocation. Without cryptographic verification, any agent can impersonate another, leading to manipulation attacks, false information propagation, or unauthorized actions performed under a trusted agent's identity.

Traditional message signing requires agents to expose private keys or rely on centralized authentication servers. ERC-8128 provides a standardized way for agents to sign messages with their wallet keys, creating verifiable proof of authorship that any other agent can validate independently.

ERC-8128 in WAIaaS: Secure Agent Communications

WAIaaS implements ERC-8128 message signing as part of its comprehensive security framework. AI agents can sign messages with their wallet's private key, and recipients can cryptographically verify the signature without trusting third parties.

This fits into WAIaaS's 3-layer security model:

Session auth controls what actions agents can perform
Policy engine enforces spending limits and whitelists
Message signing proves agent identity in communications

Sign a Message with ERC-8128

curl -X POST http://127.0.0.1:3100/v1/erc8128/sign \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer wai_sess_<token>" \
  -d '{
    "message": "MarketAnalysis: BTC trend bullish, confidence 0.87",
    "domain": "agent-network.example.com"
  }'

The response includes the signature and metadata needed for verification:

{
  "signature": "0x1234567890abcdef...",
  "message": "MarketAnalysis: BTC trend bullish, confidence 0.87",
  "domain": "agent-network.example.com",
  "signer": "0xabcdef1234567890...",
  "timestamp": "2026-04-09T10:30:00Z"
}

Verify Message Signatures

Recipients verify signatures without network calls:

curl -X POST http://127.0.0.1:3100/v1/erc8128/verify \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer wai_sess_<token>" \
  -d '{
    "signature": "0x1234567890abcdef...",
    "message": "MarketAnalysis: BTC trend bullish, confidence 0.87",
    "domain": "agent-network.example.com",
    "signer": "0xabcdef1234567890..."
  }'

Returns verification status:

{
  "valid": true,
  "signer": "0xabcdef1234567890...",
  "recoveredAddress": "0xabcdef1234567890..."
}

Security Through Policy Control

WAIaaS enforces message signing through policy controls. The ERC8128_ALLOWED_DOMAINS policy restricts which domains agents can sign messages for:

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": "ERC8128_ALLOWED_DOMAINS",
    "rules": {
      "domains": ["agent-network.example.com", "trading-pool.dao"]
    }
  }'

This prevents agents from signing arbitrary messages for unauthorized domains, reducing the attack surface for signature replay or domain confusion attacks.

MCP Integration for Claude Desktop

The ERC-8128 tools integrate seamlessly with Claude Desktop through MCP:

erc8128-sign-request — Sign messages with wallet key
erc8128-verify-signature — Verify received signatures

After setting up MCP integration, Claude can sign and verify messages directly:

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

Claude can then handle commands like "Sign this market analysis report" or "Verify this message from the trading agent."

Default-Deny Security Model

WAIaaS follows default-deny principles for message signing. Without an ERC8128_ALLOWED_DOMAINS policy, agents cannot sign messages at all. This prevents unauthorized signature generation even if session tokens are compromised.

The policy system enforces:

Domain restrictions — Only sign for whitelisted domains
Rate limiting — Prevent signature spam attacks
Time restrictions — Limit signing to business hours
Approval tiers — Require human approval for sensitive domains

Real-World Use Cases

Decentralized Trading Coordination

AI trading agents coordinate strategies by signing market analysis messages. Each agent verifies signatures before acting on intelligence, preventing manipulation by rogue agents.

Agent Reputation Systems

Combined with ERC-8004 onchain reputation, signed messages create verifiable agent communication histories. Bad actors can be identified and blacklisted based on their signature patterns.

Cross-Chain Agent Networks

Agents on different blockchains use ERC-8128 signatures to prove identity across chains, enabling unified agent networks spanning Ethereum, Solana, and other ecosystems.

Quick Start: Agent Message Signing

Install and start WAIaaS:

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

Create domain policy:

   curl -X POST http://127.0.0.1:3100/v1/policies \
     -H "Content-Type: application/json" \
     -H "X-Master-Password: <password>" \
     -d '{"walletId": "<uuid>", "type": "ERC8128_ALLOWED_DOMAINS", "rules": {"domains": ["your-domain.com"]}}'

Sign your first message:

   curl -X POST http://127.0.0.1:3100/v1/erc8128/sign \
     -H "Authorization: Bearer <session-token>" \
     -d '{"message": "Hello, agent network!", "domain": "your-domain.com"}'

Verify the signature using the returned data with the verify endpoint
Set up MCP for Claude Desktop integration using waiaas mcp setup --all

What's Next

ERC-8128 message signing provides the cryptographic foundation for trustless agent communications. Combined with WAIaaS's policy engine and session controls, you get verifiable agent identity with granular security controls.

Ready to build secure agent communication systems? Check out the code at GitHub or explore the full platform at waiaas.ai.

Production-Ready Docker Deployment: Secrets Overlay and Auto-Provisioning

Wallet Guy — Thu, 09 Apr 2026 14:59:53 +0000

Getting a production-ready Docker deployment for your AI agent's wallet infrastructure requires more than just docker run — you need secure secret management and automated provisioning that won't expose sensitive credentials to your deployment pipeline or containers. Self-hosting your wallet infrastructure means total control over private keys, policies, and transaction approvals without depending on third-party services that could leak data or impose rate limits.

Why Docker Security Matters for Wallet Infrastructure

When you're managing private keys and handling real cryptocurrency transactions, your deployment security becomes critical. A misconfigured container could expose master passwords in environment variables, process lists, or container logs. Traditional Docker deployments often require hardcoded secrets in docker-compose files or shell scripts — exactly what attackers look for.

WAIaaS addresses this with Docker Secrets integration and auto-provisioning features designed specifically for self-hosted wallet infrastructure. You get enterprise-grade secret management without the complexity of full orchestration platforms like Kubernetes.

The Two-Layer Security Approach

WAIaaS implements a dual-security model for production deployments:

Layer 1: Auto-Provisioning for First Boot
On initial startup, WAIaaS can generate cryptographically secure master passwords and save them to protected recovery files. This eliminates the chicken-and-egg problem of bootstrapping wallet infrastructure without manual intervention.

Layer 2: Docker Secrets Overlay
For ongoing operations, sensitive credentials are injected through Docker's built-in secrets mechanism, keeping passwords out of environment variables and container filesystems.

Docker Secrets Integration

The production deployment uses a secrets overlay pattern. Here's your base docker-compose.yml:

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

volumes:
  waiaas-data:
    driver: local

For production, you add the secrets overlay (docker-compose.secrets.yml):

# Create secret files with proper permissions
mkdir -p secrets
echo "your-secure-master-password" > secrets/master_password.txt
chmod 600 secrets/master_password.txt
chown root:root secrets/master_password.txt

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

This approach keeps secrets out of your main compose file and git repository. The secrets overlay is loaded only in production environments and can be managed by your deployment automation without exposing credentials.

Auto-Provisioning for Zero-Touch Deployment

For fully automated deployments, WAIaaS supports auto-provisioning mode:

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

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

The auto-provision feature generates a cryptographically secure master password using the same entropy sources as wallet key generation. The password is saved to /data/recovery.key inside the container and mounted volume, allowing you to retrieve it programmatically for further automation.

This is especially valuable for infrastructure-as-code deployments where you can't provide interactive password input. Your deployment script can start the container, retrieve the generated password, and securely store it in your secret management system.

Production Environment Configuration

Key environment variables for production deployments:

WAIAAS_AUTO_PROVISION=true              # Generate master password on first start
WAIAAS_DAEMON_PORT=3100                 # Internal listening port
WAIAAS_DAEMON_HOSTNAME=0.0.0.0         # Bind to all interfaces (inside container)
WAIAAS_DAEMON_LOG_LEVEL=info            # Avoid debug logs in production
WAIAAS_DATA_DIR=/data                   # Persistent data location
WAIAAS_RPC_SOLANA_MAINNET=<url>         # Your Solana RPC endpoint
WAIAAS_RPC_EVM_ETHEREUM_MAINNET=<url>   # Your Ethereum RPC endpoint

The Docker image runs as a non-root user (UID 1001) by default, following security best practices. The healthcheck endpoint at /health integrates with Docker's health monitoring and orchestration platforms.

Network Security and Port Binding

Notice the port binding in the default configuration: 127.0.0.1:3100:3100. This binds only to localhost, preventing external network access to your wallet infrastructure. For production deployments, you typically want this behind a reverse proxy with TLS termination and authentication.

If you need direct external access, you can modify the port binding, but ensure you have proper firewall rules and consider the security implications of exposing wallet infrastructure to the internet.

Persistent Data and Backup Strategy

WAIaaS stores all persistent data in /data inside the container, mapped to a named Docker volume. This includes:

Wallet private keys (encrypted)
Transaction history and logs
Policy configurations
Session tokens and authentication state

For production backup strategies, you can mount a host directory instead of a named volume:

volumes:
  - /opt/waiaas-data:/data

This allows your existing backup systems to access the data directory directly. The CLI includes backup commands for consistent snapshots:

# Create backup inside container
docker exec waiaas-daemon waiaas backup create --name "daily-backup"

# List available backups
docker exec waiaas-daemon waiaas backup list

# Export backup to host
docker cp waiaas-daemon:/data/backups/daily-backup.tar.gz ./

Health Monitoring and Watchtower Integration

The Docker image includes a built-in healthcheck that verifies the API endpoint responds correctly. This integrates with Docker's health monitoring and orchestration platforms like Docker Swarm or Portainer.

For automatic updates, WAIaaS works with Watchtower out of the box:

services:
  watchtower:
    image: containrrr/watchtower
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    command: --interval 30 waiaas-daemon

Watchtower will automatically pull new WAIaaS releases and restart the container while preserving your data volume and configuration.

Container Security Hardening

The WAIaaS Docker image follows container security best practices:

Non-root execution: Runs as UID 1001 to prevent privilege escalation
Minimal attack surface: Based on lightweight base images with only required dependencies
Read-only filesystem: Application files are immutable after container start
No package managers: Runtime container doesn't include npm, apt, or other package managers
Explicit healthchecks: Container health is verifiable by orchestration platforms

For additional hardening, you can run with read-only root filesystem:

docker run -d \
  --name waiaas \
  --read-only \
  --tmpfs /tmp \
  --tmpfs /var/log \
  -p 127.0.0.1:3100:3100 \
  -v waiaas-data:/data \
  ghcr.io/minhoyoo-iotrust/waiaas:latest

Integration with Reverse Proxies

For production deployments, you typically want WAIaaS behind a reverse proxy for TLS termination and additional security. Here's an example nginx configuration:

upstream waiaas {
    server 127.0.0.1:3100;
}

server {
    listen 443 ssl http2;
    server_name wallet.yourdomain.com;

    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;

    location / {
        proxy_pass http://waiaas;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

This provides TLS encryption and can integrate with authentication systems or IP allow-lists for additional access control.

Quick Start: Production Deployment

Here's how to get a production-ready WAIaaS deployment running:

Clone and configure:

   git clone https://github.com/minhoyoo-iotrust/WAIaaS.git
   cd WAIaaS

Set up secrets directory:

   mkdir -p secrets
   openssl rand -base64 32 > 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

Verify deployment:

   curl http://127.0.0.1:3100/health
   docker compose logs -f

Access admin interface:

   open http://127.0.0.1:3100/admin

The admin interface provides a web UI for wallet management, policy configuration, and monitoring — all running entirely on your infrastructure without external dependencies.

What's Next

With your production WAIaaS deployment running, you can start integrating AI agents through the MCP protocol or REST API. Check out the OpenAPI documentation at http://127.0.0.1:3100/reference for interactive API exploration, and consider setting up monitoring and alerting for your wallet infrastructure.

Ready to deploy your own wallet infrastructure? Get started with the code at GitHub or explore more deployment options at waiaas.ai.

20 CLI Commands: Complete Wallet Management for Your Self-Hosted Setup

Wallet Guy — Thu, 09 Apr 2026 07:58:03 +0000

Self-hosting your crypto wallet infrastructure means full control over your private keys, transaction policies, and agent permissions — no third-party custody required. WAIaaS provides a complete CLI toolkit with 20 commands for managing wallets, sessions, and policies on your own infrastructure. Whether you're running a single AI trading bot or managing multiple autonomous agents, these CLI commands give you granular control over every aspect of your wallet-as-a-service deployment.

Why CLI Management Matters for Self-Hosters

When you're running your own wallet infrastructure, you need more than just a web interface. You need scriptable commands for automation, backup strategies that work with your existing systems, and the ability to provision wallets without touching a GUI. Traditional wallet solutions force you to click through interfaces or rely on their hosted APIs with rate limits and custody risks.

Self-hosted wallet management eliminates these constraints. Your private keys never leave your server, your transaction policies can't be overridden by external services, and your AI agents operate with the permissions you define — not what a SaaS provider allows.

The Complete CLI Toolkit

WAIaaS includes 20 CLI commands covering wallet lifecycle, session management, backups, and integrations. Here's how they solve real self-hosting challenges:

Initial Setup and Provisioning

The init command creates your data directory and configuration files:

# Standard setup with password prompt
waiaas init

# Auto-provision mode generates a random master password
waiaas init --auto-provision

Auto-provision is perfect for Docker deployments where you want zero interaction during container startup. The master password gets saved to recovery.key for later hardening.

Start your daemon with complete control over the process:

waiaas start                    # Foreground with logs
waiaas start --daemon          # Background process
waiaas status                  # Check if running
waiaas stop                    # Clean shutdown

Wallet and Session Management

Create wallets for different purposes without any external API calls:

# Create wallets for different chains
waiaas wallet create --name "trading-bot" --chain solana --environment mainnet
waiaas wallet create --name "ethereum-defi" --chain evm --environment mainnet

# Get wallet details
waiaas wallet info --wallet-id <uuid>

The quickset command creates a complete multi-chain setup in seconds:

# Creates Ethereum + Solana wallets with MCP sessions
waiaas quickset --mode mainnet

# Outputs ready-to-use MCP configuration for Claude Desktop

Sessions provide AI agents with scoped access to specific wallets:

# Create session for an AI agent
waiaas session prompt --wallet-id <uuid>

# Returns: "Add this to your agent's environment:"
# WAIAAS_SESSION_TOKEN=wai_sess_eyJhbGciOiJIUzI1NiJ9...

Backup and Recovery Strategy

Self-hosters need reliable backup strategies that integrate with existing infrastructure:

# Create encrypted backup bundle
waiaas backup create --output-file "./backups/waiaas-$(date +%Y%m%d).backup"

# List backup contents without restoring
waiaas backup inspect --file "./backups/waiaas-20240408.backup"

# View all available backups
waiaas backup list

# Restore from backup (destructive operation)
waiaas restore --file "./backups/waiaas-20240408.backup"

Backup files are encrypted and contain everything needed to restore your complete setup: wallet keys, policies, session configurations, and transaction history. This integrates cleanly with standard backup tools like rsync, rclone, or your favorite backup solution.

MCP Integration for AI Frameworks

Model Context Protocol (MCP) connects your wallets to AI frameworks like Claude Desktop:

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

# Register specific wallet
waiaas mcp setup --wallet-id <uuid>

This writes configuration directly to Claude's config file, enabling your AI agents to access 45 MCP tools for wallet operations, DeFi actions, and transaction management.

Owner Connection and Security

The owner authentication system provides human oversight for high-value transactions:

# Connect hardware wallet or signing app
waiaas owner connect

# Check connection status
waiaas owner status

# Disconnect when done
waiaas owner disconnect

This establishes the cryptographic identity for transaction approvals and emergency controls, separate from your master password.

Notification Channels

Set up signing channels for transaction approvals:

# Configure push notifications for mobile approval
waiaas notification setup --channel push-relay

# Set up Telegram bot integration
waiaas notification setup --channel telegram

These channels enable human-in-the-loop approvals for transactions that exceed your instant execution policies.

Updates and Maintenance

Keep your self-hosted instance current:

# Update to latest version
waiaas update

# Check current status and version
waiaas status

Self-hosted updates give you control over when to upgrade, unlike SaaS platforms that force updates.

Docker Integration for Production

The CLI commands integrate seamlessly with Docker deployments. Here's a production-ready setup:

# Start with Docker Compose
git clone https://github.com/minhoyoo-iotrust/WAIaaS.git
cd WAIaaS
docker compose up -d

# Initialize through the container
docker exec waiaas-daemon waiaas init --auto-provision

# Create wallets via CLI
docker exec waiaas-daemon waiaas quickset --mode mainnet

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

Environment variables control daemon behavior:

# In your .env file or docker-compose.yml
WAIAAS_AUTO_PROVISION=true              # Skip password prompts
WAIAAS_DAEMON_PORT=3100                 # API port
WAIAAS_DATA_DIR=/data                   # Persistent storage
WAIAAS_RPC_SOLANA_MAINNET=<your-rpc>    # Custom RPC endpoints

Quick Start: Complete Self-Hosted Setup

Here's how to go from zero to running AI agents with wallet access in under 5 minutes:

Install and initialize:

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

Create wallets and sessions:

waiaas quickset --mode mainnet
# Outputs MCP configuration automatically

Set up Claude Desktop integration:

waiaas mcp setup --all

Create first backup:

waiaas backup create --output-file "./waiaas-backup-$(date +%Y%m%d).backup"

Test with Claude: Open Claude Desktop and ask "Check my wallet balance" — it should connect via MCP and return your wallet information.

Production Considerations

For production self-hosted deployments, consider these CLI patterns:

Automated backups with cron:

# Daily encrypted backups with 30-day retention
0 2 * * * /usr/local/bin/waiaas backup create --output-file "/backups/waiaas-$(date +\%Y\%m\%d).backup" && find /backups -name "waiaas-*.backup" -mtime +30 -delete

Health monitoring in your monitoring stack:

#!/bin/bash
# Health check script
waiaas status || {
  echo "WAIaaS daemon down, restarting..."
  waiaas start --daemon
}

Secure password rotation:

# After initial auto-provision, harden the master password
waiaas set-master
rm /data/recovery.key  # Remove auto-generated password file

The CLI's scriptable nature means it integrates with existing infrastructure automation tools like Ansible, Terraform, or simple bash scripts.

What's Next

These 20 CLI commands provide complete control over your self-hosted wallet infrastructure, from initial setup through production operations. The combination of Docker deployment, automated backups, and MCP integration creates a robust foundation for AI agent wallet access without third-party dependencies.

Ready to deploy your own wallet infrastructure? Clone the repository at https://github.com/minhoyoo-iotrust/WAIaaS and follow the self-hosting guide. For detailed configuration options and advanced deployment patterns, visit the documentation at https://waiaas.ai.