DEV Community

Cover image for Lock Down Your DeFi Bot: VENUE_WHITELIST Policy for 15-Protocol Trading
Wallet Guy
Wallet Guy

Posted on

Lock Down Your DeFi Bot: VENUE_WHITELIST Policy for 15-Protocol Trading

#defi #security #api #blockchain

Lock Down Your DeFi Bot: VENUE_WHITELIST Policy for 15-Protocol Trading

DeFi trading bots live and die by two things: execution speed and risk controls. You've spent weeks tuning your arbitrage logic, backtesting entry conditions, and optimizing gas — but if your bot's wallet can call any contract on any protocol it wants, one compromised session token or a single logic bug is all it takes to drain everything. The VENUE_WHITELIST policy in WAIaaS gives your bot exactly the protocols it needs and nothing more.

Why Protocol Whitelisting Matters for Automated Trading

When you're running an automated strategy, the attack surface isn't just external threats — it's your own code. A malformed output from a price oracle, an unexpected edge case in your routing logic, a dependency that starts returning bad data: any of these can produce a transaction your bot didn't intend to send. Without hard constraints on which protocols your bot can interact with, a bug becomes a catastrophic loss event.

Beyond bugs, there's the session model to think about. WAIaaS issues session tokens (wai_sess_...) that your bot uses for all wallet operations. If that token leaks — through logs, environment variable exposure, or a compromised deployment — you want the blast radius to be exactly zero outside your approved venue list. Policy enforcement happens server-side in the daemon's transaction pipeline, before any transaction hits the chain. Your bot can't bypass it, and neither can an attacker holding a stolen session token.

What You're Working With

WAIaaS integrates 15 DeFi protocol providers: aave-v3, across, dcent-swap, drift, erc8004, hyperliquid, jito-staking, jupiter-swap, kamino, lido-staking, lifi, pendle, polymarket, xrpl-dex, and zerox-swap. That's a broad surface area for a trading bot to operate across — perpetual futures on Hyperliquid, spot swaps on Jupiter, cross-chain bridges via LI.FI and Across, lending positions on Aave and Kamino, prediction markets on Polymarket.

The wallet infrastructure is built around a 7-stage transaction pipeline: validate → auth → policy → wait → execute → confirm. The policy stage is where VENUE_WHITELIST lives. Every DeFi action your bot attempts gets checked against the policy before it moves to execution. This isn't an application-layer check you can accidentally skip — it's baked into the pipeline.

The policy engine has 21 policy types total, and VENUE_WHITELIST is specifically designed for this use case: restricting which trading venues and DeFi protocols a wallet session can interact with.

Setting Up VENUE_WHITELIST for Your Strategy

Let's say you're running a SOL/USDC arbitrage strategy that operates across Jupiter (Solana DEX) and hedges exposure using perpetual futures on Drift. You want your bot to have access to exactly those two protocols — nothing else.

First, create your wallet and a session for the bot:

# 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-wallet", "chain": "solana", "environment": "mainnet"}'

# Create a session token for the bot process
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

Now lock down the venue list with a VENUE_WHITELIST 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": "VENUE_WHITELIST",
    "rules": {
      "venues": ["jupiter-swap", "drift"]
    }
  }'
Enter fullscreen mode Exit fullscreen mode

That's it. Your bot's session token can now execute Jupiter swaps and Drift perp operations. Any attempt to call aave-v3, lifi, hyperliquid, or any other provider will be rejected at the policy stage with a POLICY_DENIED error before it ever touches a signing key.

Layering Policies for a Full Risk Stack

VENUE_WHITELIST answers where your bot can trade. You probably also want to control how much it can trade and what tokens it can move. The policy engine is additive — stack multiple policies on the same wallet.

Add a spending limit to cap the damage from any single runaway transaction:

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

The 4-tier security model assigns each transaction to INSTANT (execute immediately), NOTIFY (execute + alert you), DELAY (queue for 5 minutes, cancellable), or APPROVAL (requires your explicit sign-off via WalletConnect or Telegram). For an automated bot, you want most normal-sized trades hitting INSTANT, with larger position adjustments triggering a notification so you know they're happening, and anything anomalously large getting queued for you to review.

Add a token whitelist to prevent the bot from interacting with unknown tokens:

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

ALLOWED_TOKENS is default-deny: if the token isn't on the list, the transaction is blocked. Your bot physically cannot be tricked into buying a honeypot token or moving an asset you didn't pre-approve.

For perpetuals trading on Drift, you can also cap leverage and restrict which markets the bot can open positions in:

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": "PERP_MAX_LEVERAGE",
    "rules": {
      "max_leverage": 5
    }
  }'
Enter fullscreen mode Exit fullscreen mode

And if you want to go further, PERP_ALLOWED_MARKETS lets you restrict which perpetual markets the bot can trade. No accidental position opened on an illiquid altcoin market because of a bug in your market selection logic.

Executing Trades from Your Bot

Once policies are in place, your bot uses the session token for all operations. Here's what a Jupiter swap looks like from code:

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

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

// This will be blocked if jupiter-swap isn't in VENUE_WHITELIST
const swapResult = await client.executeAction('jupiter-swap', 'swap', {
  inputMint: 'So11111111111111111111111111111111111111112',
  outputMint: 'EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v',
  amount: '1000000000',
});
Enter fullscreen mode Exit fullscreen mode

Or directly via the REST API:

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

If your bot tries to call a venue that's not on the whitelist, it gets back a clean error response:

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

Your bot can catch that error and log it as an anomaly — an attempted call to an unauthorized venue is worth knowing about, whether it came from a bug or something worse.

Gas Conditional Execution

One more tool worth knowing about for trading automation: gas conditional execution. WAIaaS supports executing transactions only when gas price meets a threshold you define. For EVM-based strategies, this means your bot doesn't waste gas on trades that become unprofitable because of network congestion — the transaction simply waits until gas comes down to your acceptable range, then executes automatically.

This is handled in the transaction pipeline before the execute stage, so the policy and signing infrastructure still applies. You're not bypassing any of the security controls to get gas optimization.

Dry-Run Before You Deploy

Before you go live with a new strategy, use the dry-run API to simulate transactions through the full pipeline — including policy checks — without actually executing them:

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

Use this to verify your policy stack is configured correctly before connecting your bot to production capital. A dry-run that comes back with POLICY_DENIED is much better than discovering the misconfiguration after a live trade goes wrong.

Quick Start: Trading Bot with VENUE_WHITELIST

Here's the minimal path from zero to a locked-down trading wallet:

Step 1: Install the CLI and start the daemon

npm install -g @waiaas/cli
waiaas init
waiaas start
Enter fullscreen mode Exit fullscreen mode

Step 2: Create a wallet and session for your bot

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

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

Step 3: Apply your policy stack

Apply VENUE_WHITELIST, SPENDING_LIMIT, ALLOWED_TOKENS, and any perp-specific policies using the examples above. Order doesn't matter — all active policies are evaluated for every transaction.

Step 4: Verify with a dry-run

Use "dryRun": true to confirm your policy configuration is correct before funding the wallet.

Step 5: Deploy your bot with the session token

WAIAAS_SESSION_TOKEN=wai_sess_<your-token> WAIAAS_BASE_URL=http://127.0.0.1:3100 node your-bot.js
Enter fullscreen mode Exit fullscreen mode

What's Next

WAIaaS is open-source and self-hosted — the code is at https://github.com/minhoyoo-iotrust/WAIaaS and the full documentation is at https://waiaas.ai. The full list of 21 policy types, all 15 DeFi protocol providers, and the OpenAPI reference at /reference are good places to start if you're designing a more complex strategy. For production deployments, the Docker setup with Docker Secrets support gives you a clean way to keep your master password out of environment variables entirely.

Top comments (0)