Що ламається в торговому контурі без інтеграції Hummingbot
Самописний маркет-мейкер зазвичай тримає стан котирувань у пам'яті процесу. Зв'язок з біржею обірвався — робот продовжує вважати, що його заявки стоять, хоча частину вже скасовано або виконано.
Після перепідключення він виставляє їх заново: у книзі заявок з'являються дублі, позиція виходить за ліміт, який ніхто не звіряє. На тонкій книзі заявок така пара зайвих заявок сама рухає ціну, спред роз'їжджається, і наступна угода закривається помітно гірше за розрахункову.
Друга точка відмови — ручне керування ордерами. Зміну спреду, кроку сітки або меж діапазону вносять правкою файлу налаштувань і перезапуском, стан при цьому втрачається, а на час перезапуску інструмент взагалі не котирується.
Поки цим займається один інженер, будь-яка його недоступність перетворюється на діру в ліквідності: книга заявок стоїть порожньою рівно стільки, скільки триває пошук причини.
Третє — тиха відмова торгової стратегії. Робот працює, заявки виставляє, журнал чистий, але конфігурація давно не відповідає волатильності: спред занадто вузький для поточної глибини, інвентар накопичується в один бік.
Зовні це виглядає як справний бот, за фактом — як стратегія, яка повільно накопичує ризик і втрачає спред на кожному колі.
Розбираємо, як це закривається інтеграцією Hummingbot у торговий контур.
Що дає керований маркет-мейкінг: вимірюваний результат
Ручне ведення котирувань тримається на чергуванні: поки інженер не переставить ордери, спред живе за вчорашньою волатильністю. Будь-який перезапуск — це вікно, коли книга заявок порожня, і обсяг іде саме в нього.
Керований контур на Hummingbot переводить такі рішення в правила: ліміти на позицію, автоматичний перезапуск вузлів, журнал кожної дії.
Час простою торгового контуру
Вузли піднімаються як служби з перевіркою живучості та автоперезапуском, а ордери відновлюються зі збереженого стану, а не виставляються заново вручну.
Простій скорочується з годин до хвилин: частка часу, коли контур реально котирує, перестає залежати від людського фактора та часового поясу чергового.
Контроль ризику позиції
Ліміти на розмір позиції, максимальну просадку та експозицію за інструментом задаються до старту, а не за фактом. Перевищення зупиняє виставлення та закриває позицію за правилом — ризик видно в моніторингу в момент наближення до межі, а не у звіті після серії угод.
Зниження частки ручних операцій
Перестановка ордерів, зміна спреду, ребалансування та зупинка стратегії переходять у розклад і умови спрацьовування. Залишаються завдання рівня налаштування: частка ручних операцій падає на порядок, а інженерний час іде на розбір метрик, а не на чергування біля термінала.
Усі три метрики знімаються з одного контуру, тому ефект видно в динаміці: порівнюємо періоди до і після перенесення стратегій, а не покладаємося на відчуття від торгової сесії.
Варіанти інтеграції Hummingbot: хмара, власний сервер, гібрид
Де живе торговий бот, важливіше, ніж здається: від цього залежать затримка до біржі, доступ до приватних ключів і те, як швидко стратегія вийде на реальний ринок. Hummingbot — відкритий рушій маркет-мейкінгу, і розгорнути його можна трьома схемами. Кожна по-своєму торгує контролем проти швидкості старту.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Хмарний запуск | Потрібен старт у короткий строк, власного заліза немає, стратегія вже відлагоджена | Ключі лежать у провайдера, затримка до біржі вища, тонке налаштування мережі недоступне |
| Розгортання на власному сервері | Потрібен повний контроль над ключами та логами, стратегія чутлива до затримки | Налаштування середовища, моніторинг і оновлення залишаються на вашому боці, старт довший |
| Гібридна схема розміщення | Торговий контур на власному залізі, перевірка стратегій на історії — у хмарі | Два контури потрібно зв'язувати, синхронізувати конфігурації та версії стратегії |
Обмеження біржового інтерфейсу однакові для всіх трьох схем і часто вирішують вибір.
Ліміти на частоту запитів і вагу заявок не дають виставляти котирування занадто часто, частина типів ордерів доступна лише на окремих ринках, а тестовий контур не повторює реальну глибину книги заявок — на живому ринку поведінка стратегії відрізняється.
Розгортання на власному сервері беруть там, де важливі приватні ключі та передбачувана затримка: контейнер із ботом, окремий вузол доступу до біржі, власні логи й оповіщення про збої.
Хмарний запуск виграє на етапі перевірки гіпотез — задали параметри стратегії та подивилися поведінку на живій книзі заявок. Гібрид закриває обидва сценарії, але потребує дисципліни в конфігураціях: розійшлися версії стратегії на контурах дають розбіжність у звітах.
Порядок робіт: від аудиту торгової логіки до запуску
Роботи з інтеграції Hummingbot ідуть від аудиту торгової логіки до передачі в експлуатацію, і кожен етап закривається артефактом, який можна перевірити, а не усним «готово».
Порядок порушувати не варто: стратегія, зібрана до інвентаризації підключень і біржових лімітів, зазвичай упирається в них уже на живому рахунку.
- Аудит торгової логіки та поточного контуру. Дивимося правила входу й виходу, спосіб обліку позиції, джерела котирувань, те, як виставляються та знімаються заявки. На виході — карта вузьких місць: де логіка тримається на ручних діях і де можливі дублі ордерів.
- Схема та цільові параметри. Фіксуємо пари, розмір спреду, крок перестановки заявок, ліміти на позицію та на кількість активних ордерів, поведінку при обриві зв'язку з біржею. Це специфікація, за якою збирається конфігурація.
- Складання стратегії та підключень. Готуємо конфігураційні файли, ключі доступу заводимо з мінімально необхідними правами, без виведення коштів, окремо задаємо обмеження за частотою запитів до біржі.
- Перевірка на історичних даних. Прогонимо логіку на записаних рядах котирувань і книги заявок: дивимося просадку, частку скасованих заявок, поведінку на пропущених свічках і на тонкому ринку.
- Тестовий контур малим обсягом. Дублюємо прогін на біржовому тестовому середовищі або на мінімальному реальному обсязі, звіряючи фактичні виконання з розрахунковими.
- Передача в експлуатацію. Віддаємо конфігурації, опис стратегій, журнали прогонів і регламент: як змінювати параметри, як зупиняти бота і як відкочуватися на попередню версію стратегії.
Що залишається в команди: конфігурації, схеми, регламенти
Після інтеграції Hummingbot команда залишається не з «чорною скринькою», а з набором артефактів, за якими контур можна розвивати, передати іншому інженеру або відновити після збою. Нижче — мінімальний склад, який ми закриваємо на кожному проєкті маркет-мейкінгу.
- Конфігурації стратегій — робочі файли параметрів: спреди, розміри та глибина котирувань, ліміти позиції, інтервали перерахунку, а поруч журнал правок із поясненням, яка зміна до якої поведінки призвела.
- Схема торгового контуру — потоки котирувань та ордерів за вузлами, точки відмови, поведінка при обриві зв'язку з біржею та порядок перезапуску без ручної правки параметрів.
- Матриця доступів — хто і з яких адрес змінює параметри, хто бачить лише показники, як видаються, ротуються та відкликаються ключі при виході інженера.
- Регламент реагування на збої — що вважаємо інцидентом, хто і як зупиняє стратегію, як відкотитися на попередній набір параметрів і за який час.
- Пакет документації — логіка стратегії, інструкція запуску з нуля, порядок виведення з експлуатації, історія змін і ухвалених рішень.
- Набір показників і порогів — за якими значеннями видно, що стратегія відходить від очікуваної поведінки, і коли потрібен ручний розбір.
Кожен артефакт ми віддаємо з перевіркою на сторонньому інженері: якщо за ним не можна підняти контур без нас — він написаний недостатньо.
Практика: як пішов клас відмов на волатильному ринку
Маркет-мейкер на кількох біржах переходив у ручний режим при кожному сплеску волатильності: котирування розходилися з еталонним спредом, частина заявок зависала між відправленням і підтвердженням, а розрив зв'язку з біржею залишав відкриті позиції без нагляду.
На різких рухах розходження сягало кількох відсотків від цільового спреду, до десятої частини заявок зависало, а відновлення контуру займало 20–30 хвилин ручного розбору.
Що змінили
В основі залишилася стратегія на Hummingbot, але стан позиції перестав жити лише всередині торгової логіки.
З'явився незалежний облік зі звіркою з біржею при кожному перепідключенні, а кожна заявка отримала клієнтський ідентифікатор: повторне відправлення після обриву більше не створює дублів і не подвоює позицію.
Окремо закрили котирування за застарілою книгою заявок: при виході ринку за заданий коридор стратегія знімає заявки й іде в паузу замість того, щоб виставлятися за невірною ціною.
Перепідключення йде з наростаючою паузою, а при втраті зв'язку контур спочатку знімає заявки і лише потім відновлюється.
Що стало
Частка завислих заявок упала з десятої частини до часток відсотка, розходження котирувань повернулося в межі цільового спреду, а відновлення контуру після розриву зв'язку займає менше хвилини й іде автоматично.
Ручних втручань за період спостереження — нуль: клас відмов «котируємо за застарілою ціною після обриву» пішов разом із ручними розборами.
У контурі з'явилися метрики, за якими деградація видна до втрати грошей: розходження спреду, частка завислих заявок, час відновлення після обриву зв'язку.
Чим маркет-мейкінг на біржі відрізняється від арбітражу?
Маркет-мейкінг — це котирування: стратегія тримає заявки з обох боків книги заявок і заробляє на спреді та винагороді за ліквідність. Арбітраж знімає розходження: той самий актив купується на одному майданчику й одразу продається на іншому.
Спільний у режимів лише шар доступу до бірж — далі це різні за навантаженням, ризиком і вимогами контури.
| Вісь | Маркет-мейкінг | Арбітраж |
|---|---|---|
| Джерело результату | Спред і винагорода за ліквідність | Різниця цін між майданчиками |
| Ризик напрямку позиції | Високий: інвентар накопичується проти руху | Низький: позиція закривається зустрічною ногою |
| Вимоги до швидкості | Безперервність котирування | Пікова реакція в короткому вікні |
| Навантаження на контур | Рівний потік заявок і скасувань | Рідкісні сплески при появі розходження |
| Коли вибирають | Потрібна постійна ліквідність і оборот | Майданчики дають стійку різницю цін |
Ризик напрямку позиції — головний вододіл. Маркет-мейкер тримає інвентар постійно, тому на тренді накопичує актив проти руху; його захищають ліміти на позицію, хеджувальні заявки та виведення котирувань із небезпечної зони.
Арбітраж майже не тримає позицію, зате потребує одночасного виконання двох ніг: затримка на одному майданчику перетворює угоду на направлену.
Швидкість реакції теж різного характеру. Маркет-мейкеру важливіша безперервність — розрив у котируванні видно за оборотом і за втраченими угодами. Арбітражу потрібна пікова реакція у вузькому вікні, тому його контур простоює й чекає сплеску.
Арбітраж вибирають там, де ліквідність рознесена по майданчиках, а розходження повторюються передбачувано.
У Hummingbot обидва режими збираються поверх спільного шару підключень до бірж, тому вибір торгової стратегії — це питання конфігурації та ризик-лімітів, а не переписування інтеграції.
Технічні питання, які задають перед стартом
Перед стартом інженерні команди запитують не «чи працює», а про стійкість: що буде при обриві зв'язку з біржею, як не задвоїти ордери при перепідключенні, як укластися в ліміти запитів і де лежать ключі доступу. Нижче — відповіді в тому вигляді, як ці місця вирішуються в нашій реалізації.
Що станеться з ордерами при обриві зв'язку з біржею?
Після кожного розриву конектор звіряє фактичний стан: відкриті заявки та баланси підтягуються з біржі, і стратегія продовжує роботу від них, а не від останнього запису в пам'яті.
Кожному ордеру присвоюється ідентифікатор на нашому боці, зіставлений з біржовим, тому перед виставленням перевіряється, чи немає вже активної заявки за цією парою та стороною. При таймауті замість підтвердження запит не повторюється наосліп — спочатку запитується стан рахунку.
Як укластися в ліміти запитів біржі?
Ліміти враховуються на рівні конектора: черга запитів і обмеження частоти на кожен метод із запасом під пікове навантаження.
При наближенні до порогу стратегія знижує частоту перерахунку — блокування з боку біржі відсікає всі запити одразу, включно з тими, що потрібні для скасування ордерів.
Де зберігаються ключі доступу до рахунку?
Ключі лежать у захищеному сховищі й потрапляють у процес лише при запуску, через змінні середовища; у конфігурації та логах їх немає.
Права API обмежуються торгівлею без виведення коштів, а доступ до сховища видається роллю на боці інфраструктури, а не загальним файлом на сервері.
Чи можна перевірити стратегію до реального рахунку?
Прогін іде в три кроки: історичні дані, тестовий контур біржі з реальними затримками та відповідями, потім рахунок із мінімальним обсягом.
На кожному кроці звіряються спред, частка виконаних заявок, кількість скасувань і максимальна просадка за позицією — за ними видно, чи поводиться стратегія так, як задумано.
Обговоримо задачу: надішлемо схему, оцінку та план робіт
Щоб повернутися з оцінкою та планом, а не із загальними формулюваннями, нам потрібно розібрати поточний контур: де запускаються боти, які біржі та пари підключені, як влаштовані ключі, ліміти й логування угод, які метрики вже збираються.
Для цього достатньо короткого дзвінка та доступу до конфігурацій — далі схему описуємо ми. Нижче — порядок, за яким іде робота; він же стає змістом плану.
- Розбір контуру: поточні стратегії, способи виставлення заявок, частота переоцінки, обробка обривів зв'язку та вже накопичена статистика виконання.
- Схема інтеграції: як Hummingbot стає поруч із вашими біржами та обліковими системами, де проходять ключі, які ліміти та запобіжники обмежують обсяг позиції.
- Оцінка строків: етапи з точками, на яких можна зупинитися або змінити пріоритети, і явні залежності від зовнішніх погоджень.
- Пілотний запуск: обмежена пара та невеликий обсяг, звірка фактичних угод з очікуваними, перевірка поведінки при відмовах і частковому виконанні.
- Кастомні стратегії: правила входу й виходу, параметри ризику, логіка скасування та перестановки заявок, тести на історичних даних.
- Супровід торгового контуру: моніторинг, розбір інцидентів, коригування параметрів при зміні ліквідності та оновленнях на боці біржі.
- Передача: конфігурації, документація щодо запуску та відновлення, інструкції для вашої команди.
Опишіть задачу в двох-трьох реченнях — за цими пунктами повернемося з оцінкою строків і планом робіт.
