Разработка протокола деривативов на блокчейне

Разработка протокола деривативов на блокчейне

dYdX v3 обрабатывал сотни тысяч ордеров в день — но работал на StarkEx, централизованном off-chain движке. Когда команда переехала на собственный Cosmos-чейн в v4, они буквально заново переписали всё, потому что «настоящий» on-chain derivatives orderbook с перпетуалами на EVM не существовал в production-ready виде. Это честный индикатор сложности задачи: протокол деривативов на блокчейне — это не надстройка над AMM, это отдельная финансовая система с десятками взаимосвязанных компонентов.

Классификация on-chain деривативов

Прежде чем писать первую строчку кода, нужно точно определить тип инструмента. Контракты для разных классов деривативов не имеют общего кода кроме базовых утилит.

Дальше сосредоточимся на perpetual futures — самом востребованном типе, который клиенты заказывают чаще всего.

Perpetual futures: где живут реальные инженерные проблемы

Funding rate — сердце перпетуала

Perpetual futures не имеют экспирации. Вместо конвергенции к спотовой цене через дату экспирации перпетуал поддерживает привязку через 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.

Более продвинутый подход — 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 при крупных позициях, funding rate не всегда отражает реальный рынок.

Global liquidity pool — подход GMX. LP депонируют корзину активов (GLP/GM), становятся контрагентами для всех трейдеров. Если трейдеры в среднем теряют — LP зарабатывают. Работает хорошо на стабильных рынках, но LP несут asymmetric risk: при массовых прибыльных позициях трейдеров GLP теряет стоимость.

Hybrid orderbook + AMM — наиболее сложный, наиболее близкий к CEX UX. Off-chain матчинг (через dedicated sequencer или off-chain orderbook) с on-chain settlement. Такую архитектуру использует Hyperliquid.

Оракульная инфраструктура

Деривативный протокол — самый demanding потребитель оракулов в DeFi. Требования:

• Latency: Chainlink apдейт раз в несколько блоков недостаточен для активной торговли. 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 как последняя линия защиты.

Риски и меры по их митигации

Insurance fund: обязательный компонент для любого перпетуал-протокола. Наполняется из части trading fee (обычно 10-20%). Покрывает bad debt при недостаточной ликвидации.

Position limits: максимальный open interest на сторону (лонг/шорт) ограничивает максимальный exposure протокола. Пропорционально размеру insurance fund.

Circuit breakers: при отклонении mark price от index price больше чем на threshold (например, 5%) — остановка новых позиций до нормализации. Защита от oракульных манипуляций.

Admin key security: протокол с GMX-уровнем TVL ($500M+) требует multi-sig timelock (минимум 48 часов) на все параметрические изменения. Мгновенные изменения комиссий или ликвидационных порогов — красный флаг для любого аудитора.

Стек разработки

Контракты: Solidity 0.8.24 + Foundry для тестирования. Foundry fork-тесты критичны — тестируем liquidation сценарии на реальных исторических данных (например, LUNA-crash в мае 2022, FTX-collapse в ноябре 2022). Статический анализ: Slither + Halmos для символьного выполнения критических функций.

Off-chain компоненты (funding rate расчёт, keeper для liquidations) — Node.js + ethers.js с Flashbots bundle submission для приоритетного исполнения ликвидаций.

Фронтенд: wagmi v2 + viem + TradingView Lightweight Charts для candlestick отображения.

Процесс работы

Аналитика и 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-тесты. Симуляция стресс-сценариев.

Внешний аудит. Обязателен для деривативного протокола с реальным TVL. Рекомендуем минимум двух независимых аудиторов.

Ориентиры по срокам

MVP vAMM с одной торговой парой — 8–10 недель. Полноценный multi-market протокол с partial liquidation, insurance fund и keeper инфраструктурой — 4–6 месяцев до аудита. Постаудитные правки и деплой — ещё 4–8 недель.