We develop Telegram Trading Bots for trading on decentralized exchanges (DEX). Imagine a trader sees an opportunity on a DEX but cannot open a browser, connect MetaMask, and execute the trade in time. Our bot solves this: the user sends a command, and the bot constructs and submits a transaction within seconds. We use advanced architecture for speed and security. Over 5+ years, our team has delivered more than 30 blockchain projects, including trading bots for Ethereum, Solana, and Binance Smart Chain. Bots like Unibot, Maestro, and Banana Gun are prime examples of success in this category, generating tens of millions in fees.
Architecture of a Telegram DEX Bot
How Are Private Keys Stored?
The key question: how are private keys stored? Two approaches:
Custodial (managed wallets): the bot generates a wallet for each user, stores the private key in an encrypted store. The user funds the wallet, and the bot trades on their behalf. Convenient, but the user trusts the service with the keys.
Non-custodial: the user imports their private key or seed phrase. The bot uses the key to sign transactions. The key is stored encrypted (AES-256) in the bot's database. Better for security, but requires the user to trust the bot — the key is still in their hands.
Most Telegram trading bots use the custodial model for UX.
| Criteria | Custodial | Non-custodial |
|---|---|---|
| Key control | Service | User |
| Security | Depends on the server | Key encrypted, but leak risk |
| UX | Simpler (funding) | Requires import |
| Recovery | Via support | Seed phrase only |
DEX Integration
The bot interacts with DEXes directly through their smart contracts:
Uniswap V3: exactInputSingle or exactInput for multi-hop swaps. Need to calculate optimal tickLower/tickUpper and slippage tolerance.
Jupiter (Solana): Jupiter API is the standard for Solana bots. Aggregates liquidity from all Solana DEXes, returns the optimal route and a ready transaction.
PancakeSwap, SushiSwap: similar to Uniswap V2 interface, different chains.
DEX Aggregators: 1inch, Paraswap, 0x API — for best execution across multiple DEXes. Adds latency but better price.
Why MEV Protection Is Critical?
A major problem in DEX trading is sandwich attacks. A bot sees a pending transaction in the mempool, buys ahead, waits for the victim's execution, then sells — all in the same block. The victim gets a worse price. As noted in Flashbots documentation, a private mempool prevents such attacks. Solutions:
- Flashbots Protect RPC: transactions go through a private mempool, not visible publicly until inclusion in a block
- MEV Blocker: an alternative for Ethereum, free, works well
- High priority fee: transaction is included in the next block quickly, less time for sandwich
- Tight slippage: a narrow slippage tolerance prevents a sandwich attack from being profitable (transaction reverts)
Key Features
Trading
/buy <token_address> <amount_eth> — buy a token /sell <token_address> <percent> — sell % of a position /snipe <token_address> — snipe new listings /limit <token> <price> <amount> — limit order (off-chain monitoring) /dca <token> <amount> <interval> — DCA strategy Position Management
/positions — current positions with P&L /wallet — wallet balance /approve <token> — approve for trading /withdraw <amount> <address> — withdraw funds Auto-Sell Strategies
Users configure automatic sell conditions:
- Take profit: sell at +X%
- Stop loss: sell at -X%
- Trailing stop: moving stop
- Auto-sell at launch: sell upon reaching a market cap threshold
Copy Trading
A popular feature: copy trades from successful wallets.
/copytrade <wallet_address> <max_amount_per_trade> The bot monitors the mempool or on-chain transactions of the target wallet. When a swap is detected, it immediately executes a similar transaction. Speed is critical: there will be many frontrunners.
Challenges:
- Latency: need a fast RPC node (Alchemy, QuickNode) for minimal delay
- Slippage: the price has already moved by the time of copying
- Gas wars: multiple copiers of the same wallet compete, gas fees rise
Tokenomics and Monetization
Telegram trading bots earn through:
- Commission per swap: 0.5-1% of trade volume
- Subscription: monthly/yearly fee for premium features
- Referral program: % of commissions from referred users
- Revenue share: Unibot pays part of fees to token holders
The project's token creates a flywheel: holders receive protocol revenues, incentivizing holding, high market cap builds user trust.
Security: Critical Aspects
Key encryption: private keys are encrypted with AES-256 using a key derived from server secret + user_id. The server secret is not stored in the database.
Hardware Security Module (HSM): for production, encryption keys are stored in an HSM (e.g., AWS CloudHSM). The key cannot be physically extracted.
Rate limiting: limits on transaction amounts, frequency, and withdrawals. Protects against account compromise.
Audit: smart contracts (if any) undergo a security audit. Service code goes through code review. Bug bounty program.
Withdrawal confirmation: for large withdrawals, additional verification (email, 2FA). A 24-hour withdrawal delay for new addresses.
What Is Included in the Work
- Requirements analysis and architecture design (custodial/non-custodial, DEX selection)
- Development of smart contracts for wallets and swaps (Solidity/Rust)
- Backend on Node.js/TypeScript with Telegram API and RPC node integration
- Integration of DEXes and aggregators (Uniswap, Jupiter, 1inch)
- Implementation of MEV protection (Flashbots, MEV Blocker)
- Development of copy trading and auto-strategies
- Testing (unit, integration, fuzzing with Echidna)
- Security audit (Slither, Mythril, code review)
- API documentation and user guide
- Training of the client's team and 30 days of support
Development of a Telegram DEX bot MVP takes 2–3 months. A production-ready version with MEV protection, copy trading, and auto-strategies takes 5–8 months. We guarantee security: keys are encrypted, protocols are audited. Our experience is confirmed by dozens of completed projects. Contact us to discuss your case and get a consultation.