Розробка 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 токена = (всі активи в пулі - сумарний невиконаний PnL трейдерів) / загальна пропозиція GM.

Це ключовий момент: коли трейдери в сукупності прибуткові — ціна GM токена падає (пулу потрібно буде виплатити). Коли трейдери програють — GM зростає. LP та трейдери в нульовій сумі.

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

Impact комісії та depth factor

Одна з розумних механік GMX v2 — price impact для відкриття позицій. Якщо трейдер відкриває великий long, який створює дисбаланс (longs > shorts), він платить додаткову impact комісію. Трейдер, який балансує дисбаланс (відкриває short в long-heavy пулі), отримує rebate.

Це емулює глибину order book без реального order book. Depth factor — параметр пулу, керований governance, який визначає наскільки агресивно impact зростає з розміром позиції.

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

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

GMX v2 розбита на кілька шарів:

Router — точка входу для користувачів. Приймає ордери, відправляє їх до OrderVault.

OrderVault — тимчасове зберігання залогу при створенні ордера. Ордери не виконуються негайно — це двофазний процес.

ExchangeRouter — виконання ордерів через keeper-ботів. Keeper перевіряє умови (ліміт ціни досягнутий, oracle оновлений) і викликає executeOrder().

DataStore — єдине сховище всіх даних протоколу через bytes32 ключі. Це дозволяє оновлювати логіку без міграції storage.

EventEmitter — окремий контракт тільки для подій. Всі події емітуються через нього, що спрощує індексування через The Graph.

Така архітектура забезпечує upgradeability: Handler контракти замінювані без зміни DataStore. Це критично для протоколу, який буде розвиватися після деплою.

Keeper-архітектура для виконання ордерів

Ордери в GMX v2 не виконуються синхронно. Користувач створює ордер (market/limit/stop-loss) → зберігається в контракті → keeper-боти моніторять ордери → коли умови виконані, keeper викликає executeOrder().

Чому це потрібно: щоб не довіряти користувачу встановлювати timestamp виконання (фронтранінг через вибір моменту виконання). Keeper отримує актуальну ціну Chainlink Low Latency в момент виконання — це справедливіше для обох сторін.

Keeper отримує execution 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 // ліміт не досягнутий
      logError(order.key, err)
    }
  }
}

Funding комісії та借oring комісії

GMX v2 має два типи постійних комісій для власників позицій:

Borrowing fee — плата за використання ліквідності пулу. Розраховується як (openInterest / poolLiquidity) * borrowingFactor * time. При високій utilization — дорожче.

Funding fee — механізм балансування між long та short. Сторона з більшим open interest платить іншій стороні. Накопичується через cumulative index подібно до процентного індексу Aave.

При частковому закритті позиції — накопичені комісії мають бути розраховані правильно. Помилка тут — прямі втрати або прибутки трейдерів за рахунок пулу.

Oracle: Chainlink Low Latency + Pyth

GMX v1 використовував стандартні Chainlink feeds (оновлення раз на кілька хвилин або при відхиленні >0.5%). Це створювало арбітраж: ціна на CEX змінилася, Chainlink ще не оновився — відкрити позицію за старою ціною, одразу закрити за новою.

GMX v2 перейшла на Chainlink Low Latency Feeds — оновлення кожні кілька секунд через off-chain підписану price attestation. Keeper включає підписану ціну прямо в транзакцію виконання.

Pyth Network — альтернативна push-oracle система з аналогічною швидкістю. Інтеграція з обома системами як primary/fallback — стандарт для production-протоколів.

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

Кожен market керується через DAO-параметри:

Неправильна калібровка параметрів — прямий вектор атаки. Oracle манипуляція + високий 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 тестування.

Keeper інфраструктура (2-3 тижні). TypeScript боти, моніторинг, fallback при RPC downtime.

Frontend інтеграція (2-4 тижні). wagmi/viem хуки для даних пулів, побудова ордерів, The Graph субграф для історії.

Аудит (4-6 тижнів). Perpetual DEX — складний протокол. Аудит повинен охоплювати як смарт-контракти, так і економічні механіки (симуляція економічних експлойтів).

Орієнтири по строкам

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

Вартість розраховується після технічної специфікації.