DEV Community

Cover image for 21 Policy Types Deep Dive: Complete Risk Management for Trading Bot Infrastructure
Wallet Guy
Wallet Guy

Posted on

21 Policy Types Deep Dive: Complete Risk Management for Trading Bot Infrastructure

#security #defi #ai #api

21 Policy Types Deep Dive: Complete Risk Management for Trading Bot Infrastructure

Trading bots operating without policy guardrails are one fat-finger or runaway loop away from draining their own wallets — and the 21 policy types built into WAIaaS exist precisely to prevent that. If you're building an arb bot, MEV system, or algo trading strategy, you need more than just a signing key: you need programmable risk controls that understand DeFi, enforce spending limits, and still get out of your bot's way when speed matters. This post walks through every policy type available in WAIaaS and how to wire them up for a production trading system.

Why Policy Infrastructure Is a Hard Problem for Trading Bots

Most bot developers start with a hot wallet and a private key. That works until it doesn't — until a bug sends tokens to the wrong address, until a misconfigured slippage triggers a massive swap, until a compromised session token drains your liquidity. At scale, these aren't edge cases, they're inevitable.

The challenge is that risk controls designed for human users are too slow for bots, and risk controls designed for speed give up too much safety. What you actually want is a system that lets small, routine trades execute instantly with no friction, escalates medium-sized moves to a notification, delays large moves long enough for you to cancel them, and flat-out requires your approval before anything catastrophic goes through. That four-tier model is exactly what WAIaaS implements, across 21 policy types that cover everything from basic spending limits to perpetual futures leverage caps and onchain reputation thresholds.

The Foundation: 4 Security Tiers

Before diving into individual policy types, it's worth understanding the tier model that most of them plug into. WAIaaS defines four tiers:

  • INSTANT — Execute immediately, no notification
  • NOTIFY — Execute immediately, send you a notification
  • DELAY — Queue the transaction for a configurable number of seconds, then execute (you can cancel during the window)
  • APPROVAL — Full stop, requires your explicit human approval via WalletConnect, Telegram, or push notification

Your SPENDING_LIMIT policy is what maps transaction amounts to these tiers. Everything else either inherits tier assignment from spending limits or overrides it for specific asset types or actions.

Setting Up Your Spending Limits

This is the first policy every trading bot should configure. Here's a realistic setup for a Solana-focused trading bot with moderate daily volume:

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

Amounts at or below $10 execute instantly — your arb bot doesn't wait. Amounts up to $100 execute instantly but you get a push notification. Amounts up to $1,000 go into a five-minute delay window. Anything above $1,000 requires your approval. The daily and monthly caps are hard ceilings regardless of tier.

You can also set per-token limits inside SPENDING_LIMIT for native assets:

{
  "instant_max_usd": 10,
  "notify_max_usd": 100,
  "delay_max_usd": 1000,
  "delay_seconds": 300,
  "daily_limit_usd": 500,
  "monthly_limit_usd": 5000,
  "token_limits": {
    "native:solana": {"instant_max": "1", "notify_max": "10", "delay_max": "50"}
  }
}
Enter fullscreen mode Exit fullscreen mode

This is useful when your bot trades stablecoins in large volumes but you want tighter controls on native SOL or ETH, which are harder to predict in USD terms during volatility.

Default-Deny: The Policies That Block Everything Unless Configured

Three policy types implement strict default-deny behavior. If these are configured, any token, contract, or spender not on the list gets blocked — no exceptions.

ALLOWED_TOKENS

Your bot should only be able to touch the tokens it's designed to trade. Configure this explicitly:

{
  "tokens": [
    {"address": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v", "symbol": "USDC", "chain": "solana"},
    {"address": "So11111111111111111111111111111111111111112", "symbol": "SOL", "chain": "solana"}
  ]
}
Enter fullscreen mode Exit fullscreen mode

Any attempt to transfer or interact with an unlisted token gets denied at the policy stage, before it ever touches the signing layer.

CONTRACT_WHITELIST

For DeFi interactions, you want to lock down which contracts your bot can call. A Jupiter-only bot should only be able to call Jupiter:

{
  "contracts": [
    {"address": "JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4", "name": "Jupiter", "chain": "solana"}
  ]
}
Enter fullscreen mode Exit fullscreen mode

APPROVED_SPENDERS

On EVM chains, token approvals are a major attack surface. APPROVED_SPENDERS blocks any approval transaction to an address not on the list, and lets you cap the maximum approval amount:

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

Pair this with APPROVE_AMOUNT_LIMIT to block unlimited approvals entirely, and APPROVE_TIER_OVERRIDE if you want all approval transactions to require explicit human sign-off regardless of USD amount.

DeFi-Specific Risk Controls

This is where WAIaaS goes beyond what generic wallet infrastructure offers. There are dedicated policy types for lending protocols, perpetual futures, and trading venues.

Lending Controls

If your bot uses Aave v3, Kamino, or other lending protocols, you can enforce loan-to-value limits at the policy level:

  • LENDING_LTV_LIMIT — Sets a maximum loan-to-value ratio. If your bot tries to borrow against collateral in a way that would exceed this LTV, the transaction is denied before execution.
  • LENDING_ASSET_WHITELIST — Restricts which assets your bot can supply or borrow.

These are especially valuable for bots running automated leveraged strategies, where a bug in the yield calculation could push LTV into liquidation territory.

Perpetuals Controls

If you're running on Hyperliquid or Drift, three policy types let you enforce hard limits on your bot's futures exposure:

  • PERP_MAX_LEVERAGE — Maximum leverage multiplier your bot can open positions at
  • PERP_MAX_POSITION_USD — Hard cap on position size in USD
  • PERP_ALLOWED_MARKETS — Whitelist of markets your bot is allowed to trade

A misconfigured leverage calculation in your strategy code can't breach these limits — they're enforced in the transaction pipeline before the trade goes out.

Venue Controls

VENUE_WHITELIST restricts which trading venues or protocol interfaces your bot can interact with, giving you a clean separation between approved execution paths and everything else.

ACTION_CATEGORY_LIMIT lets you set caps on entire categories of DeFi actions — useful if you want your bot to do swaps freely but require approval before it touches lending or derivatives.

Operational Controls for Running Bots

Beyond the financial risk controls, several policy types handle the operational realities of running automated systems.

RATE_LIMIT

Even if your bot has legitimate use cases for high-frequency trading, you probably don't want a runaway loop submitting thousands of transactions:

{"maxTransactions": 10, "period": "hourly"}
Enter fullscreen mode Exit fullscreen mode

This is a useful circuit breaker to catch bugs before they burn through your gas budget.

TIME_RESTRICTION

If your strategy only makes sense during certain market hours, or if you want to ensure no transactions go out while you're asleep and can't monitor:

{"allowedHours": {"start": 9, "end": 17}, "timezone": "UTC"}
Enter fullscreen mode Exit fullscreen mode

ALLOWED_NETWORKS

Lock your bot to specific chains. A Solana bot shouldn't be able to accidentally fire transactions on Ethereum mainnet:

{
  "networks": [
    {"network": "solana-mainnet"}
  ]
}
Enter fullscreen mode Exit fullscreen mode

WHITELIST

If your bot has a fixed set of known counterparties — like specific liquidity pools or protocol treasury addresses — you can restrict outgoing transfers to those addresses only:

{"allowed_addresses": ["<address1>", "<address2>"]}
Enter fullscreen mode Exit fullscreen mode

x402 and HTTP Payment Controls

If your bot is using the x402 HTTP payment protocol to pay for API calls automatically — say, for premium price feeds or data APIs — X402_ALLOWED_DOMAINS gives you a whitelist of domains that can trigger automatic payments:

{"domains": ["api.example.com", "*.openai.com"]}
Enter fullscreen mode Exit fullscreen mode

Without this configured, your bot can't be tricked into paying arbitrary endpoints.

Onchain Reputation Controls

Two policy types handle the more novel use cases around agent-to-agent trust:

  • REPUTATION_THRESHOLD — Sets a minimum ERC-8004 onchain reputation score required before your bot will transact with another agent
  • ERC8128_ALLOWED_DOMAINS — Whitelists domains for ERC-8128 HTTP signing interactions

These are relevant if your trading bot is participating in agent-to-agent settlement or running in an ecosystem where counterparty trust is verified onchain.

Executing a DeFi Trade Inside These Guardrails

Once your policies are configured, your bot's trading calls go through the normal session-authenticated API. Here's a Jupiter swap:

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

The transaction runs through the 7-stage pipeline: validate → auth → policy → wait → execute → confirm. The policy stage is where all 21 types are checked. If the swap amount is within your instant tier, it clears immediately. If CONTRACT_WHITELIST is configured and Jupiter is on it, it passes. If ALLOWED_TOKENS is set and SOL and USDC are listed, it passes. If anything fails, you get a structured error back:

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

The retryable field tells your bot whether to retry or surface the error to you.

Always Dry-Run Before You Go Live

Before deploying a new strategy or policy configuration, simulate the transactions:

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
  }'
Enter fullscreen mode Exit fullscreen mode

The dry-run goes through the full pipeline including policy checks, but doesn't broadcast. Use it to verify that your policy configuration accepts the trades you intend and blocks the ones you don't.

Quick Start: Getting Policy Controls Running

  1. Install the CLI and start the daemon 
npm install -g @waiaas/cli
waiaas init
waiaas start
Enter fullscreen mode Exit fullscreen mode
  1. Create a wallet 
curl -X POST http://127.0.0.1:3100/v1/wallets \
  -H "Content-Type: application/json" \
  -H "X-Master-Password: my-secret-password" \
  -d '{"name": "trading-wallet", "chain": "solana", "environment": "mainnet"}'
Enter fullscreen mode Exit fullscreen mode

  1. Apply your core policies — at minimum, set SPENDING_LIMIT, ALLOWED_TOKENS, and CONTRACT_WHITELIST before connecting your bot

  2. Create a session for your bot

curl -X POST http://127.0.0.1:3100/v1/sessions \
  -H "Content-Type: application/json" \
  -H "X-Master-Password: my-secret-password" \
  -d '{"walletId": "<wallet-uuid>"}'
Enter fullscreen mode Exit fullscreen mode
  1. Dry-run your first trade, confirm the policy response looks right, then go live

What's Next

The complete policy reference is in the interactive API docs at http://127.0.0.1:3100/reference once your daemon is running — it's an auto-generated OpenAPI 3.0 spec with a Scalar UI you can explore without writing any code. As your strategy evolves, you can layer policies: start with spending limits and token whitelists, then add DeFi-specific controls as you expand into lending or perpetuals.

Check out the full project on GitHub and the official site for deployment guides and SDK documentation:

Top comments (0)