Developing Telegram Bot for Swaps
User opens Telegram, sends /swap 100 USDC ETH—and within 15 seconds transaction confirmed on Arbitrum. No MetaMask, no browser wallet, no switching between apps. This isn't simplification—for significant audience share, messenger is primary interface, and Telegram trading bots already process billions daily.
Complexity here isn't Telegram Bot API—it's trivial. Complexity is securely managing user private keys and minimizing risks working with real DEXs.
Key Architecture Problems
Private Key Storage
Central question upon which everything depends. Three typical approaches:
Custodial with Encryption. Server stores encrypted keys, encryption key—derivative from user PIN (PBKDF2 or Argon2). Convenient, but server—honeypot. One database leak + weak PIN brute force = user losses.
Non-Custodial via MPC. Private key never exists whole anywhere. Threshold signature scheme (TSS) divides between user and server—both parts needed for signing. Standard in production (Telegram Wallet uses MPC). Implementations: tZKP (tss-lib), Fireblocks MPC SDK. Significantly more complex development.
Local Wallet via TON Connect or WalletConnect. Bot only sends tx data, signing happens in user's wallet app. Safest, but worse UX—requires separate app.
For most projects, choice—custodial with Argon2 + HSM for production or MPC with budget. Never store keys plaintext, never log.
Slippage and Front-Running
Bot works via public RPC—transaction lands in mempool, visible to all. Sandwich attack on $10K+ USDC swap via Uniswap—standard situation. Solutions:
- Flashbots Protect for Ethereum mainnet: txs go directly to builders, bypassing public mempool
- Private RPC on L2 (Arbitrum Sequencer RPC, Base private endpoint)
- Dynamic slippage tolerance: stablecoin pairs 0.1%, alts 0.5-1%
Rate Limiting and Drain Protection
If bot compromised or user's Telegram account stolen, need mechanisms limiting damage:
- Daily withdrawal limit (user-configurable)
- 24-hour delay on withdrawal to new address first time
- 2FA for txs above threshold
- Anomaly monitoring (5+ txs per minute)
How We Build Bot
Backend Stack
Node.js + TypeScript, telegraf library for Telegram Bot API. For blockchain interaction—viem instead of ethers.js: better typing, smaller bundle, native Multicall3 support.
Swap quotes—via aggregators (1inch API, 0x API, Paraswap) with fallback to direct Uniswap v3 Quoter. Aggregators give better route and update faster. For production, critical handling when aggregator API unavailable—fallback must work.
User sessions—Redis with TTL. Pending tx states—PostgreSQL.
On-Chain Interaction
For each swap, bot:
- Requests quote from aggregator
- Shows user:
100 USDC → 0.0412 ETH (~$102.3), slippage 0.5%, gas ~$0.8 - Waits confirmation (Confirm / Cancel buttons)
- Builds tx, signs, sends
- Tracks status via
watchTransactionReceiptin viem - Sends notification with hash and explorer link
For chains supporting it, use eth_sendRawTransaction via Flashbots or equivalent.
Supported Chains
Typical swap bot config: Ethereum (large positions), Arbitrum One (main—balance fee and liquidity), Base (mass-market, fees <$0.01), BSC (budget audience). Adding new EVM-compatible chain—config + RPC + supported DEX list, 1-2 days work.
Workflow
UX and Security Design (2-3 days). Determine key storage model, wallet workflow (seed import / new generation), command list.
Backend and DEX Integration (1 week). Telegram bot, sessions, quotes, tx signing.
Testnet Testing (2-3 days). All scenarios: successful swap, revert from slippage, insufficient gas, network congestion.
Security Review and Deployment. Key storage analysis, rate limiting, deploy in isolated environment (Docker, secrets via env + vault).
Timeline Expectations
Basic bot with single chain and custodial wallet—1.5-2 weeks. Multi-chain with MPC and extended commands (limit orders, DCA)—4-6 weeks. Cost depends on security model and integrated protocol count.