Разработка протокола перпетуальных контрактов
dYdX v3 обрабатывал $10 млрд дневного объёма на централизованном order book с on-chain settlement. GMX v2 идёт другим путём: провайдеры ликвидности несут риск через GM-пулы, трейдеры торгуют против этого пула, оракульная цена Chainlink Low Latency определяет PnL. Оба подхода работают — но ломаются по-разному, и выбор архитектуры определяет всё остальное.
Perpetuals-протокол — самый технически сложный тип DeFi. Funding rate, mark price, index price, open interest limits, liquidation engine, insurance fund — каждый из этих компонентов имеет способ сломаться в нестандартных рыночных условиях.
Два архитектурных паттерна и где каждый падает
Virtual AMM (vAMM) — модель Perpetual Protocol
vAMM использует формулу xy=k для определения цены без реального пула ликвидности. Трейдер открывает long на 10 ETH — виртуальный резерв ETH уменьшается, USDC увеличивается, цена растёт. Проблема в том, что при сильном дисбалансе open interest (все лонгуют) mark price расходится с index price. Funding rate должен выровнять это, но если расхождение слишком большое — funding rate становится экономически невыносимым и трейдеры просто закрывают позиции.
Perpetual Protocol v1 столкнулся именно с этим в 2021: в периоды экстремальной волатильности funding rate достигал 1000% APR, рынок переставал функционировать.
Пул ликвидности как контрагент — модель GMX
GLP/GM пул держит корзину активов (ETH, BTC, USDC, USDT). Трейдер, открывающий лонг на ETH, получает прибыль за счёт пула, убыток — пул забирает. Провайдер ликвидности несёт directional risk: если трейдеры в совокупности прибыльны — LP теряет.
Уязвимость: оракульный арбитраж. Если Chainlink feed обновляется медленнее, чем движется рынок на CEX — арбитражер открывает позицию по устаревшей цене, гарантированно профитит. GMX v1 терял на этом миллионы, решение в v2 — переход на Chainlink Low Latency Feeds с обновлением каждые несколько секунд и keeper-архитектурой для исполнения ордеров.
Ключевые механики, требующие аккуратной реализации
Funding rate
Цель funding rate — удерживать mark price около index price. Базовая формула:
fundingRate = (markPrice - indexPrice) / indexPrice * fundingFactor
Но дьявол в деталях: как часто начисляется funding (по блокам или по времени?), есть ли caps на максимальный rate, как обрабатывается накопленный funding при частичном закрытии позиции. Ошибка в логике начисления — прямые потери для трейдеров или дыра в страховом фонде.
Используем паттерн cumulative funding index (аналогично Aave's cumulative interest index): одна глобальная переменная globalFundingIndex обновляется при каждом взаимодействии, позиция хранит снапшот entryFundingIndex, разница — накопленный funding долг или кредит. Это O(1) по газу вне зависимости от количества открытых позиций.
Liquidation engine
Стандартная ошибка — liquidation происходит только по запросу (permissioned liquidation). При резком движении рынка ликвидаторы физически не успевают ликвидировать все underwater позиции за один блок. Протокол накапливает bad debt.
Правильная архитектура: ADL (Auto-Deleveraging) как последний рубеж. Если страховой фонд исчерпан — самые прибыльные позиции принудительно закрываются по mark price, чтобы покрыть bad debt убыточных. Это негативный опыт для прибыльных трейдеров, но это единственный способ не допустить полного банкротства пула.
dYdX v4 реализует ADL через keeper network — боты мониторят unsafe позиции и вызывают liquidation/ADL транзакции, получая reward из страхового фонда.
Open interest limits
Без ограничений open interest один крупный игрок может занять позицию, которая превышает весь ликвидный пул. При ликвидации рынок не сможет исполнить её без катастрофического slippage. Лимиты per-market и per-side (отдельно на лонги и шорты) обязательны.
Стек разработки
Для EVM-цепочек (Arbitrum, Optimism, Base) — Solidity + Foundry. Arbitrum особенно популярен для perps: низкий газ критичен, когда каждое обновление позиции стоит денег.
Keeper-инфраструктура: TypeScript боты на viem/ethers.js, мониторинг через Tenderly webhooks или собственный event indexer. OpenZeppelin Defender Autotasks для автоматических операций с multisig.
Ценовые данные: Chainlink Low Latency (push-модель для критичных операций), Pyth Network (pull-модель, трейдер сам предоставляет price update в транзакции — это снижает вектор oracle front-running).
| Компонент | Решение | Обоснование |
|---|---|---|
| Цепочка | Arbitrum One / Base | Низкий газ, высокая ликвидность |
| Oracle | Chainlink + Pyth | Разные модели обновления |
| Keeper | OpenZeppelin Defender | Managed execution |
| Субграф | The Graph | История позиций, PnL |
| Тесты | Foundry + Echidna | Fuzz + property tests |
Процесс разработки
Математическая спецификация (1 неделя). Формулы funding rate, margin requirements, liquidation price, mark price расчёт — всё формализуется до кода. Ошибка в формуле, найденная в спецификации, стоит часа работы. В продакшне — миллионы.
Разработка core контрактов (4-8 недель). Position manager, funding engine, liquidation engine, oracle module — разрабатываются и тестируются изолированно, затем интегрируются. Fork-тесты на mainnet с реальными Chainlink feeds.
Keeper инфраструктура (2-3 недели). TypeScript боты, мониторинг, alerting, fallback логика при downtime нод.
Параметризация и симуляция (1-2 недели). Agent-based симуляция: виртуальные трейдеры с разными стратегиями, стресс-тесты при волатильности ±50% за час. Параметры (funding factor, max OI, liquidation bonus) калибруются по результатам.
Аудит. Perpetuals-протоколы требуют аудит от специализированных фирм — финансовая математика и смарт-контракты одновременно. Отдельно рекомендуем economic audit (моделирование атак через стимулы) параллельно с code audit.
Ориентиры по срокам
MVP perpetuals-протокол (один рынок, базовые ордера) — 2-3 месяца. Полноценная платформа с несколькими рынками, DAO governance, кросс-маржой — от 4 до 6 месяцев. Время на внешний аудит — дополнительно 4-6 недель.
Стоимость рассчитывается после технического ТЗ.