7 Transaction Types Your Trading Bot Can Execute: From Token Swaps to Contract Deployment

2026-09-13

7 Transaction Types Your Trading Bot Can Execute: From Token Swaps to Contract Deployment

Your trading bot spotted the opportunity — a 0.3% arb between Jupiter and a Drift perpetual, closing in seconds. Whether it can actually execute before the block closes depends entirely on the quality of your wallet infrastructure. Flaky signing, missing protocol support, or absent gas controls don't just cost you the trade; they can cost you capital. This post walks through all 7 transaction types your bot can submit through WAIaaS, with concrete API calls for each.

Why Infrastructure Is the Hidden Variable in Algo Trading

Most trading bot tutorials spend 90% of their time on signal generation and 10% on execution. In practice, execution is where bots die. You need to sign and broadcast transactions reliably, interact with multiple protocols without building each integration yourself, control gas spend, simulate before you commit, and enforce risk limits so a runaway loop doesn't drain the wallet. WAIaaS is an open-source, self-hosted Wallet-as-a-Service designed for exactly this: giving AI agents and automated systems a battle-tested execution layer with policy controls baked in.

The system exposes a 39-route REST API, 45 MCP tools, TypeScript and Python SDKs, and 15 DeFi protocol integrations — all running locally in Docker. Let's go through every transaction type and show you what the actual calls look like.

The 7 Transaction Types

WAIaaS defines 7 transaction types in a discriminated union: Transfer, TokenTransfer, ContractCall, Approve, Batch, NftTransfer, and ContractDeploy. Each maps to a real trading scenario your bot will eventually hit.

1. Transfer — Native Token Movement

The simplest type: move native tokens (SOL, ETH, etc.) between addresses. Used for funding sub-wallets, paying relayers, or consolidating profits back to a treasury.

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

For bots, the critical companion here is dry-run simulation. Before moving capital, simulate the transaction — especially useful when gas costs matter or you're near a spending limit threshold.

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
  }'

Run the simulation, check the response, then fire the real transaction only if the simulation passes. This matters in high-frequency scenarios where a failed on-chain transaction still costs gas.

2. TokenTransfer — ERC-20 / SPL Token Transfers

TokenTransfer handles SPL tokens on Solana and ERC-20s on EVM chains. This is the type your bot uses for USDC settlement, profit distribution, or moving stablecoins between strategies.

The same /v1/transactions/send endpoint accepts this type — you specify the token address in the payload. And critically, WAIaaS enforces your ALLOWED_TOKENS policy before it hits the wire. If your bot gets exploited or starts behaving unexpectedly, a whitelist policy means it simply cannot transfer tokens you haven't explicitly approved.

Policy setup for token whitelisting:

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"
        }
      ]
    }
  }'

ALLOWED_TOKENS is default-deny: if a token isn't in the list, the transaction is blocked at the policy stage — before it ever reaches the network. For a trading bot, this is a hard guardrail that survives code bugs.

3. ContractCall — DeFi Protocol Interactions

This is the workhorse type for any bot doing real DeFi. ContractCall covers everything from Jupiter swaps to Aave deposits to Drift perp opens. WAIaaS has 15 DeFi protocol integrations built in:

aave-v3, across, dcent-swap, drift, erc8004, hyperliquid, jito-staking, jupiter-swap, kamino, lido-staking, lifi, pendle, polymarket, xrpl-dex, zerox-swap

Rather than manually encoding calldata, you call the action endpoint directly:

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

The action layer handles route construction, slippage, and transaction building — your bot just expresses intent.

For gas conditional execution, WAIaaS includes a pipeline stage (stage-gas-condition) that holds a transaction until gas price meets a configured threshold. If your arb only works under a certain gas price, you set the condition and let the system wait rather than polling manually in your bot loop.

Contract whitelisting for safety:

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": "CONTRACT_WHITELIST",
    "rules": {
      "contracts": [
        {
          "address": "JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4",
          "name": "Jupiter",
          "chain": "solana"
        }
      ]
    }
  }'

Again, default-deny: your bot can't call a contract that isn't listed. This matters when you're running automated strategies — if your routing logic generates an unexpected contract address, the policy engine stops it cold.

4. Approve — Token Allowance Management

Before any DEX can move your ERC-20 tokens, you need to issue an approval. Approve transactions are a distinct type in WAIaaS, and they come with their own policy layer.

Two relevant policies here:

APPROVED_SPENDERS — whitelists which contracts can receive approvals at all:

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

APPROVE_AMOUNT_LIMIT — blocks unlimited approvals (type(uint256).max). For a trading bot, unlimited approvals are a security liability. This policy enforces a ceiling.

APPROVE_TIER_OVERRIDE — lets you force approvals into a specific security tier regardless of amount. Useful when you want all approvals to require human confirmation via WalletConnect, even small ones.

For bots operating on EVM chains with complex DeFi interactions, managing approvals correctly is often where bugs hide. Having policy enforcement at the infrastructure layer means your approval logic doesn't need to be perfect in application code.

5. Batch — Atomic Multi-Step Execution

Batch is where algorithmic trading gets interesting. Instead of submitting three separate transactions with race conditions between them, you bundle them atomically.

Classic use cases:

Approve + swap in one atomic unit
Multi-leg arbitrage across protocols
Rebalance multiple positions simultaneously

The batch transaction type is available through the same send endpoint, and the MCP tool send-batch exposes it directly to AI agent frameworks. For EVM bots using Account Abstraction, Batch pairs naturally with the ERC-4337 UserOp support — you can batch multiple operations into a single UserOp for gasless or sponsored execution.

WAIaaS supports ERC-4337 Account Abstraction with smart accounts, gasless transactions, and a UserOp build/sign API at /v1/userop. If your bot is running on EVM and you want to eliminate gas management from your application layer entirely, this is the path.

6. NftTransfer — NFT Position Management

Not every trading bot ignores NFTs. If you're running strategies around NFT liquidity pools, Metaplex compressed NFTs, or ERC-1155 gaming assets, NftTransfer handles both EVM (ERC-721/ERC-1155) and Solana (Metaplex) with metadata caching built in.

For most algo trading bots, this type is less critical — but if you're building on protocols like Tensor or building an NFT market maker, having native NftTransfer support means you don't need a separate signing path.

7. ContractDeploy — Deploying Strategy Contracts On-Chain

The final type: ContractDeploy. If your trading strategy involves deploying smart contracts — flash loan contracts, custom AMM logic, on-chain settlement contracts — WAIaaS handles the deployment transaction through the same unified pipeline.

This means your deployment goes through the same 7-stage transaction pipeline (validate → auth → policy → wait → execute → confirm) as every other transaction type. Gas conditions, spending limits, and approval requirements all apply consistently. You're not managing a separate signing path for deployment.

The Transaction Pipeline Every Trade Goes Through

Every one of these 7 types runs through a 7-stage pipeline:

Validate — Schema validation, address format checks
Auth — Session token verification
Policy — All 21 policy types evaluated, default-deny enforced
Wait — Gas condition checks, DELAY tier queue
Execute — Broadcast to network
Confirm — On-chain confirmation tracking

For trading bots, stages 3 and 4 are where most of the risk control happens. The policy engine supports 21 policy types with 4 security tiers (INSTANT / NOTIFY / DELAY / APPROVAL). A typical trading bot configuration might look like:

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
    }
  }'

Transactions under $100 execute immediately (INSTANT). $100–$500 triggers a notification. $500–$2000 queues for 15 minutes. Over $2000 requires explicit owner approval. A runaway bot can't drain the wallet; it hits the daily limit and stops.

Quick Start: Bot Wallet in 5 Steps

Step 1: Start the daemon

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

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

Step 3: 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 4: Set spending limits and token whitelist

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
    }
  }'

Step 5: Execute your first 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"
  }'

The OpenAPI spec and interactive docs are available locally once the daemon is running:

# Interactive API reference
open http://127.0.0.1:3100/reference

What's Next

If you want to go deeper on execution reliability, the TypeScript SDK's getTransaction() polling pattern and the Python SDK's async/await interface both give you clean confirmation loops without managing raw HTTP. For multi-chain bots running across EVM and Solana simultaneously, WAIaaS supports 18 networks across both chain types — worth reviewing the full network list to match your target markets.

The full source, Docker setup, and documentation are at https://github.com/waiaas/WAIaaS. If you want the hosted dashboard and protocol overview, start at https://waiaas.ai.