Уявіть: бот торгує за стратегією, яка ідеально працювала на бектесті. Але в реальному ринку — раптовий стрибок волатильності, slippage вищий за розрахунковий, і одна угода йде в мінус на 30% рахунку. Без лімітів це катастрофа. З правильно налаштованими guardrails — це контрольований збиток, який не ламає стратегію. У DeFi-середовищі додаються ризики oracle-маніпуляцій (наприклад, Chainlink) та flash loan атак — ліміти захищають від них. Зв'яжіться з нами, щоб обговорити ваш випадок.
Ми проектуємо системи лімітів, які працюють на рівні ядра торгового бота — перевіряють кожен ордер до його відправки на біржу. За час роботи реалізували лімітні модулі для 30+ проектів: від спот-ботів на Binance до складних DeFi-стратегій на Ethereum та Solana. Ось як влаштована така система і що важливо врахувати.
Які види лімітів потрібні боту?
Позиційні ліміти
- Max position size per instrument: максимальний розмір позиції за одним інструментом. Може бути абсолютним (0.5 BTC) або відносним (5% від портфеля).
- Max total exposure: сумарна експозиція за всіма відкритими позиціями. Обмежує загальний leverage — часто використовується разом з margin requirements.
- Max positions count: кількість одночасно відкритих позицій. Захист від стратегії, яка починає відкривати позиції у всіх інструментах одразу.
- Concentration limit: максимальна частка капіталу в одному активі. Якщо три різні позиції корелюють з BTC — їх сумарна вага не повинна перевищувати X%.
Збитки та P&L ліміти
- Max daily loss: максимальний збиток за торговий день. При досягненні — зупинка до наступного дня. Професійні трейдери ставлять 2-5% від рахунку.
- Max weekly/monthly loss: аналогічно для довших періодів.
- Max drawdown: максимальна просадка від історичного піку. При досягненні — пауза та рев'ю стратегії.
- Per-trade max loss: максимальний збиток за одну угоду. Якщо стоп-лос не спрацював — примусове закриття.
Операційні ліміти
- Max orders per minute: захист від випадкового flood біржового API.
- Max order size: максимальний розмір одного ордера (захист від помилки в розрахунку розміру позиції).
Приклад розрахунку динамічного ліміту
При високому ATR розмір позиції автоматично зменшується, щоб зберегти однаковий expected dollar risk. Це запобігає надмірним втратам у періоди високої волатильності та захищає від несподіваних просадок.
Чому pre-trade validation критична?
Перевірки лімітів мають виконуватися до відправки ордера, а не після. В іншому випадку збиток вже відбувся. Ми реалізуємо синхронну pre-trade валідацію в тому ж потоці, що й генерація сигналу:
def validate_order(order, portfolio_state, limits): # Check position size current_pos = portfolio_state.get_position(order.symbol) new_pos_size = current_pos.size + order.quantity if new_pos_size > limits.max_position_size[order.symbol]: raise LimitViolation("MAX_POSITION_SIZE", ...) # Check daily loss if portfolio_state.daily_pnl < -limits.max_daily_loss: raise LimitViolation("DAILY_LOSS_LIMIT", ...) # Check total exposure new_exposure = portfolio_state.total_exposure + order.notional_value if new_exposure > limits.max_total_exposure: raise LimitViolation("MAX_EXPOSURE", ...) return True Pre-trade validation виконується за <1 мс і гарантує, що жоден ордер, який порушує ліміти, не буде відправлено. У високочастотній торгівлі це критично, щоб уникнути втрат через MEV або несподіваного руху ціни.
Динамічні ліміти vs статичні: наскільки це ефективно?
Статичні ліміти — добре, але ринок змінюється. Динамічні ліміти адаптуються до умов: при високому VIX або ATR розмір позицій автоматично зменшується. Це зберігає однаковий expected dollar risk. В години низької ліквідності (ніч за Asian session) ліміти знижуються. А при зростанні просадки ми поступово зменшуємо ліміти за принципом Kelly criterion: чим менший капітал, тим менші абсолютні ставки.
Порівняння на історичних даних за останній рік показує: динамічні ліміти зменшують максимальну просадку майже вдвічі порівняно зі статичними при тій же сумарній дохідності. Ось типові налаштування для різних режимів:
| Режим ринку | Max position (BTC) | Max daily loss ($) | Max exposure ($) |
|---|---|---|---|
| Низька волатильність | 1.0 | 5,000 | 50,000 |
| Середня волатильність | 0.7 | 3,000 | 35,000 |
| Висока волатильність | 0.4 | 1,500 | 20,000 |
| Криза (VIX > 40) | 0.2 | 500 | 10,000 |
Такий підхід дає боту більше гнучкості: він не пропускає прибуткові тренди, але захищений в кризу.
Моніторинг та алертинг за лімітами
Оператор повинен бачити поточне завантаження лімітів у реальному часі. Ми надаємо дашборд з таблицею:
| Ліміт | Максимум | Поточне | % використання |
|---|---|---|---|
| Daily loss | $5,000 | $1,230 | 24.6% |
| Max exposure | $50,000 | $31,500 | 63.0% |
| BTC position | 1.0 BTC | 0.45 BTC | 45.0% |
При досягненні 80% ліміту — попередження. При досягненні 100% — дія (пауза/зупинка) та алерт у Telegram/Slack.
Приклад реалізації динамічного ліміту на основі ATR:
def get_dynamic_max_position(portfolio, symbol, limits, atr): base_position = limits.max_position_size[symbol] atr_factor = min(1.0, limits.base_atr / (atr if atr > 0 else 1)) return base_position * atr_factor * (portfolio.equity / limits.initial_equity) Тут ліміт залежить від поточної волатильності (ATR) і знижується при просадці капіталу.
Що входить у розробку системи лімітів
- Документація: специфікація лімітів, опис поведінки при спрацюванні, інструкція для оператора.
- Вихідний код: модуль валідації, адаптери під вашу інфраструктуру (CEX/DeFi), приклади конфігурації.
- Тестування: unit-тести, інтеграційні тести, навантажувальне тестування (до 1000 ордерів/сек).
- Моніторинг та алертинг: готові метрики для Prometheus/Grafana, інтеграція з Telegram/Slack.
- Навчання: сесія для вашої команди з налаштування та експлуатації системи.
- Підтримка: 3 місяці супроводу з реакцією до 4 годин.
Як ми розробляємо систему лімітів під ключ
Процес включає п'ять етапів:
- Аналіз стратегії: розбираємо логіку бота, типові ризики, історичні просадки.
- Проектування схеми лімітів: вибираємо набір лімітів, визначаємо пороги, вирішуємо, які будуть динамічними.
- Реалізація модуля: пишемо код на Solidity (для DeFi) або Python/Node.js (для CEX), впроваджуємо pre-trade та post-trade перевірки.
- Інтеграція та тестування: підключаємо моніторинг, алертинг, проводимо навантажувальне тестування та формальний аудит (Slither, Mythril).
- Деплой та супровід: розгортаємо систему, навчаємо операторів, надаємо підтримку на 3 місяці.
Терміни розробки — від 2 до 4 тижнів залежно від складності. Вартість розраховується індивідуально після аналізу вашого проекту. Отримайте консультацію — обговоримо ваш кейс і запропонуємо оптимальне рішення.