DEV Community

Cover image for 21 Policy Types for Trading Bot Risk Management: Complete Granular Control Guide
Wallet Guy
Wallet Guy

Posted on

21 Policy Types for Trading Bot Risk Management: Complete Granular Control Guide

#defi #security #api #trading

21 Policy Types for Trading Bot Risk Management: Complete Granular Control Guide

Trading bots live and die by their risk controls — a misconfigured bot can drain a wallet in minutes, and without granular policy enforcement baked into your wallet infrastructure, you're one bad trade away from a catastrophic loss. If you're building an automated trading system that touches DeFi protocols, perpetual futures, or cross-chain arbitrage, you need more than just "set a daily limit and hope for the best." WAIaaS gives you 21 distinct policy types with 4 security tiers, enforced at the wallet layer before a single transaction hits the chain.

Why Wallet-Layer Policy Enforcement Matters

Most trading bot setups treat risk management as an application concern — you write checks in your bot code, validate inputs, maybe wrap calls in try/catch. The problem is that application-level guards are fragile. A bug, a race condition, or a compromised API key can bypass them entirely. When your bot is holding real capital and executing autonomously at 3am, you want a second line of defense that can't be circumvented by your own code.

WAIaaS enforces policies at the transaction pipeline level, before execution. There's a 7-stage pipeline — validate, auth, policy, wait, execute, confirm — and your policies run in stage 3. If a transaction violates policy, it never reaches the signing stage. That's not application logic you wrote; that's infrastructure behavior. For high-frequency or high-value trading systems, this distinction is what separates a production-grade setup from a prototype.

The Policy Engine Architecture

WAIaaS has a default-deny policy model. That means if you haven't explicitly whitelisted a token, a contract, or a spender, those transactions are blocked. This is intentional and important for trading bots: your bot should only be able to do exactly what you've authorized it to do, nothing more.

Policies attach to a wallet, get evaluated against each incoming transaction request, and produce one of 4 security tier outcomes:

  • INSTANT — Execute immediately, no notification
  • NOTIFY — Execute immediately, but send you a notification
  • DELAY — Queue the transaction, wait delay_seconds, then execute (cancellable during the window)
  • APPROVAL — Block until a human approves via WalletConnect, Telegram, or push notification

For a trading bot, most of your small routine trades will hit INSTANT. Larger trades or unusual activity escalates automatically. You configure the thresholds; the infrastructure enforces them.

The 21 Policy Types — What Each One Does for Trading

Here's every policy type available and how it maps to real trading bot scenarios.

Amount and Spending Controls

SPENDING_LIMIT is your primary guardrail. It implements the 4-tier security model based on USD value. Configure it once per wallet and every transaction gets automatically tiered:

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

Tier assignment is deterministic: amount ≤ instant_max_usd → INSTANT, ≤ notify_max_usd → NOTIFY, ≤ delay_max_usd → DELAY, above that → APPROVAL. You can also set per-token limits inside token_limits 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

RATE_LIMIT caps the number of transactions per period — useful for preventing a feedback loop where your bot hammers the chain repeatedly during volatile conditions:

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

APPROVE_AMOUNT_LIMIT prevents your bot from issuing unlimited token approvals. If a DeFi protocol asks for type(uint256).max approval, this policy can block it. APPROVE_TIER_OVERRIDE lets you force all APPROVE-type transactions into a specific security tier regardless of amount — useful for always requiring human sign-off on new spender approvals.

Token and Contract Whitelists (Default-Deny)

These three policies implement default-deny at the asset and counterparty level. If they're configured, only explicitly listed items are allowed through.

ALLOWED_TOKENS — Your bot can only move tokens you've whitelisted. Anything else is blocked:

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

CONTRACT_WHITELIST — Your bot can only call contracts you've approved. For a Jupiter arbitrage bot, you'd list the Jupiter aggregator address:

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

APPROVED_SPENDERS — Controls which addresses can receive token approvals. Blocks your bot from accidentally approving a malicious router:

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

METHOD_WHITELIST — Goes one level deeper, restricting which function selectors your bot can call on any contract. Useful if you want to allow a contract but only specific functions within it.

Recipient and Network Controls

WHITELIST restricts which addresses your bot can send funds to. For a strategy that only moves between your own wallets or known counterparties, this locks it down tight:

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

ALLOWED_NETWORKS prevents cross-chain mistakes — if your bot is a Solana-only strategy, block it from touching Ethereum mainnet entirely:

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

TIME_RESTRICTION lets you constrain your bot to trading hours. If your strategy only makes sense during US market hours, enforce it at the infrastructure layer:

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

DeFi-Specific Risk Controls

This is where WAIaaS gets genuinely interesting for serious DeFi traders. These policies understand DeFi semantics, not just raw transaction values.

LENDING_LTV_LIMIT — Sets a maximum loan-to-value ratio for lending protocol interactions. Your bot can borrow on Aave, but it can't push the position past your configured LTV threshold. This is a direct circuit breaker against liquidation risk.

LENDING_ASSET_WHITELIST — Controls which assets your bot can use as collateral or borrow. Prevents exposure to assets you haven't vetted.

PERP_MAX_LEVERAGE — Hard cap on leverage for perpetual futures positions. Relevant if your bot trades on Hyperliquid or Drift. No matter what your strategy code says, it cannot open a position with more leverage than this policy allows.

PERP_MAX_POSITION_USD — Maximum position size in USD for perp trading. Combined with PERP_MAX_LEVERAGE, you have full control over your bot's risk exposure on derivatives.

PERP_ALLOWED_MARKETS — Restrict your bot to specific perp markets. If your strategy is SOL-PERP only, block it from accidentally touching other markets.

VENUE_WHITELIST — Controls which DEX venues or trading venues your bot can route through.

ACTION_CATEGORY_LIMIT — Sets limits per DeFi action category, giving you aggregate control across protocol types.

Agent Identity and HTTP Payment Controls

REPUTATION_THRESHOLD — ERC-8004 onchain agent reputation check. Transactions can be gated on whether the counterparty agent meets a minimum reputation score.

ERC8128_ALLOWED_DOMAINS — Controls which domains can participate in ERC-8128 HTTP signing interactions.

X402_ALLOWED_DOMAINS — If your bot uses the x402 HTTP payment protocol to pay for API calls automatically, this policy whitelists which domains it can pay. Your bot can call paid AI inference endpoints without human intervention, but only to pre-approved domains:

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

A Real Trading Bot Policy Stack

Here's what a practical policy configuration looks like for an automated Solana arbitrage bot running on mainnet. You'd apply these via the masterAuth API during setup:

First, create the wallet and session:

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

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

Then stack your policies — SPENDING_LIMIT for tiered execution, ALLOWED_TOKENS to restrict to USDC and SOL only, CONTRACT_WHITELIST for Jupiter and your known DEX contracts, ALLOWED_NETWORKS to block any non-Solana execution, and PERP_MAX_LEVERAGE if your strategy hedges on Drift:

# Spending limit — small arb trades go instant, larger ones notify you
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": 50,
      "notify_max_usd": 250,
      "delay_max_usd": 1000,
      "delay_seconds": 60,
      "daily_limit_usd": 10000
    }
  }'

# Token whitelist — only SOL and USDC
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"}
    ]}
  }'
Enter fullscreen mode Exit fullscreen mode

Now when your bot calls the execute action endpoint, every transaction gets evaluated against this stack before it ever reaches signing:

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

A policy denial comes back as a structured error you can handle deterministically in your bot logic:

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

Before You Execute: Dry-Run Simulation

Before any live trade, you can simulate the transaction to verify it will pass policy and estimate execution without actually submitting it. Just add "dryRun": true to any transaction request:

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

For a trading bot, this is useful during strategy development and as a pre-flight check when you're about to enter a new market or use a newly whitelisted contract for the first time.

Quick Start: Setting Up Policy-Controlled Trading

  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 trading wallet and generate a session token for your bot 
   waiaas quickset --mode mainnet
Enter fullscreen mode Exit fullscreen mode

  1. Apply your policy stack via the REST API as shown above — SPENDING_LIMIT first, then token and contract whitelists appropriate to your strategy

  2. Connect your bot using the TypeScript SDK or direct REST calls with the session token as Bearer auth

  3. Test with dry-run before going live — simulate your first few trade types and verify they pass policy at the expected tier

What's Next

The full OpenAPI 3.0 spec is available at http://127.0.0.1:3100/doc once your daemon is running, with an interactive Scalar API reference at http://127.0.0.1:3100/reference — every policy type has documented request/response schemas there. For deeper exploration of the 15 integrated DeFi protocols (Aave v3, Jupiter, Drift, Hyperliquid, Kamino, and more) and how your bot can access them through a single unified API, the WAIaaS GitHub has the full codebase with 684+ test files to study. Drop a star, open an issue, or contribute — the project is fully open source.

Top comments (0)