Perpetual DEX по модели GMX: архитектура, смарт-контракты и oracle

Разработка децентрализованной биржи бессрочных фьючерсов (Perpetual swap) по модели GMX — задача, с которой мы сталкиваемся регулярно. Представьте: вы запускаете протокол, и через неделю трейдеры находят уязвимость в расчёте funding rate, которая позволяет им извлекать прибыль за счёт пула. Наш опыт в блокчейн-разработке помогает избежать таких сценариев. В одном из проектов трейдеры использовали задержку oracle для получения безрисковой прибыли — пришлось перепроектировать механизм исполнения. GMX v2 — протокол с пиковым объёмом более $1B в день и TVL свыше $400M. Архитектура: трейдеры торгуют с кредитным плечом против пула ликвидности (GM-пулы), провайдеры ликвидности зарабатывают на комиссиях и несут directional risk. Oracle — Chainlink Low Latency Feeds с обновлением каждые несколько секунд, keeper-боты для исполнения ордеров. Если хотите строить perpetual DEX по этой модели — понадобится разобраться в каждом компоненте. Ниже — что происходит под капотом.

Как устроен пул ликвидности GM-модели?

GM токены и состав пула

В GMX v2 каждый market имеет свой GM-пул: например, ETH/USDC market содержит ETH (long collateral) и USDC (short collateral). GM-токен представляет долю в этом пуле. Цена GM-токена = (total assets in pool - total pending PnL of traders) / total GM supply. Когда трейдеры в совокупности прибыльны — цена GM-токена падает (пул должен будет выплатить). Когда трейдеры теряют — GM растёт. LP и трейдеры в нулевой сумме.

function getGMTokenPrice(address market) external view returns (uint256) { MarketProps memory marketData = getMarketData(market); int256 poolValue = getPoolValue(market); // assets по текущим ценам int256 pendingPnL = getTotalPendingPnL(market); // нереализованный PnL трейдеров uint256 netValue = uint256(poolValue - pendingPnL); return netValue * 1e18 / IERC20(market).totalSupply(); } 

Impact fees и depth factor

Одна из умных механик GMX v2 — price impact для открытия позиций. Если трейдер открывает large long, который создаёт дисбаланс (longs > shorts), он платит дополнительный impact fee. Трейдер, выравнивающий дисбаланс (открывает short при long-heavy пуле), получает rebate. Это эмулирует order book depth без реального order book. Depth factor — параметр пула, управляемый governance, который определяет насколько агрессивно impact растёт с размером позиции.

Архитектура смарт-контрактов

Модульная система контрактов GMX v2

GMX v2 разбит на несколько слоёв: Router — точка входа для пользователей; OrderVault — временное хранение залога; ExchangeRouter — исполнение ордеров через keeper-ботов; DataStore — единое хранилище данных через bytes32 keys; EventEmitter — отдельный контракт только для событий. Такая архитектура обеспечивает апгрейдаемость: Handler контракты заменяемы без изменения DataStore. Это критично для протокола, который будет развиваться после деплоя.

Как работает keeper-инфраструктура?

Ордера в GMX v2 не исполняются синхронно. Пользователь создаёт ордер (market/limit/stop-loss) → хранится в контракте → keeper-боты мониторят ордера → при выполнении условий keeper вызывает executeOrder(). Зачем это нужно: не доверять пользователю устанавливать timestamp исполнения (фронтранинг через выбор moment исполнения). Keeper получает актуальную цену Chainlink Low Latency в момент исполнения — это честнее для обеих сторон. Keeper получает execution fee (заранее оплаченный пользователем) за каждое успешное исполнение. При неуспехе — fee возвращается пользователю.

// Keeper логика (упрощённо) async function processOrders() { const pendingOrders = await exchangeRouter.getPendingOrders() for (const order of pendingOrders) { const priceUpdate = await getPythPriceUpdate(order.indexToken) try { await exchangeRouter.executeOrder(order.key, { priceFeedTokens: [order.indexToken], priceFeedData: [priceUpdate], }) } catch (err) { if (err.message.includes('PRICE_NOT_MET')) continue // limit не достигнут logError(order.key, err) } } } 

Funding fees и borrowing fees

В GMX v2 два типа непрерывных комиссий для держателей позиций: Borrowing fee — плата за использование ликвидности пула. Рассчитывается как (openInterest / poolLiquidity) * borrowingFactor * time. При high utilization — дороже. Funding fee — балансировочный механизм между long и short. Сторона с большим open interest платит другой стороне. Накапливается через cumulative index аналогично Aave's interest index. При частичном закрытии позиции accumulated fees должны быть рассчитаны корректно. Ошибка здесь — прямые потери или прибыль трейдеров за счёт пула.

Почему стоит использовать Chainlink Low Latency и Pyth?

GMX v1 использовал стандартные Chainlink feeds (обновление раз в несколько минут или при отклонении >0.5%). Это создавало арбитраж: цена на CEX ушла, Chainlink ещё не обновился — открыть позицию по старой цене, сразу закрыть по новой. GMX v2 мигрировал на Chainlink Low Latency Feeds — обновление каждые несколько секунд через off-chain signed price attestation. Keeper включает подписанную цену прямо в транзакцию исполнения. Pyth Network — альтернативная push-oracle система с аналогичной скоростью. Интеграция с обеими системами как primary/fallback — стандарт для production-протоколов.

Параметры пула и governance

Каждый market управляется через DAO-параметры:

Неверная калибровка параметров — прямой вектор атаки. Oracle manip + высокий max PnL factor = возможность дренажа пула через искусственно прибыльные позиции.

Сравнение версий: GMX v2 vs v1 по скорости ORACLE

GMX v2 обрабатывает ордера в 5 раз быстрее благодаря Low Latency Feeds.

Что входит в разработку perpetual DEX?

• Спецификация математики (1-2 недели). Все формулы: borrowing rate, funding rate, price impact, GM token pricing, liquidation price — верифицированы формально до единой строчки кода.
• Core контракты (6-10 недель). DataStore, EventEmitter, OrderVault, ExchangeRouter, позиционный учёт. Foundry тесты с 90%+ покрытием, Echidna invariant testing.
• Keeper инфраструктура (2-3 недели). TypeScript боты, monitoring, fallback при RPC downtime.
• Frontend интеграция (2-4 недели). wagmi/viem hooks для данных пулов, построение ордеров, The Graph субграф для истории.
• Аудит (4-6 недель). Perpetual DEX — сложный протокол. Аудит должен покрывать и смарт-контракты, и экономические механики (economic exploit симуляция).
• Документация и обучение команды.

Процесс разработки

1. Аналитика и спецификация: формализация математики, выбор стека, проектирование архитектуры.
2. Разработка смарт-контрактов: написание кода с использованием Foundry, написание инвариантных тестов.
3. Интеграция oracle и keeper-инфраструктуры: настройка Chainlink Low Latency, Pyth, разработка ботов.
4. Frontend интеграция: подключение через wagmi, создание интерфейса для торговли и управления пулом.
5. Тестирование и аудит: внутренний QA, внешний аудит смарт-контрактов и экономических моделей.
6. Деплой и мониторинг: развертывание на mainnet, настройка мониторинга и алармов.

Ориентиры по срокам

MVP perpetual DEX с одним market (ETH) и keeper инфраструктурой — 2-3 месяца. Полноценная платформа с несколькими markets, governance, GM токеномикой и frontend — от 5-6 месяцев. Стоимость рассчитывается после технической спецификации. Свяжитесь с нами для предварительной оценки. Закажите разработку perpetual DEX под ключ — получите консультацию. Мы гарантируем прозрачную стоимость и фиксированные сроки. Многолетний опыт в блокчейне, 20+ успешных DeFi-проектов.