Розробка форку GMX для perpetual DEX
Ми розробляємо форки GMX для perpetual DEX, адаптуючи архітектуру під конкретні вимоги. GMX — це не просто протокол, а перевірена архітектура: пул GLP як контрагент, zero-price-impact виконання ордерів (до певного порогу) та оракульні ціни замість orderbook. Форк GMX — це не "скопіювати контракти", а зрозуміти систему управління ризиком між LP та трейдерами, і адаптувати її під ваші цілі.
Наш досвід у блокчейн-розробці перевищує 10 років, ми успішно розгорнули 5+ форків GMX на L2-мережах і забезпечили їхню стабільну роботу з uptime keeper-мережі 99.9%. Замовте розробку форку GMX у нас — ми проведемо аудит ваших вимог і запропонуємо оптимальне архітектурне рішення.
Як GLP управляє ризиком?
У GMX v1 провайдери ліквідності вносять активи в GLP vault — мультиактивний пул, що виступає контрагентом для трейдерів. Коли трейдер відкриває long на ETH, він бере ETH у GLP в борг (через механіку reserved amount). При зростанні ціни GLP втрачає, трейдер виграє, і навпаки. GLP profitability корелює з відсотком збиткових трейдерів. Баланс тримається на комісіях та розмірі відкритих позицій.
При форку потрібно явно вирішити: які активи входять у пул, яка максимальна алокація на кожен (у GMX: ETH ~35%, BTC ~25%, stablecoins ~40%), і як управляється ребалансинг через динамічні mint/redeem комісії. Неправильний баланс алокацій веде до ризику банкрутства пулу при направленому тиску ринку.
Чому важливий захист від oracle-маніпуляцій?
GMX використовує Chainlink + Binance/Coinbase price aggregation з bid/ask спредом. Spread між ними — основний механізм захисту. Позиція відкривається по ask, закривається по bid. У GMX v2 з'явився синтетичний ринок через GLV vault та keeper-система, що усуває MEV.
Якщо використовувати тільки Chainlink без власного price aggregator, latency 1-3 блоки при екстремальній волатильності створює вікно для price arbitrage. Раніше кілька форків GMX v1 втратили кошти через це — трейдери відкривали позиції, знаючи наступну ціну оракула. Ми використовуємо мульти-оракульну агрегацію з динамічним спредом та моніторингом відхилень.
Які ризики несе форк GMX?
Основні ризики: oracle-арбітраж при волатильності, bad debt від неліквідованих позицій, збій keeper-мережі, неоптимальний баланс GLP-пулу. Наприклад, при black swan події без ADL (Auto-Deleveraging) пул може стати неплатоспроможним. Ми мінімізуємо ризики через резервні keepers, fuzz-тестування та строгі параметри ризик-менеджменту.
Як запобігти bad debt та ліквідаціям?
У GMX позиція ліквідується коли losses + fees перевищують collateral мінус liquidationFeeUsd. Проблема: при екстремальних рухах позиція може піти в негативний collateral швидше, ніж keeper встигає ліквідувати — виникає bad debt. У v2 це вирішується через ADL: при високому 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 і включаючи вбудовані перевірки компілятора.
Що таке keeper-інфраструктура?
Для продакшн форку потрібна keeper-інфраструктура: мінімум 2-3 keeper з failover, моніторинг pending orders, автоматичне збільшення gas при застряглих транзакціях. Keeper — критична інфраструктура: якщо він не працює, ордери не виконуються, ліквідації не відбуваються, пул накопичує ризик. Ми будуємо keeper-систему на TypeScript з viem, Redis-чергою pending orders, Prometheus метриками та PagerDuty алертами. Execution latency повинна бути <2 блоків від моменту появи виконуваної позиції.
Технічні деталі архітектури keeper
Keeper моніторить події IncreasePositionRequest та DecreasePositionRequest. При появі нової події формує мультикол з викликом executeIncreasePosition або executeDecreasePosition. Для уникнення гонок використовує Redis-лок на кожну позицію. У разі помилки (наприклад, out-of-gas) повторює з підвищеним gas price.
Порівняння версій GMX
| Параметр | GMX v1 | GMX v2 |
|---|---|---|
| Ліквідація | Keeper-виклик | Keeper + ADL |
| Oracle | Chainlink + агрегація | Синтетичні ринки |
| Комісія | 0.1% торгівлі | Динамічна |
| Склад пулу | Фіксовані ваги | Гнучкий кошик |
Що входить у роботу
- Аудит та документація смарт-контрактів
- Налаштування keeper-інфраструктури з моніторингом
- Інтеграція The Graph subgraph для історії позицій
- Адаптація frontend (TradingView, wagmi, viem)
- Навчання команди та підтримка після запуску
Процес роботи
Аналітика (1 тиждень). Аудит цільового чейну (Arbitrum, Avalanche, Base — GMX-форки живуть на L2 через газ), конкурентний аналіз, токеноміка.
Проектування (1-2 тижні). Адаптація контрактів, storage layout, список активів, параметри ризик-менеджменту (max leverage, max OI per market).
Розробка (6-10 тижнів). Smart contracts + keeper infrastructure + subgraph + frontend.
Тестування (2 тижні). Fork-тести з симуляцією cascade liquidation, oracle latency, keeper failure. Fuzz-тести PnL та liquidation logic.
Аудит. Два незалежних зовнішніх аудитори перед mainnet.
Деплой та моніторинг. Спочатку testnet з реальними keeper, потім mainnet з обмеженими позиціями на перші 30 днів.
Орієнтири за термінами та вартістю
Форк GMX v1 на новий EVM чейн з кастомним складом пулу — 2-3 місяці. Форк GMX v2 з повною keeper-системою та subgraph — 3-4 місяці. Терміни включають аудит та поетапний запуск. Вартість розраховується індивідуально: бюджет типового форку може знаходитися в діапазоні від $50,000 до $100,000 залежно від складності інтеграцій та необхідної кастомізації.
За даними документації GMX, GLP пул використовує мультиактивний кошик з динамічною алокацією.
Зв'яжіться з нами для консультації — ми допоможемо оцінити обсяг робіт та запропонуємо оптимальне рішення під ваш проект.