Как мы создали торгового бота для Solana: разбор архитектуры

Как мы создали торгового бота для Solana: разбор архитектуры

Клиент пришёл с простым на вид заданием: торговый бот на Solana DEX, моментум-стратегия, 500+ сделок в день, максимальная просадка — 3% портфеля в сутки. Звучит конкретно. На практике это система из семи независимых слоёв, каждый из которых должен работать надёжно одновременно — под нагрузкой, в условиях рыночного стресса, с реальными деньгами. В этой статье — как мы её построили, какие компромиссы приняли и что сделали бы иначе.

Общая архитектура системы

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

Источники рыночных данных

↓

Strategy Engine

↓

Risk Manager ←→ Kill Switch

↓

Order Executor

↓

Мониторинг и алерты

Это разделение критически важно. Когда в продакшне появляется баг — а он появится — нужно сразу знать, в каком слое. Монолитный бот где данные, стратегия и исполнение ордеров перемешаны, невозможно отлаживать под давлением.

Data Layer: получение рыночных данных в реальном времени

Data layer — фундамент. Плохие данные → плохие решения → убытки раньше, чем успеешь отреагировать.

WebSocket-подключения. Подключаемся напрямую к WebSocket-фидам Solana DEX (Jupiter, Raydium) для получения апдейтов стакана и событий сделок. HTTP-поллинг добавляет задержку, которая делает стратегии реального времени ненадёжными. WebSocket даёт распространение событий за <100мс.

Нормализация данных. Разные DEX возвращают данные в разных форматах. Мы построили нормализующий слой, который приводит все входящие события к единой внутренней схеме до того, как они попадают в strategy engine. Это значит, что стратегия не зависит от конкретной биржи — добавить новый источник данных = написать один адаптер, не трогая стратегию.

Обработка обрывов соединения. WebSocket-соединения рвутся. Всегда. Data layer реализует переподключение с экспоненциальным backoff, резервный источник данных который активируется при падении основного, и детектор устаревших данных который останавливает торговлю если апдейтов не было N секунд. Стратегия никогда не должна работать на стейл-данных.

Мониторинг задержки. На каждом тике отслеживаем сквозную задержку от рыночного события до оценки стратегии. Если задержка превышает порог (200мс для этой стратегии), система фиксирует это. Устойчивые спайки задержки часто предшествуют перегрузке нод Solana — полезный ранний сигнал.

Strategy Engine

Strategy engine потребляет нормализованные рыночные данные и производит торговые сигналы. Мы намеренно держали этот слой простым и stateless.

Stateless vs Stateful стратегии. Stateless стратегия оценивает каждый тик независимо, опираясь только на текущее состояние рынка. Stateful стратегия поддерживает внутреннюю память — скользящие средние, трейлинг-стопы, позиции между сессиями. Stateless стратегии проще тестировать и рассуждать о них. Для этого проекта генерация сигналов — stateless; отслеживание позиций вынесено в Risk Manager.

Сама стратегия. Детали параметров мы не раскрываем — это IP клиента — но паттерн стандартный: засечь моментум цены выше порога, подтвердить объёмом, проверить спред, исполнить. Функция стратегии принимает снимок рынка и возвращает сигнал: BUY | SELL | HOLD. Без побочных эффектов, полностью покрывается юнит-тестами.

Бэктестинг. До деплоя на mainnet каждое изменение стратегии проходит бэктест на 6 месяцах исторических данных. Мы построили бэктестер который воспроизводит исторические тики через ту же функцию стратегии что используется в продакшне. Это важно: многие фреймворки для бэктестинга симулируют сделки на другом уровне абстракции — отсюда разрыв между бэктестом и реальными результатами. У нас этого разрыва нет.

Жёсткий урок: бэктест на дневных свечах почти бессмысленен для HFT-стратегий. Мы бэктестим на тиковых данных.

Risk Management System

Это самый важный слой в системе. Баг в strategy engine стоит вам одну сделку. Баг в risk management может стоить всё.

Лимиты позиций. Максимальный размер позиции на сделку — фиксированный процент от портфеля. Захардкожен, не настраивается в рантайме, не может быть переопределён сигналами стратегии.

Circuit breaker по дневной просадке. Если итоговый P&L за день опускается ниже -3% (требование клиента), вся торговля останавливается автоматически. Бот отправляет Telegram-алерт и ждёт ручного перезапуска. Система не возобновляется автоматически — возобновление после просадки требует решения человека.

Stop-loss на каждую позицию. Каждая открытая позиция получает стоп-лосс при входе. Если цена движется против позиции на X%, ордер закрывается немедленно — независимо от сигнала стратегии. Стоп-лоссы исполняются через тот же путь что обычные сделки, то есть подвержены тому же проскальзыванию — мы это учитываем в размере позиций.

Kill switch. Отдельный Telegram-бот (не торговый) принимает одну команду от авторизованных пользователей: /halt. По получению — отменяет все открытые ордера, закрывает все позиции по рынку, отключает новые ордера. Тестировали под имитацией высокой нагрузки перед деплоем на mainnet. Kill switch должен работать когда всё остальное сломано.

Order Execution Layer

На Solana исполнение ордеров — не просто "отправить транзакцию". Динамика мемпула, лимиты вычислительных единиц и механика priority fee означают, что наивное исполнение будет регулярно проваливаться или попадать под front-run.

Конструирование транзакций. Используем versioned transactions с address lookup tables чтобы уложить сложные DEX-свопы в лимиты compute units Solana. Транзакции включают priority fee который рассчитывается динамически на основе данных о текущей загруженности сети.

Retry logic. Транзакции Solana не проходят. Не редко — часто, в периоды конгестии. Наш execution layer реализует ретрай с экспоненциальным backoff, но с жёстким истечением: если транзакция не подтверждена за N секунд — считаем её неудавшейся и не ретраим. Strategy engine получает уведомление и может переоценить ситуацию. Бесконечный ретрай на быстро движущемся рынке — хороший способ исполнить сделку которую надо было отменить.

Управление проскальзыванием. Для каждой сделки мы рассчитываем допустимый диапазон проскальзывания до отправки и включаем его в параметры транзакции. Если on-chain исполнение даст проскальзывание хуже нашего порога — транзакция провалится на-chain вместо исполнения по невыгодной цене. Это свойство программ DEX на Solana, не то что мы реализуем сами — но нужно правильно выставить.

Отслеживание подтверждений. Каждую транзакцию отслеживаем от отправки до статуса confirmed. Неподтверждённые транзакции по истечении порога — в алерт. Эти данные идут в мониторинг-дашборд.

Мониторинг и алерты

Торговый бот без мониторинга — это риск. Нужно знать о проблемах немедленно — до того как risk management остаётся единственной преградой между вами и потерями.

P&L в реальном времени. Обновления P&L пушатся в дашборд каждые 60 секунд. Текущий P&L, разбивка по позициям, дневной максимум/минимум, стоимость проскальзывания — всё видно без открытия редактора.

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

Обнаружение аномалий. Мы реализовали простое пороговое обнаружение аномалий: если win rate опускается ниже исторического baseline на 30+ сделок подряд, если среднее проскальзывание растёт в 3x от baseline, если время исполнения ордеров спайкует — Telegram-алерт клиенту. Сложное ML-обнаружение аномалий здесь не понадобилось; rule-based пороги поймали каждую реальную проблему за первые 3 месяца работы.

Telegram-алерты. Все алерты идут в отдельный Telegram-чат с клиентом. Критические (kill switch сработал, достигнут лимит просадки, системная ошибка) — немедленно. Информационные (дневной P&L, события переподключения) — пакетно каждые 4 часа.

Результаты (анонимные данные)

После 3 месяцев live-работы:

Система исполнила 18,000+ сделок. Circuit breaker по дневной просадке сработал дважды — оба раза в периоды аномальной загруженности сети Solana, когда исполнение становилось ненадёжным. Ручной разбор обоих случаев подтвердил: circuit breaker принял правильное решение. Uptime системы: 99.7%. Средняя сквозная задержка (рыночное событие → ордер отправлен): 87мс.

Главный бенчмарк клиента — risk-adjusted доходность. Соблюдение ограничения в 3% просадки при сохранении положительного матожидания потребовало больше итераций по параметрам риска, чем по логике стратегии. Это типично. Стратегии генерировать относительно просто. Risk management который даёт им достаточно времени чтобы стать прибыльными — это настоящая сложность.