Разработка системы аварийного закрытия всех позиций бота
«Закрыть всё» — самая простая функция с виду и одна из самых важных. В момент кризиса, когда основной движок может зависнуть или UI перестать отвечать, эта кнопка должна сработать мгновенно. Промедление в 30 секунд при flash crash способно уничтожить 5–10% портфеля. Мы проектируем такие механизмы более 5 лет и внедрили их для 15+ проектов, включая высоконагруженные DeFi-протоколы и CEX-боты с сотнями позиций.
В одном из проектов во время резкого падения ETH движок бота завис из-за ошибки в скрипте расчёта маржи. Emergency close, реализованный как отдельный сервис на asyncio, закрыл 25 позиций за 2 секунды через параллельные ордера — потери составили менее 0.5% вместо потенциальных 12%. Этот кейс показывает, почему изоляция code path критична.
Как мы строим систему аварийного закрытия?
Каждый компонент проектируется с учётом отказа. Вот ключевые требования:
Скорость: emergency close должен завершаться за секунды, не минуты. Достигается параллельным закрытием всех позиций одновременно через asyncio.gather, а не последовательным циклом.
Надёжность: работает даже если основной торговый цикл завис или UI недоступен. Это отдельный, максимально простой code path без зависимостей от основного engine — только HTTP-клиент к бирже.
Подтверждение: каждая позиция должна быть подтверждена как закрытая. Если ордер не исполнился — повтор с exponential backoff. Не останавливаться, пока все позиции не закрыты или не достигнут timeout с алертом в Telegram.
Идемпотентность: если кнопка нажата дважды — не отправляем двойные ордера. Используем Redis для хранения состояния операции: при повторном вызове проверяем, active close уже идёт, и возвращаем текущий статус.
Алгоритм исполнения
1. Получить список всех открытых позиций (REST snapshot) 2. Для каждой позиции параллельно: a. Разместить market order противоположной стороны b. Подождать confirmation fill c. Если timeout — проверить статус, повторить при необходимости 3. Через N секунд сделать reconciliation: - Запросить текущие позиции с биржи - Если что-то осталось открытым — повторить для них 4. Отправить итоговый отчёт: что закрыто, по каким ценам, итоговый P&L Проблема ликвидности при экстренном закрытии
Экстренное закрытие обычно происходит в моменты высокой волатильности — именно тогда ликвидность снижается. Market order на большую позицию может дать катастрофический slippage. Решение: для крупных позиций — TWAP execution даже при emergency (разбить на несколько ордеров за 30–60 секунд). Для небольших — чистый market order. Пороговый размер настраивается в конфигурации.
Сравнение TWAP и прямого Market order
| Параметр | TWAP execution | Market order |
|---|---|---|
| Время закрытия крупной позиции | 30–60 секунд | <1 секунды |
| Риск slippage | Минимальный (≤1%) | Высокий (до 5–15%) |
| Надёжность при нулевой ликвидности | Высокая (ордера частично исполняются) | Низкая (может не исполниться) |
| Рекомендуемый размер позиции | >$10k | <$10k |
Что делать, если ликвидность упала до нуля?
В таких случаях чистый market order может исполниться по худшей цене стакана. Мы добавляем fallback: если спред превышает 5%, система переключается на лимитный ордер с агрессивной ценой (лучший bid/ask) и повторяет попытку каждые 2 секунды. Это защищает от проскальзывания при сохранении шанса закрыть позицию.
Сравнение подходов к выполнению emergency close
| Параметр | Последовательное закрытие | Параллельное закрытие |
|---|---|---|
| Время выполнения | ~10–30 секунд | ~1–3 секунды |
| Риск slippage | Выше из-за задержек | Ниже благодаря синхронности |
| Надёжность | Зависит от последовательности | Выше, каждый ордер независим |
| Сложность реализации | Низкая | Средняя (требует асинхронности) |
Параллельное закрытие в 3–5 раз быстрее последовательного при 10+ позициях.
Почему важно тестировать emergency close регулярно?
Система аварийного закрытия — это safety feature, которая нужна редко, но должна работать безотказно когда нужна. Регулярно тестируйте её в paper trading режиме с симуляцией flash crash. Мы включаем в поставку автоматизированные тесты, использующие исторические данные кризисов и эмуляцию network issues. Гарантируем, что после нашего внедрения вы сможете спать спокойно.
Процесс внедрения
| Этап | Длительность | Результат |
|---|---|---|
| Анализ архитектуры бота | 1–2 дня | Техническое задание и оценка |
| Проектирование code path | 1 день | Документ с алгоритмом и fallback |
| Разработка на Python (asyncio) или Solidity | 3–5 дней | Готовый модуль emergency close |
| Интеграция с биржей и настройка TWAP | 1–2 дня | Рабочий прототип |
| Тестирование на исторических данных | 2 дня | Отчёт с симуляциями |
| Деплой и двухчасовая поддержка | 1 день | Система в production |
Что входит в работу?
- Полная архитектура и код emergency close (отдельный сервис или integrated module)
- Реализация parallel execution с asyncio/aiohttp или аналогичным стеком
- Настройка TWAP execution для крупных позиций
- Reconciliation и алерты при сбоях
- Документация (описание алгоритма, конфигурация, инструкция по тестированию)
- Поддержка 2 часа после деплоя
Закажите оценку проекта — мы проанализируем ваш стек и предложим оптимальное решение за один рабочий день. Свяжитесь с нами, чтобы обсудить детали.