Разработка форка GMX для perpetual DEX
GMX — это не просто perpetual DEX. Это конкретная архитектура: пул GLP как контрагент для всех трейдеров, zero-price-impact исполнение ордеров (для размеров до определённого порога), и оракульные цены вместо orderbook. Форк GMX — это не «скопировать контракты», это понять, как работает система управления риском между LP и трейдерами, и адаптировать её под конкретные требования.
Почему форк GMX сложнее, чем кажется
GLP как система управления риском, а не просто пул
В GMX v1 провайдеры ликвидности вносят активы в GLP vault — мультиактивный пул, который выступает контрагентом для всех трейдеров. Когда трейдер открывает long на ETH, он берёт ETH у GLP в долг (через механику reserved amount). Когда цена растёт — GLP теряет, трейдер выигрывает, и наоборот.
Это создаёт интересную динамику: GLP profitability коррелирует с тем, как много трейдеров теряет деньги. В бычьем рынке много лонгов — GLP в убытке. В медвежьем — много шортов — GLP в убытке снова. Баланс держится на комиссиях и размере открытых позиций.
При форке нужно явно решить: какие активы входят в пул, какова максимальная аллокация на каждый (в GMX: ETH ~35%, BTC ~25%, stablecoins ~40%), и как управляется ребалансинг через динамические mint/redeem комиссии. Неправильный баланс аллокаций — риск банкротства пула при направленном давлении рынка.
Price oracle и манипуляция
GMX использует Chainlink + Binance/Coinbase price aggregation с минимальной/максимальной ценой bid/ask. Spread между ними — основной механизм защиты от оракульных манипуляций. Позиция открывается по ask, закрывается по bid — spread это неявная комиссия.
В GMX v2 появился синтетический рынок через GLV vault и keeper-система для исполнения ордеров. Keeper получает execution fee и исполняет отложенные ордера атомарно с обновлением цены. Это убирает MEV из исполнения, но создаёт зависимость от liveness keeper-сети.
Для форка: если ты используешь только Chainlink (без собственного price aggregator), latency 1-3 блока при экстремальной волатильности создаёт окно для price arbitrage через GMX-позиции. Именно так несколько форков GMX v1 потеряли средства в 2022-2023 году — трейдеры открывали позиции зная следующую цену оракула.
Liquidation mechanics и bad debt
В GMX позиция ликвидируется когда losses + fees превышают collateral минус liquidationFeeUsd (фиксированный, ~5$). Liquidation keeper может вызвать liquidatePosition только когда isLiquidatable возвращает true. Проблема: при экстремальных движениях позиция может уйти в отрицательный collateral быстрее, чем keeper успевает ликвидировать. Это bad debt — GLP платит из резервов.
В оригинальном GMX эта ситуация обрабатывается через ADL (Auto-Deleveraging) в v2: при высоком utilization наиболее прибыльные позиции принудительно закрываются. Форк без ADL рискует системной несостоятельностью при black swan событии.
Архитектура форка и что мы меняем
Ключевые контракты
| Контракт | Роль | Что меняем в форке |
|---|---|---|
| Vault | Хранение активов, P&L расчёт | Комиссии, supported tokens |
| GlpManager | Mint/redeem GLP | Состав корзины, лимиты |
| PositionRouter | Ордер-менеджмент | Execution fee, delay |
| OrderBook | Limit/stop ордера | Tick size, min size |
| PriceFeed | Oracle aggregation | Источники, spread logic |
| RewardRouter | Staking, APR дистрибуция | Emission schedule |
В GMX v1 кодовая база написана на Solidity 0.6.x. Форк обычно мигрирует на 0.8.x с явным overflow protection — убирает SafeMath бойлерплейт и включает встроенные проверки компилятора.
Сеть исполнения ордеров (keepers)
Для продакшн форка нужна keeper-инфраструктура: минимум 2-3 keeper с failover, мониторинг pending orders, автоматическое увеличение gas при застрявших транзакциях. Keeper — это не просто скрипт, это критическая инфраструктура. Если keeper не работает, ордера не исполняются, ликвидации не происходят, пул накапливает риск.
Мы строим keeper-систему на TypeScript с viem, Redis-очередью pending orders, Prometheus метриками и PagerDuty алертами. Execution latency должна быть <2 блока от момента появления исполнимой позиции.
Frontend и интеграция
GLP vault требует отдельного интерфейса для LP — статистика пул composition, текущий APR (trading fees + esGMX emissions), история P&L. Для трейдеров: charts через TradingView Lightweight Charts, позиции, ордера, история.
wagmi + viem для on-chain взаимодействия. The Graph subgraph для исторических данных — без него история позиций не восстанавливается. Subgraph для GMX-форка пишем кастомный: entities Position, Order, GlpMint, LiquidationEvent.
Процесс работы
Аналитика (1 неделя). Аудит целевого чейна (Arbitrum, Avalanche, Base — GMX-форки живут на L2 из-за газа), конкурентный анализ существующих perpetual DEX, токеномика: emission schedule GLP/GMX-аналогов, fee distribution.
Проектирование (1-2 недели). Адаптация контрактов, storage layout, список поддерживаемых активов, параметры риск-менеджмента (max leverage, max OI per market).
Разработка (6-10 недель). Smart contracts + keeper infrastructure + subgraph + frontend. Это параллельные треки.
Тестирование (2 недели). Fork-тесты на Arbitrum mainnet с симуляцией различных сценариев: cascade liquidation, oracle latency, keeper failure. Fuzz-тесты на PnL расчёт и liquidation logic.
Аудит. Обязателен внешний аудит перед mainnet — perpetual DEX с реальными средствами пула. Минимум 2 независимых аудитора.
Деплой и мониторинг. Поэтапный: сначала testnet с реальными keeper, затем mainnet с ограниченными позициями (position size cap на первые 30 дней).
Ориентиры по срокам
Форк GMX v1 на новый EVM чейн с кастомным составом пула — 2-3 месяца. Форк GMX v2 с полной keeper-системой и subgraph — 3-4 месяца. Сроки включают аудит и поэтапный запуск.
Стоимость рассчитывается после детальной оценки требований.