Lock Your Trading Bot to Trusted Protocols: VENUE_WHITELIST Policy Deep Dive

Trading bots operating without a venue whitelist are one misconfigured RPC call away from routing through a malicious or unintended protocol — and in DeFi, that mistake is usually irreversible. If you're building an arbitrage system, MEV bot, or algorithmic trading strategy, the VENUE_WHITELIST policy in WAIaaS gives you a hard enforcement layer that ensures your bot only ever touches the protocols you explicitly approved. No exceptions, no surprises.

Why Protocol-Level Restrictions Matter for Automated Trading

When a bot runs autonomously — no human in the loop, executing dozens of transactions per hour — the attack surface expands dramatically. A compromised dependency, a poisoned price feed, or a subtle bug in your routing logic could push a transaction toward a protocol you never intended to interact with. Without enforcement at the wallet layer, your only defense is the correctness of your own code.

That's a fragile position. Policy enforcement at the infrastructure level means even if your bot logic has a bug, the wallet refuses to execute transactions against venues outside your whitelist. The policy engine sits inside a 7-stage transaction pipeline — validation, auth, policy, wait, execute, confirm — and a VENUE_WHITELIST violation kills the transaction at stage three, before anything hits the chain.

What VENUE_WHITELIST Actually Does

VENUE_WHITELIST is one of 21 policy types available in WAIaaS's policy engine. It enforces a default-deny posture on trading venues: if a venue isn't explicitly listed, the transaction is blocked. This is the same default-deny logic applied to ALLOWED_TOKENS and CONTRACT_WHITELIST — the wallet won't act unless you've told it exactly what's permitted.

For a trading bot this translates directly: you configure exactly which DEXes, perp exchanges, lending protocols, or bridges your bot is allowed to interact with. Jupiter for Solana swaps? Listed. Drift for perpetuals? Listed. Anything else your bot might accidentally call? Blocked at the policy stage, never reaching execution.

The policy engine uses 4 security tiers — INSTANT, NOTIFY, DELAY, APPROVAL — and VENUE_WHITELIST works alongside SPENDING_LIMIT and other policy types to give you layered control. A transaction can pass venue validation but still get held for human approval if it exceeds your spending threshold. These policies compose.

Setting Up VENUE_WHITELIST via the REST API

Here's how you create a VENUE_WHITELIST policy for a trading wallet. You'll need masterAuth — the system administrator credential — to configure 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": "VENUE_WHITELIST",
    "rules": {
      "venues": [
        {"name": "Jupiter", "address": "JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4", "chain": "solana"},
        {"name": "Drift", "address": "<drift-program-address>", "chain": "solana"},
        {"name": "Hyperliquid", "chain": "evm"}
      ]
    }
  }'

Once this policy is active, any transaction your bot submits that routes through a venue not in this list returns a policy denial immediately:

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

retryable: false is the important signal here. This isn't a transient failure — it's a hard policy block. Your bot should treat this as a configuration issue, not something to retry.

Pairing VENUE_WHITELIST with SPENDING_LIMIT for Layered Risk Control

A venue whitelist tells your bot where it can trade. A spending limit tells it how much it can move. Together they give you the two axes of risk control that matter most for automated systems.

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

With this configuration, your bot can execute sub-$100 trades instantly with no interruption. Trades between $100–$500 execute immediately but trigger a notification to you. Trades between $500–$2000 queue for 15 minutes before executing — giving you a cancellation window. Anything above $2000 requires explicit human approval via the ownerAuth flow.

For an arb bot hunting small-margin opportunities across Solana pools, the sub-$100 instant tier is where most execution happens. The higher tiers are your safety net for when position sizing logic goes wrong.

Executing a Trade Through the Policy Engine

Once policies are in place, your bot uses sessionAuth — a scoped JWT — to submit transactions. The session is tied to a specific wallet and has its own TTL and renewal limits. Here's a Jupiter swap from the bot's perspective:

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

This hits the 7-stage pipeline: validation checks the transaction structure, auth verifies the session token, policy checks VENUE_WHITELIST (Jupiter is listed — pass) and SPENDING_LIMIT (amount is within instant tier — pass), then execution proceeds. For bots optimizing on latency, the policy check is the stage you want to minimize variance in — and because it's a local in-process check against your stored policy configuration, there's no external network hop.

Dry-Run Before You Deploy

Before putting a new strategy live, use the dry-run API to verify your policy configuration behaves as expected. Pass dryRun: true and the transaction runs through all pipeline stages including policy evaluation — but never reaches execution.

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

For trading bots, this is invaluable for testing edge cases: does a transaction to a new venue get blocked by VENUE_WHITELIST? Does a large position size hit the APPROVAL tier? Run it dry first, check the response, then deploy with confidence.

Gas Conditional Execution: Only Trade When It's Cheap

One of the less obvious but practically important features for trading bots is gas conditional execution. WAIaaS supports executing transactions only when the gas price meets a configured threshold. For strategies where margin is tight, paying 3x the normal gas to execute a trade can flip a profitable arb into a loss.

The gas condition check is a dedicated stage in the transaction pipeline — stage-gas-condition — and it sits before execution. Your bot submits the transaction, and if gas is above your threshold, the transaction waits. No polling required on your end; the pipeline handles the retry logic.

For EVM bots hunting arbitrage windows, this means you can submit your transaction optimistically and let the infrastructure handle the "wait for acceptable gas" logic, rather than building that into your bot's execution loop.

Multi-Protocol Access: One Wallet, One API

A common pattern in sophisticated trading systems is cross-protocol execution: spot buy on one venue, hedge on a perp exchange, bridge proceeds to another chain. WAIaaS has 15 DeFi protocol providers integrated — including Jupiter, Drift, Hyperliquid, LI.FI, Across, Aave v3, Kamino, Pendle, and Polymarket — all accessible through the same session token.

Your VENUE_WHITELIST policy controls exactly which of these your bot can touch. A strategy that legitimately needs Jupiter + Drift + LI.FI lists those three. A simpler spot-only strategy lists only Jupiter. The same wallet infrastructure handles both; policy configuration is what differentiates them.

For cross-chain execution specifically, LI.FI and Across are both integrated as bridge providers. A bot that spots a yield differential between Ethereum and Solana can execute the bridge through the same API as the swap, with the same policy enforcement layer applied.

The 45 MCP Tools for Agent-Based Trading

If you're building your trading system on top of an AI agent framework like Claude rather than raw API calls, WAIaaS provides 45 MCP tools that expose the full wallet, transaction, DeFi, and NFT surface to the agent. Relevant tools for trading include send-token, send-batch, execute-action via the action-provider tool, get-balance, get-assets, get-defi-positions, simulate-transaction, and hyperliquid and polymarket tools for those specific venues.

The MCP setup is a single CLI command:

waiaas mcp setup --all

This auto-registers all wallets with Claude Desktop. Your VENUE_WHITELIST and SPENDING_LIMIT policies apply equally to MCP-initiated transactions — the enforcement layer is at the wallet infrastructure level, not at the interface layer.

Quick Start: Trading Bot with Venue Whitelist

Here's the minimal path to a running setup with VENUE_WHITELIST enforcement:

Step 1: Start the daemon

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

Step 2: Create a 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"}'

Step 3: Apply venue whitelist and spending limit policies

Use the policy creation calls from the sections above, substituting your wallet UUID.

Step 4: Create a session token 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>"}'

Step 5: Dry-run your first trade to verify policy enforcement

Use the dry-run snippet above before any live execution. Confirm that whitelisted venues pass and unlisted venues return POLICY_DENIED.

What's Next

The full list of 21 policy types — including PERP_MAX_LEVERAGE, PERP_MAX_POSITION_USD, PERP_ALLOWED_MARKETS, and LENDING_LTV_LIMIT — gives you granular control over every dimension of trading risk. The OpenAPI spec at http://127.0.0.1:3100/doc and the interactive reference at http://127.0.0.1:3100/reference are the fastest way to explore the full policy and action API surface. For production deployments, the Docker setup with Docker Secrets and the secrets overlay (docker-compose.secrets.yml) is the right starting point for hardening your environment.

Explore the codebase and full documentation at github.com/waiaas/WAIaaS and waiaas.ai.