If you want your users to trade from a Telegram chat, I build the bot and the backend behind it. I'm Oussama Allamou (0xMowgli). I was backend lead on ZapX, a multi-chain Telegram trading bot for Chainge Finance that runs across five networks. I deliver wallet creation, deposits, swaps, bridging and sniping behind a chat interface, plus the infrastructure that keeps it responsive when many users act at the same moment.
/ 01 · Scope
A wallet per user created inside the chat, deposits detected on chain, withdrawals. Key handling is designed before any other feature.
Swaps routed through aggregators: Jupiter on Solana, KyberSwap on EVM networks. Slippage, fees and confirmations reported back in the chat.
Cross-chain transfers, so a user moves funds between networks without leaving the bot.
Buy on launch, copy trading, rule-based orders. The engines I build for private clients, exposed as bot commands.
One typed layer for signing and transfers. Adding a network is an adapter and configuration, not a rewrite.
Fee collection, admin tooling, alerts and dashboards.
/ 02 · Process
Which networks, and how keys are held. These two decisions shape everything else.
Every feature depends on it, so it is written and tested first.
Swap, then bridge, then automation. Each one ships working before the next starts.
Chat traffic is bursty. A token trends and everyone presses buy in the same minute. I test for that before launch.
Dashboards and alerts are live from day one. The first weeks of real usage decide what gets built next.
/ 03 · Proof
Multi-chain Telegram trading bot for Chainge Finance
The closest match to this page. I led the backend: wallet creation, deposits, swaps, bridging and sniping across five networks.
Multi-network gaming wallet
Where I built multi-network wallet infrastructure, the same core a trading bot needs for signing and transfers.
Low-latency Solana trading engine
The sniping and copy-trading side, built alone, which can sit behind a bot as its execution engine.
/ 04 · FAQ
A single-chain bot with wallets and swaps through an aggregator is the short version: weeks. Each extra network, bridging, sniping and fee systems add to that. A multi-chain product is months of work, and most of it goes into wallet security, edge cases and operations, not the chat interface.
It is a real risk and it should be treated as the main design problem. A bot that signs for the user has to keep key material somewhere. What matters is how keys are encrypted, where decryption happens, who on the team can reach it, and what gets logged. I design that part first and tell you plainly what risk remains. Anyone who says there is none has not thought about it.
Solana and EVM networks. ZapX covers five networks, and at Kayros I worked on a wallet across more than 20 EVM networks. Adding an EVM chain is mostly configuration once the core exists. Solana is a separate execution path with its own adapter.
They can be once the bot has many users. Telegram limits how fast a bot can send messages, so a bot that pushes alerts to everyone needs a queue with priorities: trade confirmations first, notifications after. That is a design decision to make early, not something to patch after launch.
The Telegram side is free. The cost is infrastructure: servers, databases, and RPC or node access for each chain. A swaps-only bot can run on paid RPC plans. Sniping and copy trading on Solana need dedicated node access, and that is the largest line. I size it with you before building.
/ Related
/ Contact
Tell me which chains and which features. I'll tell you what the first version should be.