Разработка on-chain протокола деривативов под ключ

Взявшись за разработку первого протокола перпетуалов для клиента, мы сразу столкнулись с проектированием устойчивой к манипуляциям системы ликвидации. Стандартный механизм с полным закрытием позиции при 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 — самом востребованном типе.

Почему 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. Требования:

1. Latency: Chainlink апдейт раз в несколько блоков недостаточен для активной торговли. Pyth Network предоставляет sub-second updates через pull-оракул: данные публикуются off-chain, on-chain обновление инициирует пользователь транзакцией с proof.
2. Multi-asset: для каждого рынка нужен отдельный price feed. Redstone предоставляет гибкую систему с кастомными агрегаторами.
3. Manipulation resistance: для mark price нужен TWAP, для liquidation price — более актуальные данные.

Мы строим трёхуровневую систему: Pyth для trading execution, Chainlink TWAP для mark price расчёта, собственный on-chain TWAP как последняя линия защиты. Шаги настройки:

1. Интегрировать Pyth pull-оракул для каждой торговой пары — обновления каждые 400ms.
2. Настроить Chainlink TWAP feed (с периодом 1 час) для расчёта mark price.
3. Развернуть резервный on-chain TWAP на основе последних 100 блоков.
4. Провести симуляцию манипуляции: открыть позицию на $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 параллельных подключений.

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

Что входит в разработку протокола деривативов под ключ?

• Разработка смарт-контрактов ядра (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-тестирование газовых лимитов при массовых ликвидациях.

Наша команда готова обсудить ваш проект — мы гарантируем прозрачный процесс и высокое качество кода, подтверждённое внешним аудитом.