Розробка децентралізованої біржі безстрокових ф'ючерсів (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 повинні бути розраховані коректно. Помилка тут — прямі втрати або прибуток трейдерів за рахунок пулу.
Приклад розрахунку funding rate
Формула: fundingRate = (openInterest * fundingFactor) / poolLiquidity. На практиці значення можуть варіюватися: funding factor 0.0001 per second при 100% utilization, max open interest налаштовується відповідно до конфігурації пулу.
Чому варто використовувати 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-параметри:
| Параметр | Типові значення | Опис |
|---|---|---|
| Max open interest | Настроюється | Ліміт сумарних позицій на сторону |
| Max PnL factor | 0.5 (50% пулу) | Максимум unrealized profit трейдерів |
| Borrowing factor | 0.0001 per second at 100% utilization | Швидкість нарахування borrowing fee |
| Funding factor | Varies | Швидкість перетоку від long до short |
| Position impact factor | Varies | Агресивність price impact |
Неправильне калібрування параметрів — прямий вектор атаки. Oracle manip + високий max PnL factor = можливість дренажу пулу через штучно прибуткові позиції.
Порівняння версій: GMX v2 vs v1 за швидкістю ORACLE
| Характеристика | GMX v1 | GMX v2 |
|---|---|---|
| Оракули | Chainlink стандарт | Chainlink Low Latency + Pyth |
| Частота оновлення | ~ хвилини | ~ секунди |
| Затримка до виконання | Висока | Низька — арбітраж виключено |
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 симуляція).
- Документація та навчання команди.
Процес розробки
- Аналітика та специфікація: формалізація математики, вибір стеку, проектування архітектури.
- Розробка смарт-контрактів: написання коду з використанням Foundry, написання інваріантних тестів.
- Інтеграція oracle та keeper-інфраструктури: налаштування Chainlink Low Latency, Pyth, розробка ботів.
- Frontend інтеграція: підключення через wagmi, створення інтерфейсу для торгівлі та управління пулом.
- Тестування та аудит: внутрішній QA, зовнішній аудит смарт-контрактів та економічних моделей.
- Деплой та моніторинг: розгортання на mainnet, налаштування моніторингу та алармів.
Орієнтири за термінами
MVP perpetual DEX з одним market (ETH) та keeper інфраструктурою — 2-3 місяці. Повноцінна платформа з кількома markets, governance, GM токеномікою та frontend — від 5-6 місяців. Вартість розраховується після технічної специфікації. Зв'яжіться з нами для попередньої оцінки. Замовте розробку perpetual DEX під ключ — отримайте консультацію. Ми гарантуємо прозору вартість та фіксовані терміни. Багаторічний досвід у блокчейні, 20+ успішних DeFi-проектів.