HIP-3（Hyperliquid Improvement Proposal 3） запущено в основну мережу вже близько 3 місяців, з моменту запуску третій сторонній користувачі вже здійснили понад 130 мільярдів доларів угод на налаштованих ринках, що означає, що процес «оновлення» переходить від внутрішніх процедур біржі до базової інфраструктури, яку можуть безпосередньо викликати зовнішні розробники.
У централізованих біржах «оновлення» природно є платформеними повноваженнями: які активи можна торгувати, коли вони будуть запущені, які параметри встановлювати — все це визначається операційними та ризик-менеджмент процесами. Навіть у блокчейні, для таких базових інфраструктур, як perpetual контракти, часто обмеження накладаються через швидкість розгортання та управління кількох команд.
Ідея HIP-3 полягає в тому, щоб перетворити цей процес із «затвердження платформи» у «відкритий інтерфейс»: за умови виконання певних критеріїв, сторонні можуть розгортати нові perpetual ринки на одній платформі для торгівлі та розрахунків, делегуючи централізоване право на «оновлення» систематизованим способом екосистеми. Це не лише знижує бар’єри для інновацій, а й підсилює масштабованість ринку. Однак відкриття інтерфейсів несе потенційні ризики безпеки, тому важливо забезпечити відповідність операцій цим ринкам та відсутність зловмисних дій — це ключові питання у дизайні HIP-3.
0x1 Hyperliquid: основа HIP-3
Hyperliquid — це інфраструктура для perpetual торгівлі, що працює на власному блокчейні. Для HIP-3 найважливіше — це те, що: механізм торгівлі, розрахунки та кліринг забезпечуються єдиною базою протоколу, що дозволяє повторно використовувати можливості ринку, а не створювати з нуля нову торгову систему.
Hyperliquid використовує двошарову архітектуру: #HyperCore：为合约交易优化的定制化 L1 区块链，每秒可处理 20 万笔订单，并具备确定性最终性。#HyperEVM: рівень застосунків, здатний виконувати смарт-контракти, сумісний з EVM.
Внутрішній ринок perpetual (validator-operated perps) у Hyperliquid досі більше схожий на традиційний процес централізованих бірж: офіційні особи самостійно додають perpetual контракти відповідно до волі спільноти; зняття з торгів — за рішенням валідаторів шляхом голосування.
Протокол Hyperliquid підтримуватиме розгортання перпів, створених сторонніми розробниками ((HIP-3)), що є важливим кроком до повної децентралізації процесу додавання нових контрактів.
Протокол Hyperliquid підтримуватиме розгортання perpetual контрактів сторонніми розробниками (HIP-3), що є ключовою віхою до повної децентралізації процесу їхнього додавання.
0x2 HIP-3: ринки, розгорнуті розробниками
Ідея HIP-3 дуже проста: без зміни базової платформи Hyperliquid для торгівлі та клірингу, надати можливість додавати нові perpetual ринки тим, хто відповідає певним умовам. Розробник відповідає за визначення ключових параметрів ринку та цінових джерел/операційних обов’язків, протокол же використовує єдину систему гарантій та механізм клірингу для виконання та управління ризиками; таким чином, «оновлення» перетворюється з внутрішнього процесу платформи у стандартний виклик API.
Простими словами: розробник може запустити perpetual ринок на базі двигуна HyperCore, самостійно встановлювати цінові дані та налаштовувати параметри ринку.
Обов’язки розробника: у HIP-3 розробник відповідає за два типи робіт щодо одного ринку (market): визначення ринку та його операційне управління.
Визначення ринку (Market definition): офіційно це зводиться до визначення oracle та специфікацій контракту. На практиці це включає, щонайменше:
Oracle definition: включає початковий oraclePx та визначення джерела цін. Розробник при визначенні ринку має чітко визначити актив або джерело даних, яке має бути економічно обґрунтованим, важко маніпулювати та має мати чіткий об’єкт. При реєстрації активу потрібно надати початковий oraclePx.
Специфікація контракту: у API чітко визначені параметри ринку, такі як «символ активу / мінімальна одиниця замовлення / максимальний леверидж» (coin, szDecimals, maxLeverage).
Вибір DEX: спершу розробник розгортає DEX для perpetual контрактів (кожен DEX має окремий гарантійний фонд, книгу ордерів, налаштування deployer), а також може обрати будь-який актив для забезпечення (наприклад, USDC), що буде використовуватися як заставна валюта для цього ринку.
Операції з ринком (Market operation): офіційно це — налаштування цін oracle / обмеження левериджу / розрахунок розрахунків, якщо потрібно, — детальніше:
Оновлення цін: через API setOracle постійно оновлювати oraclePx для ринку.
Обмеження левериджу: через налаштування таблиці гарантій (margin table) для активу обмежити максимальний леверидж — він встановлюється залежно від розміру позиції.
За потреби — кліринг: розробник може використовувати API haltTrading для зупинки ринку, ініціюючи кліринг — скасування всіх ордерів, розрахунок позицій за поточною mark price; цей же механізм може використовуватися для відновлення торгів.
Зараз HIP-3 підтримує лише ізольовані позиції (isolated-only), у майбутньому можливо — підтримка cross margin.
Повний процес запуску ринку
-
Stake: вимагається, щоб розробник тримав у стейкінгу 500k HYPE; навіть якщо він зупинить всі свої ринки, вимога залишається протягом 30 днів.
-
Build: після досягнення порогу, розробник може розгорнути DEX для perpetual контрактів. Кожен DEX — це окрема торгова зона: окремий гарантійний фонд, книга ордерів, налаштування deployer.
-
Встановлення застави (collateral): заставою для цього DEX може бути будь-який quote asset, але якщо цей актив втратить статус permissionless quote asset (рішення валідаторів), використання його як застави для DEX буде заборонено.
-
Додати ринки: перші 3 ринки можна розгорнути безпосередньо; для додавання нових потрібно буде пройти Dutch auction для отримання «додаткових квот».
-
Операція з ринками: після запуску ринків, робота розробника зводиться до «стабільної роботи» ринків.
-
Unstake: коли всі ринки на DEX будуть закриті та розраховані, можна зняти стейкінг 500k HYPE, але при цьому процес розблокування займе 7 днів, під час яких стейк може бути штрафований або конфіскований.
Dutch auction: поточний цикл триває 31 годину, стартова ціна — у 2 рази вища за ціну останньої угоди (ціна/мінімальна ціна).
setOracle: три типи цінових входів
У HyperCore oracle price використовується для фіксації та розрахунку funding, а mark price — для маркування гарантій та розрахунків клірингу (також для TP/SL).
У внутрішньому ринку mark price — це не безпосередній результат оновлення oraclePx, а медіана трьох цін:
oraclePx + EMA(midPx - oraclePx)
медіана (best bid, best ask, last trade) (локальні ціни ордер-бука)
вагова медіана цін між кількома CEX perpetual контрактами (perp mid prices)
На HIP-3 роль oracle price та mark price не змінилася, але механізм їхнього обчислення — так.
1. Вхідні дані setOracle
a. oraclePx ()обов’язково)
Основне визначення відповідає HyperCore.
b. markPx ((опційно))
Можна подати 0–2 зовнішніх цін mark price для розрахунку.
c. externalPerpPx ((обов’язково)
Як орієнтир для mark price, щоб запобігти різким відхиленням.
Розробник зазвичай розгортає relayer для оновлення цін, oraclePx обчислюється з зовнішніх джерел; markPx — алгоритмом relayer; externalPerpPx — вагомою медіаною цін кількох CEX.
2. Реальний mark price
HIP-3 не використовує безпосередньо оновлення oraclePx для визначення mark price:
Обчислюємо local mark: медіана )best bid, best ask, last trade###.
Об’єднуємо local mark та обрані зовнішні цінові групи (0–2), беремо медіану — отримуємо новий mark price.
3. Обмеження setOracle
Частота оновлень: не менше ніж через 2.5 секунди між викликами, якщо за 10 секунд markPx не оновиться — повертаємо local mark.
Діапазон коливань: кожне оновлення markPx не більше ±1%; всі ціни обмежуються у межах 10-кратної від ціни відкриття дня.
(# 7×24H та не 7×24H: різниця у механізмах ціноутворення
У HIP-3 perpetual ринки підтримують активи, які можна додавати цілодобово (7×24H) або лише у визначені години (не 7×24H). Це зумовлює різницю у способах отримання цін.
Для активів 7×24H (наприклад, BTC) ціна може отримуватися з CEX/DEX або довірених оракулів:
![图片])https://img-cdn.gateio.im/webp-social/moments-b08d44279708b862b9599dc0464dec7e.webp###
Для не 7×24H активів (наприклад, акції), ціна доступна лише під час відкриття ринку, і для підтримки цілодобової роботи потрібно використовувати інший механізм ціноутворення у час закриття.
Наприклад, для perpetual контрактів на акції на trade.xyz:
Під час відкриття ринку — використовуються стабільні ціни з зовнішніх оракулів, таких як Pyth.
Під час закриття — ціна базується на останньому закритті та внутрішніх ордерах, з обмеженням коливань у межах 1/max_leverage (наприклад, Tesla 10x — 10%).
(# Кліринг
HIP-3 переважно використовує логіку клірингу HyperCore, тому механізм клірингу — стандартний: коли чиста вартість позиції (isolated position value) недостатня для покриття мінімального гарантійного внеску, позиція стає кліринговою.
Клірингова ціна визначається не за окремою угодою, а за mark price.
Формула ціни клірингу:
![图片])https://img-cdn.gateio.im/webp-social/moments-f74c534a2be0f8301c5cf678261fc04d.webp(
side = 1 (long), -1 (short)
l — це коефіцієнт підтримки гарантійного внеску
![图片])https://img-cdn.gateio.im/webp-social/moments-43ed3e020660f17493f6412f8c8e651a.webp(
Мінімальний леверидж (MAINTENANCE_LEVERAGE) — залежить від рівня гарантійного забезпечення (margin tier): спочатку визначаємо його з таблиці гарантій (mmr):
![图片])https://img-cdn.gateio.im/webp-social/moments-0f3e321d617792925cf80f0754b2fbbb.webp(
Якщо є рівні (tiers), ціна клірингу — це ціна, при якій номінальна вартість позиції потрапляє у відповідний рівень.
margin_available
isolated: isolated_margin - maintenance_margin_required
Після входу у стан клірингу, система спершу закриває позиції за ринковою ціною через ордербук; якщо ризик зменшується — залишок гарантійного внеску залишається у трейдера.
Але при недостатній глибині або різкому проскакуванні ціни ціна закриття може суттєво відрізнятися від mark price, що створює «прогалину клірингу».
Значення isolated position value — це чиста вартість позиції у поточному mark price (з урахуванням прибутків/збитків), зменшена на гарантійний внесок.
ADL (Auto-Deleveraging):
У разі, коли isolated position value стає від’ємним, активується механізм ADL — автоматичне зменшення позицій з протилежних сторін за пріоритетом прибутковості та використанням левериджу, щоб закрити позиції за попереднім mark price, запобігаючи системним збиткам.
Порядок сортування:
![图片])https://img-cdn.gateio.im/webp-social/moments-c56af6a39a50ee7b052f4b33e83a5eda.webp(
previous mark price: ціна, за якою система зафіксувала попередній mark price перед ADL.
Приклад:
Перед запуском ADL, mark price = 3000.
Через обмеження setOracle, новий mark price не може перевищувати 2970 (-1%).
Якщо ордербук має слабкий попит, і при цьому ціна закриття — 2910 (на 3% нижче), то позиція може бути закрита з убитком, що призведе до «прогалини» — і активується ADL.
ADL підбирає позиції з протилежної сторони (з прибуткових коротких), закриваючи їх за previous mark price = 3000, щоб компенсувати прогалину, що створює пасивний прибуток для протилежної сторони.
![图片])https://img-cdn.gateio.im/webp-social/moments-46485922603bcc451881e82987685518.webp(![图片])https://img-cdn.gateio.im/webp-social/moments-3f11b34efd760ad2a07f657c92b39ba7.webp(
https://x.com/bartdothl/status/2000292798755684839
Ризики та обмеження: можливі сценарії відповідальності та ключові ризики
Механізм штрафів (Slashing): відповідальність
HIP-3 делегує «оновлення та управління» стороннім розробникам, але одночасно закладає у протокол правила штрафування: розробник має стейкати HYPE, і у разі неправомірної діяльності валідатори можуть голосувати за штраф і знищення (burn) його стейку.
Вимоги до стейку
На основній мережі потрібно тримати 500k HYPE у стейкінгу; навіть якщо розробник зупинить всі свої ринки, вимога залишається протягом 30 днів (відповідальність не знімається миттєво).
Процедура та голосування
У разі зловмисних дій валідатори можуть ініціювати та виконати голосування за штрафування (stake-weighted vote), щоб вирішити, чи знімати стейк з розробника.
Критерії оцінки
Офіційно: штрафи не залежать від причин — «зловмисність», «недостатня компетентність», «крадіжка ключів» — головне, щоб поведінка розробника спричинила невалідний стан, довгий простій або деградацію продуктивності.
Розмір штрафу
Розмір штрафу визначається голосуванням валідаторів, з урахуванням максимуму:
— до 100% у разі втрати валідності або тривалого простою
— до 50% у разі короткочасного простою
— до 20% при деградації продуктивності
Зняті штрафом токени знищуються, а не повертаються користувачам.
Ризики параметрів
setOracle
Ціни oracle зазвичай беруться з relayer серверів розробника, що створює централізований ризик: при компрометації приватних ключів або DDoS-атаках ціна може бути зманіпульована або довгий час відхилена.
haltTrading
Розробник може викликати haltTrading для скасування всіх ордерів у ринку та закриття позицій за поточною mark price.
Цю функцію слід використовувати обережно, наприклад, у таких випадках:
при підозрі на злом або маніпуляцію ринком, виклик haltTrading може закрити позиції за ціною mark, що може призвести до реальних прибутків зловмисника, а також до великих збитків.
setMarginTableIds / InsertMarginTable
InsertMarginTable: визначає нову таблицю гарантій, що містить вимоги до гарантій та максимальний леверидж для певного активу.
setMarginTableIds: прив’язує ринок до конкретної таблиці гарантій.
Для ринків з низькою ліквідністю або слабкою маркет-мейкерською здатністю високий max leverage може збільшити ймовірність активізації ADL.
Резке перемикання marginTableId — це зміна рівня гарантій, що може викликати масове зняття гарантій і ланцюгові кліринги.
setMarginModes
Зараз HIP-3 підтримує лише ізольований маржін (isolated margin), у майбутньому можливо — підтримка cross margin. Внутрішній DEX може мати високоліквідний та низьколіквідний ринок, і режим cross margin може поширювати ризики з низьколіквідних ринків на високоліквідні. Тому до вирішення цієї проблеми офіційно не рекомендується вводити cross margin.
Ризики оракулів
Для активів 7×24H основний ризик — це залежність від точності та стабільності зовнішніх оракулів, а також централізованих relayer серверів.
Для не 7×24H активів — більший ризик у тому, що у неробочий час ціна може бути недоступною або некоректною, що ускладнює підтримку цілодобової роботи.
Наприклад, на trade.xyz у неробочий час використовуються останні зовнішні ціни та внутрішні ордер-буки. У вихідні, коли ринок акцій малоліквідний і немає зовнішніх цін, ціна базується на останньому закритті та внутрішніх ордерах, з обмеженням коливань у 1/max_leverage. Це може спричинити масові кліринги або ADL.
14 грудня 2025 року на trade.xyz сталася маніпуляція з XYZ100-USDC, що привела до значного розриву ціни та масових клірингів.
![图片])https://img-cdn.gateio.im/social/moments-46485922603bcc451881e82987685518(![图片])https://img-cdn.gateio.im/social/moments-3f11b34efd760ad2a07f657c92b39ba7(
https://x.com/bartdothl/status/2000292798755684839
З іншого боку, у неробочий час відсутня стабільна ціна, і ринок може залежати лише від останньої зовнішньої ціни та внутрішніх ордерів, що створює ризик різких цінових скачків при відкритті ринку.
При цьому, якщо ціна різко змінюється, система може бути змушена застосовувати clamp, що призводить до розриву між ціною зовнішнього ринку та внутрішньою ціною, або швидко переоцінювати ціни при поверненні до зовнішнього орієнтиру, що може спричинити додаткові кліринги та ADL.
![图片])https://img-cdn.gateio.im/social/moments-43ed3e020660f17493f6412f8c8e651a( Ризик-менеджмент
- Стабільність ціноутворення
a. Втрата oracle ціни
Моніторинг:
— безпосередньо через on-chain показники визначати, чи блокуються оновлення oracle:
![图片])https://img-cdn.gateio.im/webp-social/moments-0b00e6148b093547c349b784ee8a5d73.webp)
Поріг:
Дія:
Рівень 1: перевірка здоров’я relayer, перемикання на резервний relayer, попередження.
Рівень 2: зменшення OI cap через setOpenInterestCaps.
b. Відхилення ціни
Моніторинг:
![图片])https://img-cdn.gateio.im/webp-social/moments-7c1c3c62517dea1a5e3d2212cf94d88e.webp(
Поріг:
Рівень 1: при перевищенні порогів у 2 з 3 показників
Рівень 2: при перевищенні у 3 з 4 та тривалості понад X секунд
Дія:
Рівень 1: зменшення OI cap
Рівень 2: оновлення таблиць гарантій, зниження max leverage, активація clamp
Рівень 3: попередження, можливо — зупинка торгів (haltTrading)
- Моніторинг ордер-бука
a. Аналіз глибини
— моніторинг depth_band, spread, aggressiveVolume_Δt, impact_ratio
— при виявленні ризиків — зменшення OI cap, зниження левериджу, примусове закриття високоризикових позицій.
b. Фальшиві ордери
— при різкому зростанні та падінні depth_band — зменшення OI cap або зупинка ринку.
- Моніторинг позицій
— аналіз швидкості зростання OI, концентрації позицій, прибутковості/збитковості — для виявлення потенційних ризиків «передавання» ринку у стан, що сприяє великим клірингам або ADL.
— при високих значеннях — попередження або обмеження.
![图片])https://img-cdn.gateio.im/social/moments-0f3e321d617792925cf80f0754b2fbbb( Підсумок
Головна ідея HIP-3 — це перетворити процес додавання нових ринків із «затвердження» у «стандартний виклик API», що дозволяє розробникам запускати свої DEX, спочатку безкоштовно, а потім через аукціон отримувати більше квот, перетворюючи розширення ринків із «очікування затвердження» у «згідно з правилами».
Проте важливо розуміти, що HIP-3 не усуває ризики, а лише змінює їхню форму та місце: частина ризиків тепер залежить від якості введення даних та операційної діяльності розробника — правильність оновлення цін, вибір markPx, рівні гарантій, ціноутворення у неробочий час, а також можливість застосування haltTrading, що може призвести до концентрації клірингів і ADL.
Основна ідея протоколу — це перетворити повноваження у відповідальність: делегування через стейкінг і голосування валідаторів, а також обмеження цін та левериджу (clamp, оновлення, волатильність, ізольовані позиції), щоб зменшити ризики виходу за межі контролю. В результаті HIP-3 — це не стільки «більше розширення», скільки «більше стандартів», що дозволяє безпечно масштабуватися.
Протокол має забезпечити, щоб «розширення» відбувалося за правилами, а ризики — були під контролем, — через механізми відповідальності, обмеження та моніторинг. Відповідальною реалізацією HIP-3 є створення системи, що дозволяє запускати нові ринки, але з гарантією їхньої безпеки та стабільності, — і це залежить від якості оракулів, параметрів левериджу, ризик-менеджменту та моніторингу у реальному часі. Якщо ви плануєте використовувати HIP-3 для створення ринкових правил, параметрів або систем попереджень — звертайтеся до BlockSec.
