Створення алгоритму маркет-мейкінгу під ключ
Ми розробляємо алгоритми маркет-мейкінгу під ключ — від аналізу ліквідності до деплою на сервері. У крипті маркет-мейкінг залишається високодохідним для нішевих активів: mid-cap altcoins, perpetual futures з невисокою ліквідністю. При правильному налаштуванні середня денна дохідність становить 0.15–0.3% від інвентарю, а fill rate досягає 70–85%. Використовуємо Avellaneda-Stoikov model та динамічний спред, щоб мінімізувати inventory risk та максимізувати P&L.
Наша гарантія — uptime котирувань 95%+ і стійкість до інвентарних ризиків навіть за високої волатильності. Досвід 5+ років і 20+ проєктів у цій галузі.
Як ми гарантуємо стабільність?
Ми використовуємо відмовостійку архітектуру з гарячим резервуванням, моніторинг latency (<10ms) та автоматичні алерти при перевищенні risk limits. Кожен алгоритм проходить стрес-тестування на історичних даних і налаштовується під конкретний актив. Сертифіковані інженери супроводжують проект 24/7.Базова модель маркет-мейкінгу
Naive market making — виставити bid на X% нижче mid-price та ask на X% вище. Проблема: inventory risk. Якщо ціна різко рухається в один бік, маркет-мейкер накопичує невигідну позицію. Втрати можуть досягати 50% капіталу за одну сесію, якщо не керувати ризиками.
Avellaneda-Stoikov модель — математично оптимальна стратегія маркет-мейкінгу. Враховує inventory risk та time horizon:
bid_price = mid - δ/2 - γσ²(T-t)q ask_price = mid + δ/2 - γσ²(T-t)q де: δ = spread (оптимальний) γ = risk aversion coefficient σ = волатильність активу q = поточний inventory (в одиницях активу) T = кінець торгового періоду t = поточний час Ключове: при позитивному inventory (накопичено багато активу) алгоритм зсуває котирування вниз, щоб швидше продати надлишки. При негативному — піднімає, щоб купити.
Як налаштувати модель Avellaneda-Stoikov?
- Зібрати історичні дані: ціни, обсяги, спред, волатильність (σ).
- Вибрати коефіцієнт risk aversion (γ) — на практиці 0.01–0.1.
- Оптимізувати target inventory (q_target) та часовий горизонт (T).
- Запустити backtest на даних за останні 30 днів.
- Налаштувати hard/soft limits: наприклад, max inventory = 10% від капіталу.
Ми підбираємо параметри індивідуально, використовуючи генетичні алгоритми та grid search.
Як працює модель Avellaneda-Stoikov?
Модель Avellaneda-Stoikov — це стохастичний підхід, який динамічно коригує котирування на основі поточного інвентарю та часу, що залишився. Коефіцієнт γ (risk aversion) визначає, наскільки агресивно алгоритм закриватиме позицію. На практиці ми підбираємо γ на historical data, щоб балансувати між дохідністю спреду та ризиком inventory.
Які ризики інвентарю та як їх мінімізувати?
Inventory risk — головний ворог маркет-мейкера. Якщо позиція вийшла за межі допустимого діапазону, ми застосовуємо кілька методів:
- Hard limit: при inventory > MAX_INVENTORY — зупиняємо виставлення ордерів на відповідній стороні. Чекаємо виконання.
- Soft limit із skewing: поступово зміщуємо котирування проти напрямку накопиченого inventory. Чим більше inventory — тим сильніше зсув.
- Hedging: відкриваємо хедж-позицію на іншій біржі або в perpetual futures. Якщо накопичили багато BTC spot, продаємо BTC-PERP.
Для кожного проекту ми обираємо комбінацію методів на основі волатильності активу та обсягу торгів. Гарантуємо, що просадка від inventory risk не перевищує заданого порогу (зазвичай 5% від капіталу).
Управління спредом
Спред не повинен бути фіксованим — він адаптується до умов ринку:
- Volatility-based spread:
spread = base_spread × (current_volatility / mean_volatility). При високій волатильності спред розширюється — inventory risk вищий. - Order book depth: якщо ліквідність у стакані низька — ризик adverse selection вищий, спред ширший.
- Time of day: у періоди низької активності спред розширюється.
- Токсичний flow: якщо останні N угод були переважно на одній стороні — можливий informed trading. Алгоритм розширює спред або тимчасово знімає котирування.
Multi-level quotes
Замість однієї пари ордерів (1 bid + 1 ask) виставляємо кілька рівнів:
Bid 3: mid - 0.5% × 1000 USDT Bid 2: mid - 0.3% × 500 USDT Bid 1: mid - 0.15% × 200 USDT --- MID PRICE --- Ask 1: mid + 0.15% × 200 USDT Ask 2: mid + 0.3% × 500 USDT Ask 3: mid + 0.5% × 1000 USDT Ближні до mid ордери виконуються частіше та дають rebate від біржі. Дальні — страхують від різких рухів.
Order cancellation та re-quoting
Ордери потрібно регулярно оновлювати при зміні mid-price:
- Threshold-based re-quoting: якщо mid зсунувся більше ніж на N% — скасовуємо старі ордери та виставляємо нові.
- Time-based re-quoting: примусове оновлення кожні T секунд.
- Event-based: при будь-якій зміні найкращого bid/ask у стакані.
Часте скасування ордерів коштує API request quota. Біржі мають rate limits. Для Binance: 1200 requests/min HTTP, окремі ліміти для WebSocket. Важливо оптимізувати частоту оновлень.
Біржові програми маркет-мейкінгу
Великі біржі платять за надання ліквідності:
| Біржа | Програма | Умови |
|---|---|---|
| Binance | Liquidity Provider | Rebate до -0.005% |
| Bybit | Market Maker | Нульова або від'ємна maker fee |
| OKX | Market Maker | Спеціальні умови fee |
| Kraken | Market Maker | Maker rebate за заявкою |
Для отримання цих умов потрібно забезпечувати мінімальний uptime котирувань (>80% часу bid/ask у визначеному діапазоні від mid) та мінімальний обсяг.
Етапи розробки
| Етап | Тривалість | Результат |
|---|---|---|
| Аналіз ліквідності | 2–5 днів | Звіт з optimal model та risk parameters |
| Реалізація алгоритму | 2–4 тижні | Модулі pricing, order management, risk control |
| Інтеграція з біржею | 3–7 днів | Стабільне з'єднання WebSocket + REST |
| Тестування (backtest + paper) | 1–2 тижні | Звіт по sharpe, drawdown, fill rate |
| Деплой та моніторинг | 3–5 днів | Сервер з Grafana, алерти в Telegram |
Моніторинг та метрики
P&L breakdown: spread income - inventory risk losses - fees.
Fill rate: відсоток ордерів, які виконалися. Занадто низький (<50%) → занадто широкий спред. Занадто високий (>90%) → занадто вузький, багато adverse selection.
Inventory exposure: поточна позиція в USD, максимальна за сесію, середнє. Uptime: відсоток часу, коли котирування виставлені (ціль >99.5%).
Latency: час від отримання оновлення ринку до виставлення/оновлення ордерів (ціль <10ms).
Технічний стек
Мова: Python (asyncio + aiohttp/websockets) для стратегій з latency > 50ms. C++ або Rust для latency-critical компонентів.
Біржові конектори: CCXT Pro (Python) забезпечує уніфікований API для WebSocket. Для production — власні конектори для кожної біржі.
Зберігання: PostgreSQL для trades, orders, positions. InfluxDB або TimescaleDB для метрик продуктивності.
Моніторинг: Grafana дашборди для realtime P&L, inventory, latency. Алерти в Telegram при перевищенні risk limits.
Зв'яжіться з нами для оцінки вашого проєкту за 2 дні. Отримайте консультацію архітектора — обговоримо деталі.