Разработка perpetual DEX (GMX-стиль)

Разработка perpetual DEX (GMX-стиль)

GMX v2 — $400M+ TVL, $1B+ дневного объёма в пиковые периоды. Архитектура: трейдеры торгуют с кредитным плечом против пула ликвидности (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.

OrderVault — временное хранение залога при создании ордера. Ордер не исполняется немедленно — это двухфазный процесс.

ExchangeRouter — исполнение ордеров через keeper-ботов. Keeper проверяет условия (limit price достигнут, oracle обновлён) и вызывает executeOrder().

DataStore — единое хранилище всех данных протокола через bytes32 keys. Это позволяет обновлять логику без миграции storage.

EventEmitter — отдельный контракт только для событий. Все события emit через него, что упрощает индексирование через The Graph.

Такая архитектура обеспечивает апгрейдаемость: 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 должны быть рассчитаны корректно. Ошибка здесь — прямые потери или прибыль трейдеров за счёт пула.

Oracle: 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 = возможность дренажа пула через искусственно прибыльные позиции.

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

Спецификация математики (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 симуляция).

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

MVP perpetual DEX с одним market (ETH) и keeper инфраструктурой — 2-3 месяца. Полноценная платформа с несколькими markets, governance, GM токеномикой и frontend — от 5-6 месяцев.

Стоимость рассчитывается после технической спецификации.