Mobile-First Transaction Approvals: Push Relay + Telegram for Trading Bot Security

Mobile-First Transaction Approvals: Push Relay + Telegram for Trading Bot Security

Trading bots move fast, but a rogue session or compromised API key can drain your wallet faster. If you're running automated trading strategies — arb bots, MEV searchers, algorithmic DeFi — you already know that speed and security are usually at war with each other. Lock things down too hard and you kill your latency. Leave too much open and one bad transaction wipes the account. WAIaaS's push relay and Telegram signing channels give you a third path: let the bot run freely within tight policy guardrails, and get a mobile ping the moment something needs a human eye.

The Real Risk in Automated Trading

Most trading bot setups have an uncomfortable secret: the bot has effectively unlimited signing power. The session token sitting in your .env file can send anything, to anyone, for any amount. You're trusting that your code has no bugs, your key management is perfect, and nobody has access to that token but you.

That's a lot of trust.

The problem compounds at scale. When you're running Jupiter swaps, Drift perps, and LI.FI bridges from the same wallet, a single misconfigured trade or an exploit in one of those protocol integrations becomes a total-loss event. The industry answer has been "just don't keep much in the hot wallet" — but that's not a solution when your strategy requires capital on hand to execute.

WAIaaS approaches this differently. Rather than treating the wallet as a raw signer, it wraps every transaction in a 7-stage pipeline — validate, auth, policy check, wait, execute, confirm — and gives you fine-grained control over which transactions go through automatically, which trigger a notification, which get delayed, and which require you to pull out your phone and approve.

Four Security Tiers, Not Two

The typical "hot wallet vs. cold wallet" framing is too blunt for trading. WAIaaS uses 4 security tiers that map onto how traders actually think about risk:

INSTANT — Execute immediately, no notification. Your bot's routine rebalancing trades under a dollar threshold don't need to wake you up.

NOTIFY — Execute immediately, but send you a push or Telegram message so you know it happened. Good for medium-size trades you want visibility on without creating friction.

DELAY — Queue the transaction for a configurable number of seconds, then execute automatically unless you cancel. This is your circuit breaker for larger trades.

APPROVAL — Full stop. The transaction does not execute until you approve it via WalletConnect, Telegram, or push notification. Required for anything above your risk threshold.

These tiers aren't manually assigned per transaction. They're derived automatically from your policy configuration. Set up a SPENDING_LIMIT policy once, and every transaction your bot submits gets routed to the right tier based on its USD value:

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 config: trades under $100 execute instantly (your bot doesn't feel a thing), trades between $100-$500 execute but you get a notification, trades between $500-$2,000 are queued for 15 minutes (you can cancel if something looks wrong), and anything over $2,000 requires explicit approval. The daily cap at $5,000 means a runaway bot can't blow past your intended exposure even if it tries.

Three Signing Channels for Mobile Approval

When a transaction hits the APPROVAL tier, WAIaaS needs to reach you. There are 3 signing channels available: a push relay channel, a Telegram signing channel, and a wallet notification channel.

The push relay is WAIaaS's own notification infrastructure — a separate Docker image (push-relay) that handles delivery to mobile devices. The Telegram channel works through bot integration, which many traders already have set up for price alerts. The wallet notification channel ties into WalletConnect, letting you approve transactions from your hardware wallet's mobile app.

From a trading bot perspective, this is significant. Your bot is running autonomously on a server, but you retain a physical approval step for high-value transactions without any manual process changes on the bot side. The bot submits the transaction normally; WAIaaS intercepts it at the policy stage, sends it to whichever signing channel you've configured, and waits for your response.

Locking Down the Attack Surface with Policies

For a trading bot, you want more than just spending limits. WAIaaS has 21 policy types — here are the ones most relevant to automated trading:

CONTRACT_WHITELIST — Your bot should only be touching the protocols you've specifically authorized. If someone compromises your session token and tries to interact with an unknown contract, this blocks it:

{"contracts": [{"address": "JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4", "name": "Jupiter", "chain": "solana"}]}

ALLOWED_TOKENS — Default-deny on tokens. Your arb bot that's supposed to trade SOL/USDC shouldn't be able to send random SPL tokens even if a bug tries to:

{"tokens": [{"address": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v", "symbol": "USDC", "chain": "solana"}]}

APPROVED_SPENDERS — If your strategy involves token approvals (EVM DeFi), this whitelist ensures approvals only go to known protocol contracts. Combined with APPROVE_AMOUNT_LIMIT, you can block unlimited approvals entirely.

PERP_MAX_LEVERAGE and PERP_MAX_POSITION_USD — If you're running Drift perpetual strategies, these policies enforce position size limits directly at the wallet layer, independent of whatever your trading logic says. A bug that calculates 100x leverage instead of 10x gets blocked before it touches the chain.

RATE_LIMIT — Maximum transactions per period. If your bot suddenly starts firing 50 transactions in a minute when it normally does 5, that's a signal something went wrong:

{"maxTransactions": 10, "period": "hourly"}

ALLOWED_NETWORKS — Restrict your bot to only the chains it's supposed to operate on. An Ethereum bot shouldn't be able to accidentally send to Solana and vice versa.

Gas Conditional Execution

One underrated feature for trading bots: gas conditional execution. Your bot only sends the transaction when gas price meets a threshold you define. This is handled at the pipeline stage level — the transaction waits in the queue until gas conditions are satisfied rather than your bot needing to poll and resubmit.

For arb strategies where your profit margin is thin, this is not a nice-to-have. A trade that pencils out at 20 gwei becomes a loss at 80 gwei. Rather than building gas oracle logic into your bot, you lean on WAIaaS's pipeline to handle the condition check.

Multi-Protocol Access in One API Call

The protocol coverage matters for traders running cross-venue strategies. 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 Jupiter for Solana spot, Drift for Solana perps, Hyperliquid for perp futures and spot, LI.FI and Across for cross-chain bridging, Aave for EVM lending, Kamino for Solana lending, and Polymarket for prediction markets — all through the same session token, same API server, same policy engine.

A Jupiter swap from your bot looks like this:

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 same session token that executes that swap can open a Drift position, bridge proceeds via LI.FI, or stake idle SOL on Jito. The policy engine applies uniformly across all of them — you don't need to maintain separate risk logic for each protocol integration.

Dry Run Before You Send

For strategies that are hard to backtest perfectly, the dry-run API is useful. You can simulate a transaction before committing:

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

The same request with "dryRun": true runs through the full pipeline — policy checks, validation, everything — without touching the chain. You get back exactly what would happen if you ran it live. For a new strategy going into production, this lets you validate that your transaction construction is correct and that your policies won't block it unexpectedly, before any real capital moves.

Quick Start: Bot with Mobile Approvals

Here's the minimal path to a trading bot setup with push approvals for large trades:

Step 1 — Get WAIaaS running:

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

The daemon starts on 127.0.0.1:3100. Default port binding is 127.0.0.1:3100:3100.

Step 2 — Create a trading wallet and session:

# Create the 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"}'

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

Step 3 — Set your spending policy:

Use the SPENDING_LIMIT curl call from earlier. Tune instant_max_usd, delay_max_usd, and delay_seconds to match your strategy's typical trade sizes. Start conservative — you can always loosen it.

Step 4 — Add protocol and token restrictions:

Apply CONTRACT_WHITELIST and ALLOWED_TOKENS policies for the specific protocols and tokens your strategy touches. Default-deny means anything not on the list is blocked, which is exactly what you want for a live trading bot.

Step 5 — Configure your notification channel:

Run waiaas notification setup from the CLI to connect your preferred signing channel. Once configured, APPROVAL-tier transactions will route to your mobile device rather than blocking indefinitely.

Your bot uses the session token for all trading operations. Large trades get queued and ping your phone. Everything else executes at the latency your strategy needs.

Approving from Mobile

When a transaction hits the APPROVAL tier, you receive a mobile notification with the transaction details. The approval flow ties into WAIConnect — you review what the bot is trying to do (amount, recipient, protocol), and tap approve or reject. The transaction then either executes or is cancelled.

This keeps the human-in-the-loop step lightweight. You're not re-entering keys or going through a multi-step flow — you're reviewing a specific transaction that your bot flagged itself as large enough to warrant oversight, and making a binary decision. The ownerAuth layer handles the cryptographic verification:

curl -X POST http://127.0.0.1:3100/v1/transactions/<tx-id>/approve \
  -H "X-Owner-Signature: <ed25519-or-secp256k1-signature>" \
  -H "X-Owner-Message: <signed-message>"

Under the hood that's what your mobile approval is doing — generating a signature over the transaction ID that WAIaaS verifies before proceeding.

What's Next

The policy system has considerably more depth than what's covered here — DeFi-specific policies like LENDING_LTV_LIMIT, PERP_MAX_LEVERAGE, and VENUE_WHITELIST let you encode your risk parameters directly into the wallet layer rather than relying solely on your bot's logic. The full OpenAPI reference is available at http://127.0.0.1:3100/reference once your daemon is running, with interactive docs you can use to explore the 39 REST API route modules before writing a line of code.

For the full codebase and deployment configs, head to https://github.com/minhoyoo-iotrust/WAIaaS. Documentation and further resources are at https://waiaas.ai.