Взявшись за розробку першого протоколу перпетуалів для клієнта, ми одразу зіткнулися з проектуванням стійкої до маніпуляцій системи ліквідації. Стандартний механізм із повним закриттям позиції при 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
Класичний підхід — ліквідація при 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.
Як ми захищаємо протокол від оракульних маніпуляцій?
Деривативний протокол — найвимогливіший споживач оракулів у 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 для ліквідацій) — 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-тестування газових лімітів при масових ліквідаціях.
Наша команда готова обговорити ваш проєкт — ми гарантуємо прозорий процес та високу якість коду, підтверджену зовнішнім аудитом.