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

Telegram-бот для свапов: где ломается обмен

Свап в Telegram-боте выглядит простым: пользователь выбирает пару, подтверждает — и получает актив. На деле сделка проходит через несколько независимых состояний, и на каждом её можно потерять. Самый частый отказ — проскальзывание цены: между показом котировки и подтверждением резервы в пуле меняются, и в тонких парах крупная заявка сдвигает цену сильнее, чем пользователь готов принять.

Вторая точка отказа — зависшая операция. Транзакция подписана и ушла в сеть, но комиссия оказалась ниже рыночной, подтверждения нет, а бот уже показал статус «в обработке». Пользователь видит списание, баланс не изменился, и он идёт в поддержку: формально средства не потеряны, но сделка не состоялась.

Третий и самый дорогой сценарий — обрыв маршрута на половине пути. Обмен криптовалют в боте редко идёт одной ногой: маршрут собирается через два-три пула, иногда с промежуточным активом. Если первая нога исполнена, а вторая сорвалась, средства застревают в промежуточном токене, и разруливать это приходится вручную.

Для заказчика это не абстракция: неудачные обмены — это брошенные корзины, поток обращений первой линии и репутация бота, которую восстанавливают месяцами. Разбираем, как эти сценарии закрываются на уровне механики: контроль проскальзывания, таймауты и отмена, атомарность маршрута.

Эффект внедрения: скорость обмена, отказы, простои

Скорость обмена

Узкое место — не сама сеть, а цепочка «котировка → подтверждение → подпись → отправка». Мы держим прогретые соединения с узлами и запрашиваем котировки параллельно, поэтому бот в Telegram отвечает за 1–2 секунды там, где ручной маршрут занимал 10–15. Пользователь не уходит ждать в другой чат, а показанная цена совпадает с исполненной.

Доля неуспешных обменов

Отказы дают проскальзывание цены, нехватка средств на комиссию и таймаут подтверждения. Повторная попытка с пересчётом маршрута, проверка баланса до отправки и запас на комиссию переводят долю неуспешных обменов из десятков процентов в единицы. По каждой сделке остаётся хеш и понятный статус — разбор спорного случая занимает минуты.

Автоматизация выплат

Очередь на выплаты, идемпотентность операций и автоподбор комиссии убирают ручной труд: партии выводов уходят без оператора, а зависшая транзакция подхватывается повтором, не создавая дубля. Ночные и пиковые окна закрываются тем же кодом, что и днём.

Простой сервиса

Простой в часы пик обычно связан с единственным узлом и лимитами источника котировок. Резервирование узлов, несколько источников цены и деградация вместо падения держат сервис на связи: часть маршрутов отключается, обмен продолжается. Обновления выкатываются по одной ноде — бот не уходит в офлайн.

Варианты исполнения обмена: сравнение подходов

Схема исполнения определяет, откуда бот берёт курс, как строит маршрутизацию обмена и что делает, когда источник недоступен. Вариант фиксируем на этапе проектирования — от него зависят логика подтверждений, требования к хранению ключей и поведение системы при отказе.

На практике редко берут один вариант в чистом виде. Чаще собираем гибрид: агрегатор ликвидности как базовый источник курса, собственный маршрутизатор на парах с постоянным потоком и кастодиальный контур как резерв для крупных заявок.

Такая связка даёт предсказуемое исполнение и понятный сценарий, когда источник отвечает ошибкой: маршрут перестраивается и обмен уходит через резервный канал без участия пользователя.

Как проходит внедрение: этапы инженерной работы

Аудит начинается не с кода, а с того, как активы реально двигаются между кошельками, биржами и сетями. На этом шаге мы фиксируем места, где транзакция может зависнуть, и договариваемся о критериях приёмки: какая доля операций проходит с первой попытки и за какое время.

1. Аудит инфраструктуры. Проверяем доступы к узлам сети, хранение ключей, лимиты провайдеров и журналы прошлых сбоев. На выходе — перечень узких мест, которые нельзя закрыть только кодом.
2. Схема потоков активов. Разбираем, как токен уходит от пользователя, через какие пулы проходит и куда возвращается. Схема показывает, где подпись остаётся у пользователя, а где её контролирует сервис.
3. Настройка маршрутов. Определяем источники котировок, приоритет пулов, порог проскальзывания и поведение при расхождении цены. Маршрут переключается сам, без ручного вмешательства в момент сделки.
4. Сборка логики бота. Диалог, подтверждение сделки, статусы, уведомления, повторы при ошибке сети. Каждый сценарий выстроен так, чтобы пользователь в любой момент видел, где находятся его средства.
5. Тестовый контур. Прогоняем маршруты на тестовой сети, затем на ограниченных лимитах. Смотрим не только удачные сделки, но и отказы, таймауты, повторные подписи.
6. Передача в эксплуатацию. Отдаём конфигурации, схему, инструкции по мониторингу и порядок отката. Отдельно показываем, как менять маршруты и лимиты без правки кода.

Артефакты внедрения: конфигурации, схемы, регламенты

Пакет передачи — не папка с презентацией, а рабочий комплект в вашем репозитории: с историей изменений, правами на редактирование и возможностью поднять окружение с нуля без нашей помощи. Каждый артефакт закрывает свой слой — настройки, маршруты, доступы, эксплуатацию.

• Конфигурация бота. Файл настроек с перечнем поддерживаемых сетей и токенов, лимитами на размер операции, порогами проскальзывания и таймаутами ожидания подтверждения — меняется правкой значений, без пересборки образа.
• Схема маршрутов. Диаграмма пути заявки от команды в чате до подписи транзакции: какие источники ликвидности опрашиваются, в каком порядке, где включается резервный маршрут при отказе основного.
• Политика доступа к ключам. Где хранятся ключи подписи, кто и по какой процедуре их получает, как разделены роли оператора и администратора, как настроены ротация и отзыв доступа.
• Схема развёртывания. Разделение тестового и боевого контуров, перечень переменных окружения, точки отката на предыдущую сборку и порядок её возврата.
• Регламент обслуживания. Чек-лист регулярных проверок: баланс нативного токена для комиссий, глубина очереди заявок, отставание узла от сети, разбор отклонённых транзакций.
• Журналирование и оповещения. Какие события пишутся, с какой детализацией, какие пороги поднимают уведомление дежурному.
• Сценарии приёмки. Набор проверок с ожидаемым результатом: успешный обмен, недостаток ликвидности, таймаут подтверждения, повторная отправка.

Комплект передаётся с правом правки и без привязки к нам: инженер вашей команды разворачивает бота по этим документам и дальше ведёт его самостоятельно.

Кейс: как выросла доля успешных обменов

Бот изначально ходил за котировкой в один источник ликвидности. На тонких парах глубины не хватало, и обмен отваливался уже после подтверждения пользователем, а в чате появлялось одинаковое «не удалось выполнить обмен». Каждый такой случай инженеры разбирали руками: сверяли хеши транзакций, состояние пула и допуск токена к списанию.

Первым делом получение цены перевели на агрегатор 1inch — он сам собирает маршрут через несколько пулов и дробит крупный объём на части. Перед отправкой бот повторно запрашивает котировку и пересчитывает минимальную сумму к получению, а баланс и допуск токена проверяются заранее, до подписи — пользователь видит причину, а не абстрактную ошибку.

Отдельно занялись откликом: тяжёлые запросы к сети ушли в фоновые задачи, поэтому бот реагирует на команду сразу, а не после получения цены. Итог по трём метрикам:

Чтобы результат не откатился, на долю отказов поставили оповещения, каждый шаг маршрута пишется в лог, а сценарии с недостатком ликвидности закрыты автотестами. Поддержка переключилась с разбора зависших транзакций на вопросы по продукту.

Чем отличается прямой свап от маршрутизации через агрегатор?

Прямой свап — это одна сделка с одним пулом ликвидности: бот отправляет транзакцию, и контракт обменивает токен A на токен B по текущему соотношению резервов. Агрегатор работает иначе: сначала строит маршрут, разбивая сумму между несколькими пулами и площадками, иногда цепочкой A → B → C, и только потом собирает из этого одну транзакцию.

Разница в первую очередь видна в цене исполнения. Прямой свап отдаёт то соотношение, которое лежит в пуле, и на крупной сумме оно проседает пропорционально доле, которую вы забираете из резерва. Агрегатор суммирует ликвидность нескольких источников, поэтому итоговая цена на среднем и крупном объёме обычно лучше — но к ней добавляется комиссия самого агрегатора и комиссии каждого пула в маршруте.

Скорость и устойчивость обмена устроены по-разному. Прямой свап предсказуем: один вызов, понятный расход сетевой комиссии, минимум мест, где сделка может отвалиться. Маршрут через агрегатор длиннее, и чем больше в нём переходов, тем выше шанс, что к моменту включения в блок часть пулов уже изменилась и транзакция упадёт по превышению проскальзывания — особенно на тонкой ликвидности неликвидного токена.

Поэтому в боте мы не фиксируем один способ навсегда, а задаём правило под конкретный поток: до определённого порога и в ликвидной паре идёт прямой свап, выше порога или при малой глубине пула — маршрутизация через агрегатор с ограничением допустимого проскальзывания и повторной проверкой суммы на выходе. Если маршрут не собирается, логика откатывается на прямой свап или снижает объём, и пользователь видит не ошибку, а исполненный обмен.

Безопасность ключей, лимиты и отказоустойчивость

Самое частое техническое сомнение по свап-боту — не интерфейс, а то, кто может распорядиться средствами и что произойдёт при сбое внешнего сервиса. Ниже — предметно по каждому пункту: хранение ключей, лимиты на обмен, отказоустойчивость.

Как работают лимиты на обмен и что при их превышении?

Лимиты задаются на трёх уровнях: на одну сделку, на суточный оборот пользователя и общий предохранитель по всем операциям. При превышении операция не отклоняется молча — она уходит на ручное подтверждение с уведомлением администратора. Пороги меняются конфигурацией, без пересборки и простоя сервиса.

Что если внешний сервис — пул, узел сети, биржа — недоступен?

Сделка ведётся по журналу состояний, поэтому отказ на любом шаге не теряет данные. Бот повторяет запрос с нарастающей задержкой и перед повтором сверяет состояние по идентификатору операции — дубль транзакции не отправится. Если сервис молчит дольше заданного порога, сделка помечается как требующая внимания, средства остаются в известном состоянии, администратор получает уведомление. После восстановления обработка продолжается с той же точки.

Обсудим задачу: пришлите описание потока обмена

Чтобы вернуться с оценкой разработки бота, а не с общими словами, нам нужен ваш взгляд на сам обмен. Ниже — то, что обычно закрывает большинство вопросов; если чего-то ещё нет, достаточно описать словами, как это работает сейчас.

• Описание потока обмена: из какой сети и токена пользователь приходит, в какой уходит, где бот берёт ликвидность и по какому маршруту проводит сделку.
• Правила котировки: как считается курс, какой допуск по цене закладываем, что показываем при резком движении рынка.
• Поведение при сбое: что делаем, если обмен не прошёл или прошёл частично — кто видит статус, что получает пользователь, как откатываем операцию.
• Интерфейс бота: набор команд и кнопок, работа в личке или в группе, нужны ли роли и админ-панель.
• Подключение кошельков: какие должны поддерживаться и подписывает ли пользователь операцию у себя.
• Требования к защите: лимиты на операции, антифрод, журнал действий, разделение доступов.
• Что уже есть: текущий код, схемы, логи, тестовый контур — подскажете, что переиспользуем.

Опишите задачу в свободной форме, приложите схему потока, если она есть — обсудим её предметно. Оценка разработки бота строится по описанию потока обмена: чем точнее он изложен, тем меньше уточнений и переделок на старте. Вернёмся с планом работ, составом этапов и сроками.