Представьте: бот торгует по стратегии, которая идеально работала на бэктесте. Но в реальном рынке — внезапный скачок волатильности, 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 недель в зависимости от сложности. Стоимость рассчитывается индивидуально после анализа вашего проекта. Получите консультацию — обсудим ваш кейс и предложим оптимальное решение.