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 — каждый из этих компонентов может сломаться в нестандартных рыночных условиях. Наша команда имеет 7+ лет опыта в DeFi и более 30 реализованных проектов, включая 5 протоколов перпетуалов.
Разработка протокола перпетуальных контрактов: с чего начать?
Первым шагом определяем архитектуру. От неё зависят требования к оракулам, газовая стоимость (до 3x разница), риски для LP и трейдеров. Ниже разбираем два основных паттерна.
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 столкнулся с этим в историческом примере: в периоды экстремальной волатильности funding rate достигал 1000% APR, рынок переставал функционировать.
Пул ликвидности как контрагент — модель GMX
GLP/GM пул держит корзину активов (ETH, BTC, USDC, USDT). Трейдер, открывающий лонг на ETH, получает прибыль за счёт пула; убыток — пул забирает. Провайдер ликвидности несёт directional risk: если трейдеры в совокупности прибыльны — LP теряет. Уязвимость: оракульный арбитраж. Решение в v2 — переход на Chainlink Low Latency Feeds с обновлением каждые несколько секунд и keeper-архитектурой для исполнения ордеров.
Что такое cumulative funding index и почему это важно?
Funding rate рассчитывается по формуле: fundingRate = (markPrice - indexPrice) / indexPrice * fundingFactor. Критическая деталь — как часто начисляется funding (по блокам или по времени?), есть ли caps, как обрабатывается накопленный funding при частичном закрытии. Cumulative funding index (как в Aave) — одна глобальная переменная globalFundingIndex, обновляемая при каждом взаимодействии; позиция хранит снапшот entryFundingIndex. Разница — накопленный funding долг или кредит. Это O(1) по газу вне зависимости от количества открытых позиций. Ошибка в этой логике — прямые потери для трейдеров или дыра в страховом фонде.
Детали реализации: пример на Solidity
// pseudocode for funding index update function _updateFundingIndex() internal { uint256 timeDelta = block.timestamp - lastFundingTimestamp; uint256 fundingAccrued = (indexPrice - markPrice) * timeDelta / 1e18; globalFundingIndex += fundingAccrued; lastFundingTimestamp = block.timestamp; } Liquidation engine
Стандартная ошибка — permissioned liquidation (только по запросу). При резком движении рынка ликвидаторы не успевают ликвидировать все underwater позиции за один блок — протокол накапливает bad debt. Правильная архитектура: ADL (Auto-Deleveraging) как последний рубеж. Если страховой фонд исчерпан (типичный размер 2–3% от TVL) — самые прибыльные позиции принудительно закрываются по mark price. Это негативный опыт, но единственный способ не допустить полного банкротства пула. dYdX v4 реализует ADL через keeper network — боты мониторят unsafe позиции и вызывают liquidation, получая reward. Подробнее об Auto-Deleveraging.
Open interest limits
Без ограничений один крупный игрок может занять позицию, превышающую весь ликвидный пул. При ликвидации рынок не сможет исполнить её без катастрофического slippage. Лимиты per-market и per-side (отдельно на лонги и шорты) обязательны.
Сравнение архитектур
| Параметр | vAMM (Perpetual Protocol) | Pool-model (GMX) |
|---|---|---|
| Контрагент | Виртуальный пул | Реальный пул LP |
| Oracle dependency | Низкая (цены по формуле) | Высокая (Chainlink) |
| Gas cost на открытие | ~80k | ~120k |
| Liquidity fragmentation | Нет | Есть (каждый пул отдельно) |
| Risk for LP | Нет | Да (directional) |
vAMM в 3 раза дешевле по газу, но не масштабируется при высокой концентрации open interest (например, >$500 млн). Pool-model требует более сложной оракульной инфраструктуры, но даёт лучшие возможности для комбинирования позиций.
Стек разработки
Для EVM-цепочек (Arbitrum, Base) — Solidity + Foundry (в 5 раз быстрее Hardhat при запуске тестов). Keeper-инфраструктура: TypeScript боты на viem/ethers.js, мониторинг через Tenderly webhooks. Рекомендуем комбинацию оракулов: Chainlink Low Latency (push-модель) и Pyth Network (pull-модель — трейдер сам предоставляет price update, снижая вектор oracle front-running). Среднее время между блоками на Arbitrum — 0.25 секунды, что позволяет выполнять ликвидации в течение 2–3 блоков.
| Компонент | Решение | Обоснование |
|---|---|---|
| Цепочка | 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%. 90% ликвидаций происходят в течение 5 секунд после движения цены — это критический параметр для настройки.
- Аудит. Code audit (reentrancy, overflow) + economic audit (стимулы). Рекомендуем Trail of Bits или Code4rena.
Чтобы обсудить детали вашего проекта, получите консультацию наших инженеров — оценим архитектуру и предложим оптимальный стек.
Типичные ошибки при разработке перпетуалов
- Использование permissioned liquidation вместо ADL — рост bad debt при резких движениях.
- Отсутствие caps на funding rate — при дисбалансе рынок перестаёт функционировать.
- Недостаточный размер страхового фонда (<2% от TVL) — при нескольких ликвидациях подряд пул может обанкротиться.
- Oracle front-running без pull-модели (Pyth) — трейдеры могут опережать обновления цены.
Что входит в работу
- Архитектурная документация с диаграммами потоков
- Полный набор смарт-контрактов с тестами (Foundry, Echidna)
- Keeper-сервисы и deployment скрипты
- Agent-based симуляция для калибровки параметров
- Интеграция с subgraph для истории позиций
- Развёртывание в mainnet/testnet с мультисигом
- Мониторинг и алертинг (Tenderly, Datadog)
- Документация для DAO governance
Ориентиры по срокам
MVP с одним рынком и базовыми ордерами — 2–3 месяца. Полноценная платформа с несколькими рынками, DAO governance, кросс-маржой — от 4 до 6 месяцев. Внешний аудит — дополнительно 4–6 недель. Стоимость рассчитывается после технического ТЗ.
Свяжитесь с нами для обсуждения вашего протокола. Закажите консультацию по архитектуре — оценим проект и предложим оптимальный паттерн.