Розробка Telegram-бота для свапів

Розробка Telegram-бота для свапів

Користувач відкриває Telegram, відправляє /swap 100 USDC ETH — і через 15 секунд транзакція підтверджена на Arbitrum. Без MetaMask, без браузерного гаманця, без переключення між додатками. Це не упрощення — для значної частини аудиторії саме мессенджер є основним інтерфейсом, та Telegram-боти для трейдингу вже обробляють мільярди доларів на добу.

Складність тут не у Telegram Bot API — він тривіален. Складність у тому, як безпечно управляти приватними ключами користувачів та мінімізувати ризики при роботі з реальними DEX.

Ключові проблеми архітектури

Хранення приватних ключів

Це центральний питання, від якого залежить все решта. Три типічних підходи:

Custodial з шифруванням. Сервер зберігає зашифровані ключі, ключ шифрування — похідна від PIN-коду користувача (PBKDF2 або Argon2). Зручно, але сервер — honeypot. Одна утечка базі + брутфорс слабких PIN-кодів = втрати користувачів.

Non-custodial через MPC. Приватний ключ ніколи не існує цілком ні у кого. Threshold signature scheme (TSS) ділить його між користувачем та сервером — для підписи потрібні обидві частини. Це стандарт у production (Telegram Wallet використовує MPC). Реалізації: тZKP (tss-lib), Fireblocks MPC SDK. Значно складніше в розробці.

Локальний гаманець через TON Connect або WalletConnect. Бот тільки відправляє дані транзакції, підпис відбувається у гаманці користувача. Найбезпечніше, але гірша UX — вимагає окремого додатку.

Для більшості проектів вибір — custodial з Argon2 + HSM для production або MPC при наявності бюджету на розробку. Ніколи не зберігаємо ключи plaintext, ніколи не логуємо.

Slippage та front-running

Бот працює через публічний RPC — транзакція попадає у mempool та видна всім. Sandwich attack на своп 10K+ USDC через Uniswap — стандартна ситуація. Рішення:

• Flashbots Protect для Ethereum mainnet: транзакції йдуть напрямки до builders, обминаючи публічний mempool
• Private RPC на L2 (Arbitrum Sequencer RPC, Base private endpoint)
• Динамічний slippage tolerance: для стейблкоін-пар ставимо 0.1%, для альтів — 0.5-1%

Rate limiting та захист від дренажу

Якщо бот скомпрометований або у користувача украли Telegram-аккаунт, потрібни механізми обмеження ущерби:

• Денний лімітом на вивід (налаштовується користувачем)
• Задержка 24 години на вивід коштів при першому додаванню нового адреса
• 2FA для транзакцій вище порогового значення
• Мониторинг аномальних паттернів (5+ транзакцій за хвилину)

Як ми будуємо бота

Backend-стек

Node.js + TypeScript, бібліотека telegraf для Telegram Bot API. Для взаємодії з блокчейном — viem замість ethers.js: краща типізація, менший bundle size, нативна підтримка Multicall3.

Котировки свапів — через агрегатори (1inch API, 0x API, Paraswap) з fallback на прямий Uniswap v3 Quoter. Агрегатори дають кращий маршрут та оновлюються швидше. Для production критична обробка випадку, коли агрегатор API недоступен — fallback повинен працювати.

Сессії користувачів — Redis з TTL. Стан ожидаючих підтвердження транзакцій — PostgreSQL.

On-chain взаємодія

Для кожного свапу бот:

1. Запитує котировку у агрегатора
2. Показує користувачеві: 100 USDC → 0.0412 ETH (~$102.3), slippage 0.5%, gas ~$0.8
3. Чекає підтвердження (кнопки Підтвердити / Отмена)
4. Будує транзакцію, підписує, відправляє
5. Стежить за статусом через watchTransactionReceipt у viem
6. Відправляє уведомлення з хешем та лінком на explorer

Для чейнів, де підтримується, використовуємо eth_sendRawTransaction через Flashbots або аналог.

Підтримувані чейни

Типова конфігурація для бота свапів: Ethereum (для крупних позицій), Arbitrum One (основний, баланс комісії та ліквідності), Base (для mass-market, комісії < $0.01), BSC (для аудиторії з меньшим бюджетом). Додавання нового EVM-сумісного чейна — конфіг + RPC + список підтримуваних DEX, 1-2 дні роботи.

Процес роботи

Проектування UX та безпеки (2-3 дні). Визначаємо модель хранення ключів, flow роботи з гаманцем (імпорт мнемоніки / генерація нового), список команд.

Backend та інтеграція з DEX (1 тиждень). Telegram-бот, сесії, котировки, підписання транзакцій.

Тестування на testnet (2-3 дні). Всі сценарії: успішний своп, revert через slippage, недостаток газу, congestion мережі.

Security review та деплой. Аналіз хранення ключів, rate limiting, деплой у ізольованому окружленні (Docker, секрети через env + vault).

Орієнтири за строками

Базовий бот з одним чейном та custodial-гаманцем — 1.5-2 тижні. Мультичейн з MPC та розширеним набором команд (лімітні ордера, DCA) — 4-6 тижнів. Вартість залежить від моделі безпеки та кількості інтегрованих протоколів.