dYdX v3 обробляв $10 млрд денного об'єму на централізованому order book з on-chain settlement. GMX v2 іде іншим шляхом: провайдери ліквідності несуть ризик через GM-пули, трейдери торгують проти пулу, оракульна ціна Chainlink Low Latency визначає PnL. Обидва підходи працюють — але ламаються по-різному, і вибір архітектури визначає все. Ми розробляємо протоколи перпетуальних контрактів під ключ: від специфікації до деплою та моніторингу.
Perpetuals-протокол — найбільш технічно складний тип DeFi. Funding rate, mark price, index price, open interest limits, liquidation engine, insurance fund — кожен з цих компонентів може зламатися в нестандартних ринкових умовах. Наша команда має 7+ років досвіду в DeFi та більше 30 реалізованих проєктів, включаючи 5 протоколів перпетуалів. Ми гарантуємо якість через багаторівневе тестування та аудит.
Розробка протоколу перпетуальних контрактів: з чого почати?
Першим кроком визначаємо архітектуру. Від неї залежать вимоги до оракулів, газова вартість (до 3x різниця), ризики для LP та трейдерів. Нижче розбираємо два основні патерни.
Virtual AMM (vAMM) — модель Perpetual Protocol — розробка протоколу перпетуальних
vAMM використовує формулу xy=k для визначення ціни без реального пулу ліквідності. Трейдер відкриває long на 10 ETH — віртуальний резерв ETH зменшується, USDC збільшується, ціна зростає. Проблема: при сильному дисбалансі open interest mark price розходиться з index price. Funding rate має вирівняти це, але якщо розходження занадто велике — funding rate стає економічно невигідним. Perpetual Protocol v1 зіткнувся з цим в історичному прикладі: в періоди екстремальної волатильності funding rate досягав 1000% APR, ринок переставав функціонувати.
Пул ліквідності як контрагент — модель GMX
GLP/GM пул тримає корзину активів (ETH, BTC, USDC, USDT). Трейдер, який відкриває лонг на ETH, отримує прибуток за рахунок пулу; збиток — пул забирає. Провайдер ліквідності несе directional risk: якщо трейдери в сукупності прибуткові — LP втрачає. Вразливість: оракульний арбітраж. Рішення в v2 — перехід на Chainlink Low Latency Feeds з оновленням кожні кілька секунд та keeper-архітектурою для виконання ордерів.
Що таке cumulative funding index і чому це важливо?
Funding rate розраховується за формулою: fundingRate = (markPrice - indexPrice) / indexPrice * fundingFactor. Критична деталь — як часто нараховується funding (по блоках чи по часу?), чи є caps, як обробляється накопичений funding при частковому закритті. Cumulative funding index (як у Aave) — одна глобальна змінна globalFundingIndex, що оновлюється при кожній взаємодії; позиція зберігає снапшот entryFundingIndex. Різниця — накопичений funding борг або кредит. Це O(1) по газу незалежно від кількості відкритих позицій. Помилка в цій логіці — прямі втрати для трейдерів або дірка в страховому фонді.
Деталі реалізації: приклад на Solidity
// pseudocode for funding index update function _updateFundingIndex() internal { uint256 timeDelta = block.timestamp - lastFundingTimestamp; uint256 fundingAccrued = (indexPrice - markPrice) * timeDelta / 1e18; globalFundingIndex += fundingAccrued; lastFundingTimestamp = block.timestamp; } Liquidation engine
Стандартна помилка — permissioned liquidation (тільки за запитом). При різкому русі ринку ліквідатори не встигають ліквідувати всі underwater позиції за один блок — протокол накопичує bad debt. Правильна архітектура: ADL (Auto-Deleveraging) як останній рубіж. Якщо страховий фонд вичерпано (типовий розмір 2–3% від TVL) — найприбутковіші позиції примусово закриваються за mark price. Це негативний досвід, але єдиний спосіб не допустити повного банкрутства пулу. dYdX v4 реалізує ADL через keeper network — боти моніторять unsafe позиції та викликають liquidation, отримуючи reward. Детальніше про Auto-Deleveraging.
Open interest limits
Без обмежень один великий гравець може зайняти позицію, що перевищує весь ліквідний пул. При ліквідації ринок не зможе виконати її без катастрофічного slippage. Ліміти per-market та per-side (окремо на лонги та шорти) обов'язкові.
Порівняння архітектур
| Параметр | vAMM (Perpetual Protocol) | Pool-model (GMX) |
|---|---|---|
| Контрагент | Віртуальний пул | Реальний пул LP |
| Oracle dependency | Низька (ціни за формулою) | Висока (Chainlink) |
| Gas cost на відкриття | ~80k (в 1.5 рази менше) | ~120k |
| Liquidity fragmentation | Немає | Є (кожен пул окремо) |
| Risk for LP | Немає | Так (directional) |
vAMM в 3 рази дешевший по газу, але не масштабується при високій концентрації open interest (наприклад, >$500 млн). Pool-model потребує складнішої оракульної інфраструктури, але дає кращі можливості для комбінування позицій.
Стек розробки
Для EVM-мереж (Arbitrum, Base) — Solidity + Foundry (в 5 разів швидше Hardhat при запуску тестів). Keeper-інфраструктура: TypeScript боти на viem/ethers.js, моніторинг через Tenderly webhooks. Рекомендуємо комбінацію оракулів: Chainlink Low Latency (push-модель) та Pyth Network (pull-модель — трейдер сам надає price update, знижуючи вектор oracle front-running). Середній час між блоками на Arbitrum — 0.25 секунди, що дозволяє виконувати ліквідації протягом 2–3 блоків.
| Компонент | Рішення | Обґрунтування |
|---|---|---|
| Мережа | Arbitrum One / Base | Низький газ, висока ліквідність |
| Oracle | Chainlink + Pyth | Різні моделі оновлення |
| Keeper | OpenZeppelin Defender | Managed execution |
| Субграф | The Graph | Історія позицій, PnL |
| Тести | Foundry + Echidna | Fuzz + property tests |
Процес розробки
- Математична специфікація (~1 тиждень). Формалізація формул funding rate, margin requirements, liquidation price, mark price. Помилка в специфікації коштує години; в продакшні — мільйони.
- Розробка core контрактів (~4-8 тижнів). Position manager, funding engine, liquidation engine, oracle module. Fork-тести на mainnet з реальними Chainlink feeds.
- Keeper інфраструктура (~2-3 тижні). TypeScript боти, моніторинг, alerting, fallback при downtime.
- Параметризація та симуляція (~1-2 тижні). Agent-based симуляція: віртуальні трейдери з різними стратегіями, стрес-тести волатильності ±50%. 90% ліквідацій відбуваються протягом 5 секунд після руху ціни — це критичний параметр для налаштування.
- Аудит. Code audit (reentrancy, overflow) + economic audit (стимули). Рекомендуємо Trail of Bits або Code4rena — фірми з сертифікатами безпеки.
Щоб обговорити деталі вашого проєкту, отримайте консультацію наших інженерів — оцінимо архітектуру та запропонуємо оптимальний стек.
Типові помилки при розробці перпетуалів
- Використання permissioned liquidation замість ADL — зростання bad debt при різких рухах.
- Відсутність caps на funding rate — при дисбалансі ринок перестає функціонувати.
- Недостатній розмір страхового фонду (<2% від TVL) — при кількох ліквідаціях поспіль пул може збанкрутувати.
- Oracle front-running без pull-моделі (Pyth) — трейдери можуть випереджати оновлення ціни.
Що входить в роботу
- Архітектурна документація з діаграмами потоків
- Повний набір смарт-контрактів з тестами (Foundry, Echidna)
- Keeper-сервіси та deployment скрипти
- Agent-based симуляція для калібрування параметрів
- Інтеграція з subgraph для історії позицій
- Розгортання в mainnet/testnet з мультисигом
- Моніторинг та алертинг (Tenderly, Datadog)
- Документація для DAO governance
Орієнтири по термінах
MVP з одним ринком та базовими ордерами — 2–3 місяці. Повноцінна платформа з кількома ринками, DAO governance, крос-маржею — від 4 до 6 місяців. Зовнішній аудит — додатково 4–6 тижнів. Вартість розраховується після технічного ТЗ.
Зв'яжіться з нами для обговорення вашого протоколу. Замовте консультацію з архітектури — оцінимо проєкт та запропонуємо оптимальний патерн.