Розробка Perpetuals-протоколу
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, страховий фонд — кожна компонента має способи поламатися у нестандартних ринкових умовах.
Два архітектурних паттерни та де кожен падає
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 зіткнувся саме з цим у 2021: у періоди екстремальної волатильності funding rate досягав 1000% APR, ринок переставав функціонувати.
Пул ліквідності як контрагент — модель GMX
GLP/GM пул тримає кошик активів (ETH, BTC, USDC, USDT). Трейдер, що відкриває long на ETH, отримує прибуток за рахунок пулу, збиток — пул забирає. Провайдер ліквідності несе directional risk: якщо трейдери у сукупності прибуткові — LP програє.
Вразливість: оракульний арбітраж. Якщо Chainlink feed оновлюється повільніше, ніж рухається ринок на CEX — арбітражер відкриває позицію за застарілою ціною, гарантовано профітить. GMX v1 терпів мільйони на цьому, рішення у v2 — перехід на Chainlink Low Latency Feeds з оновленням кожні кілька секунд та keeper-архітектурою для виконання ордерів.
Ключові механіки, що вимагають акуратної реалізації
Funding rate
Мета funding rate — утримувати mark price близько index price. Базова формула:
fundingRate = (markPrice - indexPrice) / indexPrice * fundingFactor
Але диявол у деталях: як часто починається funding (по блокам або по часу?), чи є caps на максимальний rate, як обробляється накопичений funding при частковому закритті позиції. Помилка у логіці нарахування — прямі втрати для трейдерів або дира у страховому фонді.
Використовуємо паттерн cumulative funding index (аналогічно Aave's cumulative interest index): одна глобальна змінна globalFundingIndex оновлюється при кожній взаємодії, позиція зберігає снапшот entryFundingIndex, різниця — накопичений funding борг або кредит. Це O(1) по газу незалежно від кількості відкритих позицій.
Liquidation engine
Стандартна помилка — ліквідація тільки за запитом (permissioned liquidation). При різкому рухові ринку ліквідатори фізично не встигають ліквідувати усі underwater позиції за один блок. Протокол накопичує bad debt.
Правильна архітектура: ADL (Auto-Deleveraging) як останній рубіж. Якщо страховий фонд вичерпаний — найприбутковіші позиції примусово закриваються за mark price, щоб покрити bad debt збиткових. Це негативний досвід для прибуткових трейдерів, але єдиний спосіб не допустити повного банкротства пулу.
dYdX v4 реалізує ADL через keeper network — боти мониторять unsafe позиції та викликають liquidation/ADL транзакції, отримуючи reward з страхового фонду.
Open interest limits
Без обмежень open interest один крупний гравець може займати позицію, яка перевищує весь ліквідний пул. При ліквідації ринок не зможе виконати її без катастрофічного slippage. Лімити per-market та per-side (окремо на лонги та шорти) обов'язкові.
Stack розробки
Для EVM-цепочок (Arbitrum, Optimism, Base) — Solidity + Foundry. Arbitrum особливо популярний для perps: низький газ критичний, коли кожне оновлення позиції коштує грошей.
Keeper-інфраструктура: TypeScript боти на viem/ethers.js, мониторинг через Tenderly webhooks або власний event indexer. OpenZeppelin Defender Autotasks для автоматичних операцій з multisig.
Цінові дані: Chainlink Low Latency (push-модель для критичних операцій), Pyth Network (pull-модель, трейдер сам надає price update у транзакції — це зменшує вектор oracle front-running).
| Компонент | Рішення | Обґрунтування |
|---|---|---|
| Цепочка | 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 симуляція: віртуальні трейдери з різними стратегіями, stress-тести при волатильності ±50% за годину. Параметри (funding factor, max OI, liquidation bonus) калібруються за результатами.
Аудит. Perpetuals-протоколи вимагають аудит від спеціалізованих фірм — фінансова математика та смарт-контракти одночасно. Окремо рекомендуємо economic audit (моделювання атак через стимули) паралельно з code audit.
Орієнтири за часом
MVP perpetuals-протокол (один ринок, базові ордери) — 2-3 місяці. Повнофункціональна платформа з кількома ринками, DAO governance, кросс-маржою — від 4 до 6 місяців. Час на зовнішній аудит — додатково 4-6 тижнів.
Вартість розраховується після технічного ТЗ.