Взявшись за разработку первого протокола перпетуалов для клиента, мы сразу столкнулись с проектированием устойчивой к манипуляциям системы ликвидации. Стандартный механизм с полным закрытием позиции при health factor < 1 на высоковолатильных рынках генерировал bad debt в 3.8% от объёма. На внутреннем хакатоне мы переписали core liquidation engine четыре раза, прежде чем нашли рабочую конфигурацию partial liquidation + dynamic fee. Это честный индикатор сложности задачи: разработка on-chain протокола деривативов — это не надстройка над AMM, а отдельная финансовая система с десятками взаимосвязанных компонентов. Наша команда имеет 5+ лет опыта в DeFi и реализовала более 10 протоколов с совокупным TVL свыше $180M. Гарантируем качество кода и прохождение внешнего аудита. Благодаря оптимизации газовых расходов, наши клиенты экономят до $150 000 на транзакционных издержках в год.
Классификация on-chain деривативов
Прежде чем писать первую строчку кода, нужно точно определить тип инструмента. Контракты для разных классов деривативов не имеют общего кода кроме базовых утилит.
| Тип | Примеры | Ключевая механика | Сложность |
|---|---|---|---|
| Perpetual futures | GMX, dYdX, Gains | Funding rate, mark price, liquidation | Высокая |
| Options | Lyra, Dopex, Premia | Greeks, IV модель, exercise | Очень высокая |
| Structured products | Ribbon Finance | Vault стратегии, rolling | Средняя |
| Prediction markets | Polymarket | Binary settlement, оракул | Средняя |
| Синтетические активы | Synthetix | Debt pool, oracle debt, SNX стейкинг | Высокая |
Дальше сосредоточимся на perpetual futures — самом востребованном типе.
Почему perpetual futures требуют сложного движка ликвидации?
Funding rate — сердце перпетуала
Perpetual futures on Wikipedia не имеют экспирации. Вместо конвергенции к спотовой цене через дату экспирации перпетуал поддерживает привязку через funding rate — периодические платежи между лонгами и шортами.
Стандартная формула: fundingRate = clamp(premium / fundingInterval, -maxRate, maxRate), где premium = (markPrice - indexPrice) / indexPrice.
Проблема в том, что mark price на слаболиквидных рынках легко манипулируема. GMX v1 использовал чистый Chainlink price feed как mark price — это позволяло атакующим открывать позиции прямо перед манипулированным апдейтом оракула и закрывать после. GMX потерял на этом несколько миллионов долларов до введения position impact fee.
Решение, которое мы используем: mark price = TWAP по последним X минутам торгов на самом протоколе (если объём достаточный) с fallback на median из трёх оракулов (Chainlink, Pyth, Redstone). Манипуляция становится дорогой: нужно двигать и торговый объём на протоколе, и несколько внешних оракулов одновременно.
Liquidation engine и partial liquidation
Классический подход — liquidation при health factor < 1 с немедленным закрытием всей позиции. Ликвидатор получает liquidation fee (обычно 0.5–1%). Проблема: на волатильном рынке позиция может уйти глубоко в минус быстрее, чем ликвидатор успеет среагировать. Результат — bad debt, который покрывает insurance fund. Средняя ликвидация обходится в ~2000 gas, что при цене газа 50 gwei составляет около $0.02, но при высокой волатильности ликвидаторы платят премию до $0.5.
Более продвинутый подход — partial liquidation: при достижении warning threshold (например, margin ratio < 5%) позиция частично принудительно уменьшается до восстановления margin ratio. Полная ликвидация только при полном исчерпании маржи.
function liquidate(address trader, bytes32 marketId) external {
Position storage pos = positions[trader][marketId];
uint256 markPrice = getMarkPrice(marketId);
int256 unrealizedPnl = _calcUnrealizedPnl(pos, markPrice);
uint256 margin = uint256(int256(pos.collateral) + unrealizedPnl);
uint256 maintenanceMargin = _getMaintenanceMargin(pos, markPrice);
require(margin < maintenanceMargin, "Position healthy");
// Частичная ликвидация если возможно
uint256 reduceAmount = _calcPartialLiquidationSize(pos, margin, maintenanceMargin);
_reducePosition(trader, marketId, reduceAmount, markPrice);
uint256 liquidationFee = reduceAmount * liquidationFeeRate / 1e18;
_transferFee(msg.sender, liquidationFee);
}
Cross-margin vs isolated margin
Cross-margin: весь баланс пользователя — общая маржа для всех позиций. Позиция на ETH помогает выжить позиции на BTC при локальном просадке. Риск — одна убыточная позиция может ликвидировать весь аккаунт.
Isolated margin: каждая позиция изолирована. Максимальный убыток ограничен выделенной маржой. Более безопасно для пользователя, сложнее для реализации: нужно per-position accounting в storage.
Для большинства клиентских протоколов мы реализуем изолированный margin как режим по умолчанию с опциональным cross-margin для продвинутых пользователей.
Архитектура: AMM vs Virtual AMM vs Orderbook
vAMM (virtual AMM) — подход Perpetual Protocol. Реальной ликвидности нет, цена определяется формулой x*y=k на виртуальных резервах. Liquidity providers не нужны для базовой работы. Минус: высокое slippage при крупных позициях (до 2% для позиции $500k), funding rate не всегда отражает реальный рынок.
Global liquidity pool — подход GMX. LP депонируют корзину активов (GLP/GM), становятся контрагентами для всех трейдеров. Если трейдеры в среднем теряют — LP зарабатывают (средняя доходность 15-20% годовых). Работает хорошо на стабильных рынках, но LP несут asymmetric risk: при массовых прибыльных позициях GLP теряет стоимость.
Hybrid orderbook + AMM — наиболее сложный, наиболее близкий к CEX UX. Off-chain матчинг (через dedicated sequencer или off-chain orderbook) с on-chain settlement. Такую архитектуру использует Hyperliquid.
Как мы защищаем протокол от оракульных манипуляций?
Деривативный протокол — самый demanding потребитель оракулов в DeFi. Требования:
- Latency: Chainlink апдейт раз в несколько блоков недостаточен для активной торговли. Pyth Network предоставляет sub-second updates через pull-оракул: данные публикуются off-chain, on-chain обновление инициирует пользователь транзакцией с proof.
- Multi-asset: для каждого рынка нужен отдельный price feed. Redstone предоставляет гибкую систему с кастомными агрегаторами.
- Manipulation resistance: для mark price нужен TWAP, для liquidation price — более актуальные данные.
Мы строим трёхуровневую систему: Pyth для trading execution, Chainlink TWAP для mark price расчёта, собственный on-chain TWAP как последняя линия защиты. Шаги настройки:
- Интегрировать Pyth pull-оракул для каждой торговой пары — обновления каждые 400ms.
- Настроить Chainlink TWAP feed (с периодом 1 час) для расчёта mark price.
- Развернуть резервный on-chain TWAP на основе последних 100 блоков.
- Провести симуляцию манипуляции: открыть позицию на $1M и попытаться сдвинуть цену — система должна сопротивляться.
Как обеспечить ликвидность для деривативной биржи?
Ликвидность — ключевой фактор успеха любого деривативного протокола. Мы предлагаем несколько моделей: vAMM для быстрого запуска (требует минимального капитала), liquidity pool с LP-стимулами (начальный TVL от $2M), или гибридный orderbook для институциональных объёмов. Выбор зависит от целевой аудитории и объёмов торгов. Обычно для старта достаточно vAMM с последующим переходом на pool при достижении $10M дневного объёма.
Риски и меры по их митигации
Insurance fund: обязательный компонент для любого перпетуал-протокола. Наполняется из части trading fee (обычно 10-20%). Покрывает bad debt при недостаточной ликвидации. При TVL $180M мы рекомендуем целевой размер фонда $1.8M.
Position limits: максимальный open interest на сторону (лонг/шорт) ограничивает экспозицию протокола. Пропорционально размеру insurance fund.
Circuit breakers: при отклонении mark price от index price больше чем на 5% — остановка новых позиций до нормализации. Защита от оракульных манипуляций.
Admin key security: протокол с TVL > $500M требует multi-sig timelock (минимум 48 часов) на все параметрические изменения. Мгновенные изменения комиссий или ликвидационных порогов — красный флаг для любого аудитора.
Стек разработки
Контракты: Solidity 0.8.24 + Foundry для тестирования. Foundry fork-тесты критичны — тестируем liquidation сценарии на исторических данных (крах LUNA, коллапс FTX). Статический анализ: Slither + Halmos для символьного выполнения критических функций.
Off-chain компоненты (funding rate расчёт, keeper для liquidations) — Node.js + ethers.js с Flashbots bundle submission для приоритетного исполнения ликвидаций. Типичная ликвидация занимает ~2000 gas.
Фронтенд: wagmi v2 + viem + TradingView Lightweight Charts для candlestick отображения. Поддерживаем до 50 000 параллельных подключений.
Процесс работы
| Этап | Продолжительность | Описание |
|---|---|---|
| Аналитика и spec | 1 неделя | Тип деривативов, торговые пары, модель ликвидности, оракульный стек, экономика fee |
| Архитектурное проектирование | 1 неделя | Контрактная схема, storage layout, интерфейсы, economic model simulation |
| Разработка ядра | 4–8 недель | Position management, margin system, liquidation engine, funding rate, оракульные интеграции |
| Off-chain сервисы | 2–3 недели | Keeper боты для ликвидаций, funding rate keeper, price feed агрегатор |
| Тестирование | 2 недели | Unit, fuzz, fork-тесты. Симуляция стресс-сценариев |
| Внешний аудит | 2–4 недели | Обязателен для деривативного протокола с реальным TVL. Минимум два независимых аудитора |
Что входит в разработку протокола деривативов под ключ?
- Разработка смарт-контрактов ядра (Solidity, Foundry)
- Off-chain сервисы (Node.js, ethers.js)
- Интеграция оракулов (Pyth, Chainlink, Redstone)
- Комплексное тестирование (unit, fuzz, fork)
- Подготовка к внешнему аудиту и сопровождение
- Документация (архитектурная, API, deployment guide)
- Обучение команды заказчика
- Постдеплойная поддержка в течение 3 месяцев
Ориентиры по срокам
MVP vAMM с одной торговой парой — 8–10 недель. Полноценный multi-market протокол с partial liquidation, insurance fund и keeper инфраструктурой — 4–6 месяцев до аудита. Постаудитные правки и деплой — ещё 4–8 недель. Свяжитесь с нами для оценки вашего проекта — мы рассчитаем сроки и стоимость индивидуально. Получите консультацию по выбору модели ликвидности и стека разработки.
Перед деплоем рекомендуется проверить: reentrancy guard во всех функциях изменения маржи, тестирование ликвидации при экстремальных движениях цены (например, -50% за 1 блок), корректность расчёта funding rate при нулевом объёме, формальную верификацию критических функций (Halmos), аудит доступа в admin-функциях и stress-тестирование газовых лимитов при массовых ликвидациях.
Наша команда готова обсудить ваш проект — мы гарантируем прозрачный процесс и высокое качество кода, подтверждённое внешним аудитом.