Розробка форку GMX для perpetual DEX

Розробка форку 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 прибутковість корелює з тим, скільки трейдерів гублять гроші. На бичому ринку багато лонгів — 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 механіка та 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 подіям.

Архітектура форку та що ми мінюємо

Ключові контракти

У GMX v1 кодова база написана на Solidity 0.6.x. Форк зазвичай мігрує на 0.8.x з явним overflow захистом — убирає SafeMath бойлерплейт та включає вбудовані проверки компілятора.

Мережа виконання ордерів (keepers)

Для production форку потрібна keeper-інфраструктура: мінімум 2–3 keeper з failover, моніторинг pending orders, автоматичне збільшення газу при застрявлих транзакціях. 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 для історичних даних — без нього історія позицій не відновлюється. Custom 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, список поддерживаемих активов, параметри risk-менеджменту (max leverage, max OI per market).

Розробка (6–10 тижнів). Smart contracts + keeper інфраструктура + subgraph + frontend. Це паралельні треки.

Тестування (2 тижні). Fork-тесты на Arbitrum mainnet з симуляцією різних сценаріїв: cascade liquidation, oracle latency, keeper failure. Fuzz-тесты на PnL розрахунок та liquidation логіку.

Аудит. Обов'язковий зовнішній аудит перед mainnet — perpetual DEX з реальними коштами пулу. Мінімум 2 незалежних аудитора.

Деплой та моніторинг. Поетапний: спочатку testnet з реальними keeper, потім mainnet з обмеженими позиціями (position size cap на перші 30 днів).

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

Форк GMX v1 на новий EVM чейн з кастомним складом пулу — 2–3 місяці. Форк GMX v2 з повною keeper-системою та subgraph — 3–4 місяці. Строки включають аудит та поетапний запуск.

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