Разработка децентрализованной биржи бессрочных фьючерсов (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 10-50M USD.
Почему стоит использовать 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 | 10-50M USD | Лимит суммарных позиций на сторону |
| 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-проектов.