Написано: Blocksec
HIP-3 (Hyperliquid Improvement Proposal 3) запущений у основну мережу вже близько 3 місяців, з моменту запуску третій сторонній користувачі вже створили понад 130 мільярдів доларів торгів за допомогою налаштованих ринків, що означає, що «оновлення» переходить від внутрішніх процесів біржі до базової інфраструктури, яку можуть безпосередньо викликати зовнішні розробники.
У централізованих біржах «оновлення» природно є платформеними повноваженнями: які активи можна торгувати, коли вони запускаються, як налаштовувати параметри — все це визначається операційними та ризик-менеджмент процесами. Навіть у блокчейні, продукти з довгостроковими контрактами, як perpetuals, часто обмежені темпами розгортання та управління невеликих команд.
Інновація HIP-3 полягає в тому, що це перетворює процес із «затвердження платформи» у «відкритий інтерфейс»: за умови виконання певних критеріїв, сторонні можуть розгортати нові perpetual ринки на одній платформі для торгівлі та розрахунків, дозволяючи централізоване «оновлення» систематизувати та делегувати екосистемі. Це не лише знижує бар’єри для інновацій, а й підсилює масштабованість ринку. Однак відкриття інтерфейсів несе потенційні ризики безпеки, тому важливо ретельно контролювати операційну відповідність та відсутність зловмисних дій у таких ринках — це ключові питання у дизайні HIP-3.
0x1 Hyperliquid: основа HIP-3
Hyperliquid — це інфраструктура для perpetual торгівлі, що працює на власному ланцюгу. Для HIP-3 найважливіше — це те, що: механізми торгівлі, розрахунків та клірингу забезпечуються єдиною базою протоколу, що дозволяє повторно використовувати можливості ринку, а не створювати з нуля нову торгову систему.
Hyperliquid використовує двошарову архітектуру:
HyperCore: кастомізований L1 блокчейн, оптимізований для контрактної торгівлі, здатний обробляти до 200 000 ордерів за секунду та має детерміновану кінцевість.
HyperEVM: рівень застосунків, що підтримує запуск смарт-контрактів та сумісний з EVM.
Ринкові продукти Hyperliquid (validator-operated perps) при запуску більше схожі на традиційні централізовані біржі: офіційні особи самостійно додають perpetual контракти відповідно до волі спільноти; а зняття — рішення валідаторів шляхом голосування.
Протокол Hyperliquid підтримуватиме розгортання perpetuals, створених сторонніми розробниками (HIP-3), що є важливим кроком до повної децентралізації процесу лістингу.
Протокол Hyperliquid підтримуватиме розгортання perpetual контрактів сторонніми розробниками (HIP-3 — це ключова віхта для досягнення повної децентралізації процесу лістингу).
0x2 HIP-3: ринки, розгорнуті розробниками
Ідея HIP-3 дуже проста: без зміни базової платформи Hyperliquid для торгівлі та розрахунків, відкривається можливість створювати «нові perpetual ринки» для тих, хто відповідає умовам. Розробник відповідає за визначення ключових параметрів ринку та цінування/операційні обов’язки, протокол же використовує єдину систему маржі та механізм клірингу для виконання та управління ризиками; таким чином, «оновлення» перетворюється з внутрішнього процесу платформи у стандартний виклик API.
Проще кажучи: розробник може створити perpetual ринок на базі HyperCore, самостійно налаштовуючи цінову політику та параметри ринку.
Обов’язки розробника (Builder)
У HIP-3 розробник відповідає за два типи робіт із перп-ринками (market): визначення ринку та його операційне управління.
Визначення ринку (Market definition):
Офіційно цю частину описують як oracle definition + contract specifications. На практиці це включає:
Визначення oracle:
— включає початкове значення oraclePx та джерело цін. Розробник при створенні ринку має чітко визначити актив або джерело даних із зрозумілими, важко маніпулювати та з економічною сутністю характеристиками; при реєстрації активу потрібно надати початкове значення oraclePx.
Специфікація контракту:
— у API чітко визначені параметри ринку, такі як «символ активу / мінімальний розмір ордеру / максимальний леверидж» (coin, szDecimals, maxLeverage тощо).
Вибір DEX:
— розробник спершу розгортає DEX для perpetuals (кожен DEX має окремий маржін, книгу ордерів, налаштування), а також може обрати будь-який quote asset (наприклад USDC) як заставу для цього DEX. Кожен perpetual ринок відповідає одному DEX.
Операційна частина (Market operation):
Офіційно зазначено, що це включає налаштування цін oracle / обмеження левериджу / розрахунок розрахунків, якщо потрібно, — детальніше:
Оновлення цін:
— через функцію setOracle для постійного оновлення ціни oracle.
Обмеження левериджу:
— через налаштування відповідної таблиці маржі (margin table), що обмежує максимальний леверидж — він динамічно залежить від розміру позиції.
Необхідна кліринга:
— розробник може зупинити ринок через haltTrading, ініціюючи кліринг — скасовуючи всі ордери та розраховуючи позиції за поточною mark price; цей же механізм може використовуватися для відновлення торгів.
Зараз HIP-3 підтримує лише ізольовані позиції (isolated-only), у майбутньому можливо — підтримка cross margin.
Повний процес запуску ринку
- Stake
Розробник має внести 500 000 HYPE у заставу; навіть якщо всі його ринки будуть зупинені, вимога залишається протягом 30 днів.
- Build
Після досягнення порогу застави, розробник може розгорнути перп DEX. Кожен DEX — це окрема торгова зона: ізольована маржа, книга ордерів, налаштування.
- Встановлення застави (collateral)
Застава для DEX може бути будь-яким quote asset, але якщо цей актив втратить статус permissionless quote asset (рішення валідаторами), використання його як застави буде заборонено.
- Додати ринки
Перші 3 ринки можна розгорнути безпосередньо; для додавання нових ринків потрібно пройти Dutch auction для отримання «додаткових квот».
- Операція ринків
Після запуску ринку, робота розробника зводиться до «стабільної роботи» ринку.
- Виведення застави (Unstake)
Після того, як всі ринки будуть закриті та розраховані, заставу у 500k HYPE можна буде зняти. Після ініціації unstake, процес триватиме 7 днів у черзі, під час яких заставу можна буде штрафувати або конфісковувати.
Dutch auction: поточний цикл триває 31 годину, стартова ціна — у 2 рази вища за останню (торгівельну або мінімальну).
SetOracle: три типи цінових входів
У HyperCore ціна oracle використовується для фіксації та розрахунку funding, а mark price — для маркування цін для ризик-менеджменту, розрахунків та тригерів TP/SL.
У внутрішньому ринку mark price — це не безпосередній результат feed, а медіана трьох цін:
oraclePx + EMA(midPx - oraclePx)
median(best bid, best ask, last trade) (локальні ціни ордер-борду)
середньозважена ціна між кількома CEX perpetuals (perp mid prices)
З HIP-3 роль oracle та mark price не змінилася, але механізм обчислення — так.
setOracle приймає:
a. oraclePx (обов’язково))
— визначається так само, як у HyperCore.
b. markPx (може бути необов’язковим)
— можна подати 0–2 зовнішніх значень mark price для розрахунку.
c. externalPerpPx (обов’язково)
— використовується як орієнтир для запобігання різким відхиленням mark price.
Розробник зазвичай розгортає relayer для feed, тоді:
— oraclePx обчислюється relayer-ом за зовнішніми джерелами.
— markPx — за власним алгоритмом relayer.
— externalPerpPx — за середньою ціною кількох CEX.
Фактичний mark price
HIP-3 не використовує безпосередньо feed для mark price, а обчислює його так:
— локальний mark: median(best bid, best ask, last trade).
— новий mark price — це медіана між локальним mark та 0–2 зовнішніми значеннями markPx.
Обмеження setOracle
Частота оновлень: не менше ніж через 2.5 секунди між викликами; якщо за 10 секунд markPx не оновиться, воно повернеться до локального mark.
Діапазон коливань: markPx не може змінюватися більш ніж на ±1%; всі ціни обмежені в межах 10-кратної від ціни відкриття дня.
7×24H та не 7×24H: механізми ціноутворення
У HIP-3 perpetual ринки підтримують активи, які можна поділити на 7×24H (торгівля цілодобово) та не 7×24H (торги лише у визначені години). Це визначає різницю у способах отримання цін.
Для 7×24H активів (наприклад BTC) ціна може отримуватися з CEX/DEX або довірених оракулів:
Для не 7×24H активів (наприклад, акцій) — ціна доступна лише під час відкриття ринку, і для підтримки роботи цілодобово потрібно використовувати інший механізм ціноутворення під час закриття.
Приклад: perpetual акції на trade.xyz
— під час відкриття ринку використовуються зовнішні оракули (наприклад Pyth).
— під час закриття — ціна базується на останньому закритті, з урахуванням внутрішніх ордерів, з обмеженням коливань у межах 1/max_leverage (наприклад, Tesla 10x — 10%).
Ліквідація
HIP-3 переважно використовує логіку клірингу HyperCore: коли вартість позиції (isolated position value) падає нижче за рівень підтримки, активується механізм ліквідації.
Ліквідація базується на mark price, а не на окремій транзакції.
Формула ліквідаційної ціни:
side = 1 (long), -1 (short)
l — це рівень підтримки (maintenance margin rate)
Мінімальна маржа (maintenance margin) визначається відповідною категорією позиції.
Якщо є градації (tiers), ліквідаційна ціна підбирається відповідно до рівня.
margin_available
— для ізольованих позицій: isolated_margin - maintenance_margin_required.
Після входу у стан ліквідації, система спершу закриває позицію за ринковою ціною через ордер-кільце; якщо вдається повернути ризик у безпечну зону — залишок маржі залишається трейдеру.
Однак при недостатній глибині або різкому проскакуванні ціна може значно відрізнятися від mark price, що спричиняє «прогалину ліквідації».
Isolated position value — це чиста вартість позиції за поточною mark price (з урахуванням прибутків/збитків і маржі).
ADL (Auto-Deleveraging)
У разі, коли isolated position value стає від’ємним, активується механізм ADL, що автоматично зменшує ризик:
— при негативній позиції система починає зменшувати позиції у порядку прибутковості та левериджу, використовуючи попередній mark price, щоб закрити або зменшити позиції, запобігаючи системним збиткам.
Приклад: якщо mark price обмежений у межах ±1% від попереднього, і ціна різко проскакує — система може зафіксувати збитки, що призведуть до активування ADL.
0x3 Ризикові аспекти та обмеження:
Механізми відповідальності та ключові ризики
Механізм штрафів (Slashing): відповідальність
HIP-3 делегує «оновлення та управління» розробнику, але одночасно вводить штрафи у протоколі: розробник має заставу HYPE, і у разі неправомірної діяльності валідатори можуть голосувати за штраф і знищення застави.
Вимоги до застави
— 500 000 HYPE на основному ланцюгу, навіть якщо всі ринки будуть зупинені, — протягом 30 днів.
Голосування та рішення
— при підозрі на зловмисні дії валідатори можуть ініціювати голосування з вагомістю за заставою, щоб вирішити про штраф.
Принципи оцінки
— штрафи застосовуються незалежно від причин (злом, недбалість, злом приватних ключів), головне — чи спричинили дії протоколу стан безладу, довгий простій або деградацію.
Розмір штрафу
— визначається голосуванням валідаторів, з верхньою межею:
— до 100% у разі серйозних збоїв або довгого простою
— до 50% при короткочасних збоїх
— до 20% при деградації продуктивності
Заставні токени, що підлягають штрафу, знищуються, а не повертаються користувачам.
Ризики параметрів
setOracle
Ціни oracle зазвичай надходять із relayer-сервера розробника, що створює централізований ризик: при компрометації приватного ключа або DDoS-атаці ціна може бути зманіпульована або довгий час відхилена.
haltTrading
Розробник може зупинити торги через haltTrading, закриваючи всі ордери за mark price. Це слід використовувати обережно, оскільки:
— при атаці зловмисника, що маніпулює ринком, виклик haltTrading може закрити позиції за ціною, що дає змогу зловмиснику отримати прибуток або спричинити збитки.
setMarginTableIds / InsertMarginTable
— InsertMarginTable: визначає нову таблицю маржі з вимогами та максимальним левериджем.
— setMarginTableIds: прив’язує ринок до конкретної таблиці.
Неправильне налаштування або надмірне підвищення левериджу для малоліквідних ринків може спричинити часті активізації ADL або раптові ліквідації.
Різке перемикання marginTableId може змінити рівень підтримки маржі, що призведе до масових ліквідацій.
setMarginModes
Зараз HIP-3 підтримує лише ізольовану маржу (isolated margin), у майбутньому можливо — підтримка cross margin. Внутрішній DEX з високою та низькою ліквідністю може мати різні режими, і перехід до cross margin може поширювати ризики.
Ризики оракулів
Для активів 7×24H — основний ризик у точності та стабільності зовнішніх джерел даних та централізованих relayer.
Для не 7×24H активів — ризик у отриманні або обчисленні ціни під час закриття ринку. Внутрішні механізми ціноутворення, як-от використання останньої ціни або обмеження коливань, можуть не враховувати реальні ринкові умови.
Приклад: у trade.xyz у періоди без торгівлі ціна базується на останньому закритті та внутрішніх ордерах, що може спричинити значні відхилення під час відкриття.
У 2025 році, 14 грудня, на trade.xyz сталася маніпуляція з XYZ100-USDC, що привела до сильного відхилення ціни та масових ліквідацій.
Ризик у відсутності стабільних зовнішніх цін у неробочий час, що може спричинити різкі коливання при відкритті ринку або неправильне ціноутворення через внутрішні механізми.
Загалом, відсутність зовнішніх цінових джерел у неробочий час може спричинити значні коливання та системні ризики.
0x4 Стратегії контролю ризиків
- Стабільність ціни oracle
Для активів, що не торгуються цілодобово, важливо мати надійне джерело стабільних цін у періоди закриття. Це може бути:
— тимчасова зупинка оновлення oracle або обмеження торгів у цей час.
— використання внутрішніх цінових механізмів, наприклад, у trade.xyz.
Обидва підходи — компроміс між безпекою та зручністю.
- Верифікація цін
Рекомендується створити механізм перевірки цін, що дозволить будь-якому користувачу або організації перевірити чесність та справедливість цінових даних, наприклад, через RedStone або подібні рішення, що підписують та зберігають джерела даних.
— публічні алгоритми та відкриті API.
— підписані дані з джерел.
— стандарти для передачі та перевірки цін.
- Моніторинг ризиків
— автоматичне виявлення збоїв у feed та відхилень.
— контроль за рівнем open interest та волатильністю.
— швидке реагування на підозрілі активності.
— активне управління ризиками через обмеження левериджу, обмеження ордерів, зупинку торгів.
Загалом, важливо поєднувати технічні рішення з управлінням ризиками для зменшення системних загроз та забезпечення стабільної роботи системи.
