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

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

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 на медіану з трьох оракулів (Chainlink, Pyth, Redstone). Маніпуляція стає дорогою: потрібно рухати і торговий обсяг на протоколі, і кілька зовнішніх оракулів одночасно.

Liquidation engine та partial 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 облік у storage.

Для більшості клієнтських протоколів ми реалізуємо ізольовану маржу як режим за замовчуванням з опціональним 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 використовує цю архітектуру.

Oracle інфраструктура

Деривативний протокол — найбільш вимогливий споживач оракулів у DeFi. Вимоги:

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

Ми будуємо трирівневу систему: Pyth для торгівельного виконання, Chainlink TWAP для розрахунку mark price, власний on-chain TWAP як остання лінія захисту.

Ризики та заходи їх мітигації

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

Position limits: максимальний open interest на сторону (long/short) обмежує максимальний exposure протоколу. Пропорційно розміру insurance fund.

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

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 для ліквідацій) — Node.js + ethers.js з Flashbots bundle submission для пріоритизованого виконання ліквідацій.

Frontend: 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 тижнів.