Розробка алгоритму funding rate арбітража
Funding rate арбітраж — одна з небагатьох стратегій у крипте з позитивним математичним очікуванням та відносно передбачуваним профілем ризику. Механіка: держиш лонг на споті та шорт на перпе одночасно. Delta нейтральна позиція, ціна не важлива. Важнив тільки funding rate — плата між лонгами та шортами на perpetual біржах. Коли ринок перегрітий та всі лонгують, шортисти отримують оплату від лонгістів. Це дохід стратегії.
Проблема в виконанні: кажуча простота скриває кілька інженерних шарів, без яких стратегія втрачає до 80% теоретичної дохідності.
Математика та ключові компоненти
Розрахунок реальної дохідності
Поверхневий розрахунок APY через funding rate обманює. Потрібно враховувати:
- Funding rate — виплачується кожні 8 годин на більшості бірж (Binance, Bybit). APY = avgFundingRate × 3 × 365 × 100%. При ставці 0.01% в 8 годин це 10.95% років до комісій.
- Borrowing rate (для маржинальної позиції на споте) — вичитається
- Trading fees (entry + exit обох позицій) — 0.04-0.1% per side
- Slippage при відкритті крупної позиції — особливо критично для неліквідних токенів
- Basis risk — різниця між споттовою та фьючерсною ціною при закритті
Для 100k USD позиції з 0.01% funding rate за 8 годин: $10 за раз, $30/день, $10,950/рік. Мінус комісії ~0.08% × 2 = $160 на вхід та вихід. Мінус borrowing rate ~5% років = $5,000. Итого реальний P&L ≈ $5,790 або ~5.8% при нейтральному funding.
Це потрібно рахувати до відкриття позиції, а не після.
Funding rate prediction
Ставка змінюється на кожній біржі незалежно. Binance perpetuals, dYdX, GMX v2, Hyperliquid — у кожного своя механіка розрахунку. На Binance: funding rate = clamp(premium index + clamp(interest rate - premium index, -0.05%, 0.05%), -0.75%, 0.75%). Premium index залежить від mark price vs. index price spread.
Для алгоритму важливо передбачати знак та приблизну величину ставки за 1-2 години до виплати. Історичні дані funding rate доступні через API всіх крупних бірж; на їх основі будується проста регресійна модель (або LSTM для складнішої логіки) на open interest + funding rate history + spot/perp spread.
def estimate_next_funding_rate(symbol: str, lookback_hours: int = 24) -> float:
"""
Оцінка наступної ставки на основі поточного premium index
та історичної волатильності ставки
"""
history = get_funding_history(symbol, lookback_hours)
current_premium = get_mark_vs_index_spread(symbol)
# Базовий розрахунок по механіці Binance
estimated_rate = clamp(
current_premium + clamp(INTEREST_RATE - current_premium, -0.0005, 0.0005),
-0.0075, 0.0075
)
# Momentum adjustment: якщо ставка росте останні N періодів
momentum = compute_momentum(history, window=3)
return estimated_rate * (1 + momentum * MOMENTUM_WEIGHT)
Інженерні деталі реалізації
Multi-exchange execution
Спот можна тримати на CEX (Binance spot) або DEX (Uniswap, через hedging з perp на dYdX або Hyperliquid). Повністю on-chain реалізація можлива: спот через Uniswap v3 позицію, перп через GMX v2 або dYdX v4 (Cosmos-based). Переважи — немає custodial risk CEX. Недостатки — gas costs + slippage вище.
Для CEX-based стратегії використовуємо REST + WebSocket APIs. Критичний момент: атомарність відкриття позицій. Якщо спот куплений, а перп з якихось причин не відкрився (нема маржи, помилка API, rate limit) — позиція стала directional. Потрібен rollback механізм.
Управління маржою та ребалансировка
Delta нейтральність нарушується при русі ціни. Якщо BTC виріс на 10%, notional стоїмість спота виросла, а перп позиція пішла в убиток по mark price. При цьому unrealized loss на перпе потребує маржу — є ризик ліквідації при різкому русі.
Рішення: dynamic rebalancing при відхиленні delta від нуля більше ніж на заданий поріг (зазвичай 1-2% від позиції). Ребалансировка стоїть комісій, тому потрібна оптимізація — не ребалансировать занадто часто.
| Параметр | Значення | Обґрунтування |
|---|---|---|
| Delta threshold | 1.5% | Нижче — занадто часті ребалансировки |
| Margin buffer | 20% від IM | Захист від ліквідації при gap down |
| Max leverage (perp) | 3x | Вище — liquidation risk росте нелінійно |
| Min funding rate | 0.005% per 8h | Нижче — не покриває комісії |
Моніторинг та алерти
- Funding rate падає нижче мінімального порогу — сигнал на закриття позиції
- Unrealized PnL на перпе наближається до margin call level — примушена часткова ребалансировка
- Exchange API недоступен — hedged halt (не торгуємо до відновлення)
- Basis різко розширився (>0.5%) — можлива аномалія на ринку, стоп-торгівля
Стек та компоненти
Python — core алгоритм, розрахунки, управління позиціями. ccxt — унівіковий інтерфейс до 100+ CEX API. PostgreSQL — зберігання історії funding rates, P&L, угод. Redis — real-time стан позицій, черги ордерів. Grafana + Prometheus — дашборд моніторингу, алерти.
Для on-chain версії: viem/ethers.js для взаємодії з GMX v2 контрактами, Foundry для тестування on-chain логіки на fork.
Процес роботи
Аналітика (3-5 днів). Вибір бірж, аналіз історичних funding rates по цільовим активам, розрахунок реальної дохідності з врахуванням всіх витрат. Якщо цифри не сходяться — чесно говоримо про це до початку розробки.
Розробка (1-2 тижні). Backtesting модуль на історичних даних, execution engine, система управління ризиками.
Бэктестинг на 12-24 місяцях даних. Перевіряємо поведінку при кризисних періодах (LUNA crash, FTX коллапс).
Paper trading (1 тиждень). Реальні market data, віртуальні позиції. Перевіряємо execution logic без ризику.
Часові орієнтири
Алгоритм для однієї пари на одній біржі — 1-2 тижні. Мульти-біржева система з динамічним управлінням портфелем та бэктестингом — 3-5 тижнів. Вартість розраховується індивідуально.