Разработка perpetual DEX (dYdX-стиль)
dYdX v4 перешёл на собственный Cosmos appchain именно потому, что on-chain orderbook на Ethereum главной сети экономически нецелесообразен: каждое обновление заявки — транзакция, каждая транзакция — gas. При тысячах обновлений в минуту это неподъёмно. Реальная perpetual DEX с orderbook — это гибридная архитектура: off-chain matching с on-chain settlement.
Это принципиально отличает perpetual DEX от spot AMM. Здесь нет пула ликвидности в классическом смысле — есть виртуальный AMM (vAMM) или orderbook, позиции с плечом, funding rate, страховой фонд и ликвидационный движок.
Архитектура perpetual DEX
Off-chain orderbook + on-chain settlement
Orderbook layer (off-chain). Orders размещаются и матчатся off-chain matching engine. Это централизованный компонент в большинстве perpetual DEX — компромисс между UX и децентрализацией. Orders подписаны приватным ключом пользователя (EIP-712 typed signature), что позволяет верифицировать on-chain без доверия к matching engine.
Settlement layer (on-chain). Matched orders батчатся и отправляются в 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 иногда экстремальный при дисбалансе лонгов и шортов.
Позиции и маржа
Isolated margin vs cross margin — ключевое архитектурное решение:
Isolated margin. Каждая позиция имеет выделенный залог. Ликвидация одной позиции не затрагивает другие. Проще в расчётах, ниже капитал-эффективность.
Cross margin. Все позиции аккаунта суммируются. Прибыль по одной позиции покрывает убыток другой. Выше эффективность, сложнее health factor расчёт.
Структура позиции в контракте:
struct Position {
int256 size; // положительный = лонг, отрицательный = шорт
uint256 openNotional; // открытая позиция в USD
int256 lastFundingIndex; // для расчёта funding payments
uint256 collateral; // залог в маржинальном токене
}
Funding rate механика
Funding rate — механизм привязки перп-цены к 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 check. Если оракул не обновлялся более 1 часа — funding pause.
Ликвидационный движок
Health factor и margin requirements
Initial margin (IM) — залог необходимый для открытия позиции. Maintenance margin (MM) — минимальный залог для поддержания. IM > MM.
Пример: leverage 10x, IM = 10%, MM = 5%.
- Открываем $100,000 позицию с $10,000 залогом
- При убытке $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).
Liquidation и страховой фонд
Когда marginRatio < MM — позиция ликвидируется. Ликвидатор получает bonus (обычно 2-5% от position size). Оставшийся залог после bonus — в страховой фонд.
Если залог меньше liquidation bonus — insurance fund покрывает разницу (bad debt). Если insurance fund исчерпан — 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 scenarios.
Технический стек
Контракты: Solidity 0.8.x, Foundry. Базовая логика — собственная реализация, не 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 updates на Arbitrum/Solana).
Frontend: React + wagmi/viem, real-time orderbook через WebSocket.
Тестирование
Foundry fuzz-тесты на финансовые инварианты:
- Сумма всех positions = 0 (лонги = шортам)
- Insurance fund не уходит в минус без ADL
- Funding payments корректно начисляются при всех сценариях
Симуляция cascade liquidations: создаём 100 позиций, резко движем mark price, проверяем что все ликвидируются корректно и insurance fund не исчерпывается.
Fork-тесты с реальными Chainlink feeds на форке Arbitrum mainnet.
Процесс разработки
Спецификация (1 неделя). Тип DEX (orderbook/vAMM), поддерживаемые рынки, модель маржи, funding rate параметры.
Архитектура (1 неделя). Settlement контракты, off-chain компоненты, oracle интеграции.
Разработка контрактов (6-8 недель). Позиции, ликвидация, funding, страховой фонд.
Off-chain движок (4-6 недель). Matching engine, API, orderbook.
Аудит (6-8 недель). Обязателен. Perpetual DEX — в числе самых сложных DeFi систем по поверхности атак.
Запуск (постепенный). Тестнет → mainnet с ограниченным OI → полный запуск. Gradual открытие лимитов снижает риск эксплойта на старте.
Ориентиры по срокам
Минимальный perpetual DEX с vAMM для одного рынка — 2 месяца разработки. Полноценная платформа orderbook-стиля с несколькими рынками, cross margin и автоматической ликвидацией — 3+ месяца только разработки, плюс 6-8 недель аудита.