Розробка Perpetual DEX (стиль dYdX)
dYdX v4 мігрував на власний Cosmos appchain саме тому, що on-chain orderbook на Ethereum mainnet економічно нецілісно: кожне оновлення ордера — це транзакція, кожна транзакція споживає газ. При тисячах оновлень на хвилину це стає неприйнятно дорогим. Справжній perpetual DEX з orderbook — це гібридна архітектура: off-chain matching з on-chain settlement.
Це принципово відрізняє perpetual DEX від spot AMM. Тут немає пулу ліквідності у класичному сенсі — замість цього є віртуальний AMM (vAMM) або orderbook, плечові позиції, funding rate, страховий фонд та engine ліквідації.
Архітектура Perpetual DEX
Off-chain orderbook + on-chain settlement
Orderbook layer (off-chain). Ордери розміщуються та матчуються off-chain matching engine. Це централізована компонента у більшості perpetual DEX — компроміс між UX та децентралізацією. Ордери підписуються приватним ключем користувача (EIP-712 typed signature), що дозволяє on-chain верифікацію без довіри до matching engine.
Settlement layer (on-chain). Матчені ордери батчуються та надсилаються до settlement контракту. Контракт верифікує підписи, оновлює позиції, розраховує PnL та застосовує funding payments.
Цей підхід використовують dYdX v3, Aevo та Paradex. Основний ризик — liveness: якщо matching engine впаде, користувачі не можуть відкривати/закривати позиції (хоча кошти завжди залишаються on-chain та безпечні).
vAMM підхід (Perpetual Protocol)
Perpetual Protocol v2 (Curie) використовує віртуальний AMM: немає реальних резервів, ціна визначається механікою x*y=k, але ліквідність віртуальна. Реальні кошти у пулі розташовані у Uniswap v3, який використовується як механізм price discovery.
Переваги: повна децентралізація, немає off-chain компонент. Недоліки: slippage вищий, ніж у orderbook, немає limit orders, funding rate іноді екстремальний при дисбалансу лонгів та шортів.
Позиції та margin
Isolated margin vs cross margin — ключове архітектурне рішення:
Isolated margin. Кожна позиція має виділений collateral. Ліквідація однієї позиції не впливає на інші. Простіше в розрахунках, нижча capital efficiency.
Cross margin. Усі позиції аккаунту агрегуються. Прибуток по одній позиції покриває збиток іншої. Вища ефективність, складніший розрахунок health factor.
Структура позиції у контракті:
struct Position {
int256 size; // позитивний = long, негативний = short
uint256 openNotional; // відкрита позиція у USD
int256 lastFundingIndex; // для розрахунку funding payments
uint256 collateral; // collateral у маржинальному токені
}
Механіка funding rate
Funding rate — механізм прив'язки perp-ціни до spot-ціни. Лонги платять шортам при perp > spot, і навпаки.
Стандартна формула (Binance-стиль):
fundingRate = clamp((perpPrice - spotPrice) / spotPrice * 0.01, -0.075%, 0.075%)
Застосовується кожні 8 годин. On-chain реалізація через fundingIndex — глобальний акумулятор:
newFundingIndex = lastFundingIndex + fundingRate * positionSize
userFundingPayment = (currentFundingIndex - position.lastFundingIndex) * position.size
При оновленні позиції lastFundingIndex синхронізується. Невложений funding виплачується/отримується з collateral.
Для spot-ціни — Chainlink oracle з перевіркою staleness. Якщо оракул не оновлювався більше 1 години — funding pause.
Engine ліквідації
Health factor та margin requirements
Initial margin (IM) — collateral необхідний для відкриття позиції. Maintenance margin (MM) — мінімальний collateral для утримання. IM > MM.
Приклад: 10x leverage, IM = 10%, MM = 5%.
- Відкриємо позицію $100,000 з $10,000 collateral
- При збитку $5,000 → margin ratio = $5,000 / $100,000 = 5% → ліквідація
marginRatio = (collateral + unrealizedPnL) / openNotional
Unrealized PnL = (markPrice - entryPrice) * size. Mark price — це Chainlink або TWAP з вашого пулу, не last trade price (захист від wash trading та price manipulation).
Ліквідація та страховий фонд
Коли marginRatio < MM — позиція ліквідується. Ліквідатор отримує bonus (зазвичай 2-5% від position size). Залишок collateral після bonus йде до страхового фонду.
Якщо collateral менше, ніж liquidation bonus — страховий фонд покриває різницю (bad debt). Якщо страховий фонд вичерпаний — ADL (Auto-Deleveraging): прибуткові позиції примусово скорочуються для покриття bad debt. ADL — це останній рубіж, деструктивний для довіри трейдерів.
Страховий фонд поповнюється з частини trading fees (зазвичай 10-20% від fee revenue).
Цінові оракули та захист від маніпуляцій
Mark price = медіана трьох джерел: Chainlink, Pyth Network, on-chain TWAP (якщо є). Якщо відхилення між джерелами > 2% — використовуємо медіану, не середнє.
Index price (для funding rate) = Chainlink агрегатор від 7+ джерел. Значно складніше маніпулювати.
Circuit breaker: якщо mark price відхиляється від index price > 5% — торгівля зупиняється на 15 хвилин. Захист від oracle attacks та flash crash сценаріїв.
Tech stack
Контракти: Solidity 0.8.x, Foundry. Core logic — власна реалізація, не fork dYdX (їхній код не повністю відкритий). OpenZeppelin для access control та pausable механіки.
Off-chain matching engine: TypeScript/Go. Redis для orderbook in-memory. PostgreSQL для історичних даних. Kafka/Redis Streams для event streaming між компонентами.
Oracle інтеграції: Chainlink Price Feeds + Pyth Network (sub-second оновлення на Arbitrum/Solana).
Frontend: React + wagmi/viem, real-time orderbook через WebSocket.
Тестування
Foundry fuzz-тести на фінансові інваріанти:
- Сума всіх позицій = 0 (лонги = шортам)
- Страховий фонд не йде в мінус без ADL
- Funding payments коректно застосовуються у всіх сценаріях
Симуляція cascade liquidations: створюємо 100 позицій, різко рухаємо mark price, перевіряємо, що всі ліквідуються коректно та страховий фонд не вичерпується.
Fork-тести з реальними Chainlink feeds на форку Arbitrum mainnet.
Процес розробки
Специфікація (1 тиждень). Тип DEX (orderbook/vAMM), підтримувані ринки, модель margin, параметри funding rate.
Архітектура (1 тиждень). Settlement контракти, off-chain компоненти, oracle інтеграції.
Розробка контрактів (6-8 тижнів). Позиції, ліквідація, funding, страховий фонд.
Off-chain engine (4-6 тижнів). Matching engine, API, orderbook.
Аудит (6-8 тижнів). Обов'язковий. Perpetual DEX серед найскладніших DeFi систем за поверхнею атак.
Запуск (поступовий). Testnet → mainnet з обмеженим OI → повний запуск. Поступове відкриття лімітів знижує ризик експлойту при запуску.
Орієнтири за часом
Мінімальний perpetual DEX з vAMM для одного ринку — 2 місяці розробки. Повнофункціональна платформа orderbook-стилю з кількома ринками, cross margin та автоматичною ліквідацією — 3+ місяці розробки, плюс 6-8 тижнів аудиту.