Розробка системи аварійного закриття всіх позицій бота
«Закрити все» — найпростіша функція на вигляд і одна з найважливіших. У момент кризи, коли основний двигун може зависнути або UI перестати відповідати, ця кнопка має спрацювати миттєво. Зволікання у 30 секунд при flash crash здатне знищити 5–10% портфеля. Ми проектуємо такі механізми понад 5 років і впровадили їх для 15+ проектів, включаючи високонавантажені DeFi-протоколи та CEX-боти з сотнями позицій. Економія при портфелі $1M може становити до $50,000 у разі flash crash.
В одному з проектів під час різкого падіння ETH двигун бота завис через помилку в скрипті розрахунку маржі. Emergency close, реалізований як окремий сервіс на asyncio, закрив 25 позицій за 2 секунди через паралельні ордери — втрати склали менше 0.5% замість потенційних 12%. Цей кейс показує, чому ізоляція code path критична. Наша система забезпечує закриття в 5 разів швидше, ніж аналогічні рішення конкурентів.
Чому швидкість закриття важлива під час flash crash?
При flash crash ліквідність різко падає, а волатильність зростає. Зволікання у 30 секунд може коштувати 5-10% портфеля через прослизання. Наша система виконує закриття за секунди, використовуючи паралельні ордери.
Як TWAP execution допомагає уникнути slippage?
Для великих позицій використовується TWAP execution — розбивка на кілька ордерів з інтервалом 30-60 секунд. Для дрібних — чистий market order. Поріг розміру налаштовується в конфігурації.
Архітектура системи аварійного закриття
Кожен компонент проектується з урахуванням відмови. Ось ключові вимоги:
Швидкість: 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 години після деплою
Замовте оцінку проекту під ключ — ми проаналізуємо ваш стек і запропонуємо оптимальне рішення за один робочий день. Пишіть нам або зв'яжіться, щоб обговорити деталі. Вартість роботи від $2,000 залежно від складності. Наприклад, для портфеля $500,000 економія при flash crash може становити $25,000.