Telegram-бот для свопів: де ламається обмін
Своп у Telegram-боті виглядає простим: користувач обирає пару, підтверджує — і отримує актив. Насправді угода проходить через кілька незалежних станів, і на кожному її можна втратити.
Найчастіша відмова — прослизання ціни: між показом котирування й підтвердженням резерви в пулі змінюються, і в тонких парах велика заявка зсуває ціну сильніше, ніж користувач готовий прийняти.
Друга точка відмови — зависла операція. Транзакція підписана й пішла в мережу, але комісія виявилася нижчою за ринкову, підтвердження немає, а бот уже показав статус «в обробці».
Користувач бачить списання, баланс не змінився, і він іде в підтримку: формально кошти не втрачено, але угода не відбулася.
Третій і найдорожчий сценарій — обрив маршруту на півдорозі. Обмін криптовалют у боті рідко йде однією ногою: маршрут збирається через два-три пули, іноді з проміжним активом.
Якщо перша нога виконана, а друга зірвалася, кошти застрягають у проміжному токені, і розрулювати це доводиться вручну.
Для замовника це не абстракція: невдалі обміни — це покинуті кошики, потік звернень першої лінії та репутація бота, яку відновлюють місяцями. Розбираємо, як ці сценарії закриваються на рівні механіки: контроль прослизання, таймаути й скасування, атомарність маршруту.
Ефект впровадження: швидкість обміну, відмови, простої
Швидкість обміну
Вузьке місце — не сама мережа, а ланцюжок «котирування → підтвердження → підпис → відправлення». Ми тримаємо прогріті з’єднання з вузлами й запитуємо котирування паралельно, тому бот у Telegram відповідає за 1–2 секунди там, де ручний маршрут займав 10–15. Користувач не йде чекати в інший чат, а показана ціна збігається з виконаною.
Частка невдалих обмінів
Відмови спричиняють прослизання ціни, брак коштів на комісію та таймаут підтвердження. Повторна спроба з перерахунком маршруту, перевірка балансу до відправлення й запас на комісію переводять частку невдалих обмінів із десятків відсотків в одиниці. По кожній угоді залишається хеш і зрозумілий статус — розбір спірного випадку займає хвилини.
Автоматизація виплат
Черга на виплати, ідемпотентність операцій і автопідбір комісії прибирають ручну працю: партії виведень ідуть без оператора, а зависла транзакція підхоплюється повтором, не створюючи дубля. Нічні та пікові вікна закриваються тим самим кодом, що й удень.
Простій сервісу
Простій у години пік зазвичай пов’язаний з єдиним вузлом і лімітами джерела котирувань. Резервування вузлів, кілька джерел ціни й деградація замість падіння тримають сервіс на зв’язку: частина маршрутів відключається, обмін продовжується. Оновлення викочуються по одному вузлу — бот не йде в офлайн.
Варіанти виконання обміну: порівняння підходів
Схема виконання визначає, звідки бот бере курс, як будує маршрутизацію обміну й що робить, коли джерело недоступне. Варіант фіксуємо на етапі проєктування — від нього залежать логіка підтверджень, вимоги до зберігання ключів і поведінка системи при відмові.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Прямий пул | Одна-дві пари з достатньою глибиною, великі заявки, мінімум зовнішніх залежностей | Курс помітно відходить при прослизанні; на рідкісних парах ліквідність тонка, велика заявка сама рухає ціну |
| Агрегатор ліквідності | Багато пар, потрібен найкращий курс без власного набору джерел | Залежність від зовнішнього сервісу: затримки відповіді, ліміти запитів, частина маршруту непрозора |
| Власний маршрутизатор | Частотні пари, потрібен контроль над шляхом обміну та утриманням комісії | Дорожче в підтримці: ребаланс резервів, постійний контроль стану джерел, складніше тестувати |
| Кастодіальна схема | Введення та виведення поза мережею, простий інтерфейс для новачка | Кошти на рахунках оператора — жорсткіші вимоги до ключів, частина операцій ручна, додаються регуляторні обмеження |
На практиці рідко беруть один варіант у чистому вигляді. Частіше збираємо гібрид: агрегатор ліквідності як базове джерело курсу, власний маршрутизатор на парах із постійним потоком і кастодіальний контур як резерв для великих заявок.
Така зв’язка дає передбачуване виконання й зрозумілий сценарій, коли джерело відповідає помилкою: маршрут перебудовується, і обмін іде через резервний канал без участі користувача.
Як проходить впровадження: етапи інженерної роботи
Аудит починається не з коду, а з того, як активи реально рухаються між гаманцями, біржами й мережами. На цьому кроці ми фіксуємо місця, де транзакція може зависнути, і домовляємося про критерії приймання: яка частка операцій проходить із першої спроби й за який час.
- Аудит інфраструктури. Перевіряємо доступи до вузлів мережі, зберігання ключів, ліміти провайдерів і журнали минулих збоїв. На виході — перелік вузьких місць, які не можна закрити лише кодом.
- Схема потоків активів. Розбираємо, як токен іде від користувача, через які пули проходить і куди повертається. Схема показує, де підпис залишається в користувача, а де його контролює сервіс.
- Налаштування маршрутів. Визначаємо джерела котирувань, пріоритет пулів, поріг прослизання й поведінку при розходженні ціни. Маршрут перемикається сам, без ручного втручання в момент угоди.
- Складання логіки бота. Діалог, підтвердження угоди, статуси, повідомлення, повтори при помилці мережі. Кожен сценарій вибудуваний так, щоб користувач у будь-який момент бачив, де перебувають його кошти.
- Тестовий контур. Проганяємо маршрути на тестовій мережі, потім на обмежених лімітах. Дивимося не лише вдалі угоди, а й відмови, таймаути, повторні підписи.
- Передача в експлуатацію. Віддаємо конфігурації, схему, інструкції з моніторингу та порядок відкату. Окремо показуємо, як змінювати маршрути й ліміти без правки коду.
Артефакти впровадження: конфігурації, схеми, регламенти
Пакет передачі — не папка з презентацією, а робочий комплект у вашому репозиторії: з історією змін, правами на редагування та можливістю підняти середовище з нуля без нашої допомоги. Кожен артефакт закриває свій шар — налаштування, маршрути, доступи, експлуатацію.
- Конфігурація бота. Файл налаштувань із переліком підтримуваних мереж і токенів, лімітами на розмір операції, порогами прослизання й таймаутами очікування підтвердження — змінюється правкою значень, без перезбирання образу.
- Схема маршрутів. Діаграма шляху заявки від команди в чаті до підпису транзакції: які джерела ліквідності опитуються, у якому порядку, де вмикається резервний маршрут при відмові основного.
- Політика доступу до ключів. Де зберігаються ключі підпису, хто і за якою процедурою їх отримує, як розділені ролі оператора й адміністратора, як налаштовані ротація та відкликання доступу.
- Схема розгортання. Розділення тестового й бойового контурів, перелік змінних середовища, точки відкату на попередню збірку та порядок її повернення.
- Регламент обслуговування. Чек-ліст регулярних перевірок: баланс нативного токена для комісій, глибина черги заявок, відставання вузла від мережі, розбір відхилених транзакцій.
- Журналювання та оповіщення. Які події пишуться, з якою деталізацією, які пороги піднімають повідомлення черговому.
- Сценарії приймання. Набір перевірок з очікуваним результатом: успішний обмін, брак ліквідності, таймаут підтвердження, повторне відправлення.
Комплект передається з правом правки та без прив’язки до нас: інженер вашої команди розгортає бота за цими документами й далі веде його самостійно.
Кейс: як зросла частка успішних обмінів
Бот спочатку ходив за котируванням до одного джерела ліквідності. На тонких парах глибини не вистачало, і обмін відвалювався вже після підтвердження користувачем, а в чаті з’являлося однакове «не вдалося виконати обмін».
Кожен такий випадок інженери розбирали руками: звіряли хеші транзакцій, стан пулу й допуск токена до списання.
Першим ділом отримання ціни перевели на агрегатор 1inch — він сам збирає маршрут через кілька пулів і дробить великий обсяг на частини.
Перед відправленням бот повторно запитує котирування й перераховує мінімальну суму до отримання, а баланс і допуск токена перевіряються заздалегідь, до підпису — користувач бачить причину, а не абстрактну помилку.
Окремо зайнялися відгуком: важкі запити до мережі пішли у фонові задачі, тому бот реагує на команду одразу, а не після отримання ціни. Підсумок за трьома метриками:
| Метрика | До | Після |
|---|---|---|
| Частка успішних обмінів | 78% | 97% |
| Час відгуку бота | 9 с | 2 с |
| Ручних розборів на добу | 40+ | поодинокі |
Щоб результат не відкотився, на частку відмов поставили оповіщення, кожен крок маршруту пишеться в лог, а сценарії з браком ліквідності закриті автотестами. Підтримка переключилася з розбору завислих транзакцій на питання щодо продукту.
Чим відрізняється прямий своп від маршрутизації через агрегатор?
Прямий своп — це одна угода з одним пулом ліквідності: бот надсилає транзакцію, і контракт обмінює токен A на токен B за поточним співвідношенням резервів.
Агрегатор працює інакше: спочатку будує маршрут, розбиваючи суму між кількома пулами й майданчиками, іноді ланцюжком A → B → C, і лише потім збирає з цього одну транзакцію.
Різниця насамперед видна в ціні виконання. Прямий своп віддає те співвідношення, яке лежить у пулі, і на великій сумі воно просідає пропорційно до частки, яку ви забираєте з резерву.
Агрегатор сумує ліквідність кількох джерел, тому підсумкова ціна на середньому й великому обсязі зазвичай краща — але до неї додається комісія самого агрегатора й комісії кожного пулу в маршруті.
Швидкість і стійкість обміну влаштовані по-різному. Прямий своп передбачуваний: один виклик, зрозуміла витрата мережевої комісії, мінімум місць, де угода може відвалитися.
Маршрут через агрегатор довший, і чим більше в ньому переходів, тим вищий шанс, що на момент включення в блок частина пулів уже змінилася й транзакція впаде через перевищення прослизання — особливо на тонкій ліквідності неліквідного токена.
Тому в боті ми не фіксуємо один спосіб назавжди, а задаємо правило під конкретний потік: до певного порога й у ліквідній парі йде прямий своп, вище порога або за малої глибини пулу — маршрутизація через агрегатор з обмеженням допустимого прослизання й повторною перевіркою суми на виході.
Якщо маршрут не збирається, логіка відкочується на прямий своп або знижує обсяг, і користувач бачить не помилку, а виконаний обмін.
Безпека ключів, ліміти та відмовостійкість
Найчастіший технічний сумнів щодо своп-бота — не інтерфейс, а те, хто може розпорядитися коштами й що станеться при збої зовнішнього сервісу. Нижче — предметно за кожним пунктом: зберігання ключів, ліміти на обмін, відмовостійкість.
Де зберігаються ключі та хто має до них доступ?
Ключі не лежать у базі бота й не пишуться в логи. Підпис іде в ізольованому сервісі-підписувачі: ключ розшифровується в пам’яті лише на час складання транзакції й не покидає її. Кожне звернення фіксується в журналі — видно, хто і за якою угодою запросив підпис. За некастодіальної схеми ключ залишається у власника, бот лише ініціює обмін.
Як працюють ліміти на обмін і що при їх перевищенні?
Ліміти задаються на трьох рівнях: на одну угоду, на добовий обіг користувача й загальний запобіжник за всіма операціями. При перевищенні операція не відхиляється мовчки — вона йде на ручне підтвердження з повідомленням адміністратора. Пороги змінюються конфігурацією, без перезбирання й простою сервісу.
Що якщо зовнішній сервіс — пул, вузол мережі, біржа — недоступний?
Угода ведеться за журналом станів, тому відмова на будь-якому кроці не втрачає дані. Бот повторює запит із наростаючою затримкою й перед повтором звіряє стан за ідентифікатором операції — дубль транзакції не відправиться.
Якщо сервіс мовчить довше за заданий поріг, угода позначається як така, що потребує уваги, кошти залишаються у відомому стані, адміністратор отримує повідомлення. Після відновлення обробка продовжується з тієї ж точки.
Обговоримо задачу: надішліть опис потоку обміну
Щоб повернутися з оцінкою розробки бота, а не із загальними словами, нам потрібен ваш погляд на сам обмін. Нижче — те, що зазвичай закриває більшість питань; якщо чогось ще немає, достатньо описати словами, як це працює зараз.
- Опис потоку обміну: з якої мережі та токена користувач приходить, у яку йде, де бот бере ліквідність і за яким маршрутом проводить угоду.
- Правила котирування: як рахується курс, який допуск за ціною закладаємо, що показуємо при різкому русі ринку.
- Поведінка при збої: що робимо, якщо обмін не пройшов або пройшов частково — хто бачить статус, що отримує користувач, як відкочуємо операцію.
- Інтерфейс бота: набір команд і кнопок, робота в особистих повідомленнях чи в групі, чи потрібні ролі та адмін-панель.
- Підключення гаманців: які мають підтримуватися й чи підписує користувач операцію у себе.
- Вимоги до захисту: ліміти на операції, антифрод, журнал дій, розділення доступів.
- Що вже є: поточний код, схеми, логи, тестовий контур — підкажете, що перевикористаємо.
Опишіть задачу у вільній формі, додайте схему потоку, якщо вона є — обговоримо її предметно. Оцінка розробки бота будується за описом потоку обміну: чим точніше він викладений, тим менше уточнень і переробок на старті. Повернемося з планом робіт, складом етапів і строками.
