Building a Production Solana Trading Bot: Architecture Deep Dive

#javascript #architecture #node #solana

I built a production Solana trading bot that runs on Telegram. Here's the complete architecture — what worked, what didn't, and lessons learned from 4,100 lines of Node.js.

Architecture

bot.js (single file)
├── Telegram Bot API (long-polling)
├── Jupiter V6 (swap routing)
├── Pump.fun (bonding curve trades)
├── Jito (MEV bundles)
├── Helius RPC (Solana access)
├── DexScreener (token discovery)
└── JSON file persistence

Why Single-File?

For bots under 5,000 lines, a single file beats multi-file architecture:

Zero import overhead
Easy deployment — scp bot.js server:~/ done
Easy debugging — one file, one stack trace
Ctrl+F finds everything

Telegram: Long-Polling > Webhooks

I use long-polling instead of webhooks:

No HTTPS certificate needed
Works behind NAT
Simpler error handling
No webhook URL to manage

Jupiter V6 Integration

Get quote → build swap transaction → sign → send via Jito for MEV protection. The key insight: always use dynamicComputeUnitLimit: true and prioritizationFeeLamports: 'auto' for reliable execution.

Copy Trading via Snapshot-Diff

Snapshot target wallet's token holdings
Wait 60 seconds
New snapshot
Diff: new tokens = buys, missing = sells
Execute matching trades

Simpler and more reliable than WebSocket monitoring.

12 Background Workers

All run in the main event loop on staggered intervals — no separate processes, no job queues. Check limit orders every 3 polls, copy trades every 2, DCA every 3, alerts every 5, premium expiry every 60.