Посібник з підтримки рівня залучення HIP-3: від налаштування параметрів до виконання ризик-менеджменту

Hyperliquid через HIP-3 (Пропозиція щодо покращення Hyperliquid 3) реалізував новий децентралізований підхід на ринку безстрокових контрактів, з моменту запуску основної мережі пройшло близько трьох місяців. Треті сторони-розробники можуть розгортати свої ринки на єдиній платформі для торгівлі та розрахунків, загальний обсяг торгів третіх сторін вже перевищив 130 мільярдів доларів. Це значне нововведення, яке суттєво знижує бар’єри для інновацій, але водночас несе нові ризики безпеки. Зокрема, управління рівнем застави та підтримкою маржі стає ключовим фактором для довгострокової стабільної роботи ринку.

Для Builder застави — це не лише “вхідний квиток” для участі, а й економічна мотивація та рамки розподілу ризиків. За допомогою застави та обмежень рівня підтримки маржі HIP-3 створює відкриту інноваційну систему із можливістю підзвітності у системі управління ризиками.

Механізм застави та рамки підтримки маржі HIP-3

HIP-3 базується на двошаровій архітектурі Hyperliquid: HyperCore (індивідуалізована L1-ланцюг для оптимізації контрактної торгівлі, здатна обробляти 200 000 ордерів за секунду) та HyperEVM (сумісна з EVM прикладна оболонка). Головна перевага цієї архітектури — узгоджена підтримка та розрахунки через протокол, що дозволяє Builder повторно використовувати високопродуктивний движок без необхідності створювати все з нуля.

Економічний зміст застави

У HIP-3 Builder має тримати заставу у 5 мільйонів HYPE. Це має три значення:

1. Механізм входу: застава є передумовою для розгортання ринків, гарантує достатню економічну залученість учасників
2. Розподіл ризиків: у разі неправильного функціонування ринку заставу може бути конфіскована, що зв’язує інтереси Builder та користувачів
3. Обмеження рівня підтримки маржі: розмір застави безпосередньо визначає кількість ринків, які може розгорнути Builder, та масштаб ризиків, які він може нести

Безпосередній зв’язок рівня підтримки маржі

Зв’язок між рівнем підтримки маржі (Maintenance Margin Ratio) та розміром застави полягає у тому, що застава виступає як “запасний капітал ризику” для ринку Builder. У разі аномалій (наприклад, ціновий розрив, глибина ринку, що зникає, або пропуски у ліквідації) ця застава стає останнім захистом і джерелом компенсації.

Валідаційні вузли (validators) голосують за допомогою stake-weighted vote (голосування за вагою застави), визначаючи, чи потрібно застосовувати штрафи або конфіскацію. Умови штрафів включають:

• Виведення ринку з дії або довгий простої: штраф до 100% застави
• Тимчасові збої або зниження продуктивності: штраф до 20-50%
• Злом приватного ключа, що призвів до маніпуляцій ціною: також під ризиком конфіскації

Цей дизайн фактично поєднує відповідальність за операції з економічними інтересами — чим вищий рівень підтримки маржі, тим більший запас безпеки, але при цьому ризик втрат для відповідальних за ризик зростає.

Термін блокування застави

Навіть якщо Builder припинить роботу всіх своїх ринків, заставу потрібно тримати протягом 30 днів перед можливістю її розблокування. Це означає, що відповідальність за ризики не знімається миттєво при зупинці торгів — якщо під час простою виникнуть нові проблеми безпеки або суперечки користувачів, заставу можуть заморозити або конфіскувати.

Параметри роботи ринку та обмеження рівня підтримки маржі

Після запуску ринку Builder має налаштовувати параметри для підтримки стабільності. Ці налаштування безпосередньо впливають на умови тригера ліквідації та масштаб ризиків, що, у свою чергу, визначає реальний тиск на рівень застави.

Оракул та механізм ціноутворення

Builder має постійно подавати три типи цін через setOracle:

• oraclePx (обов’язково): базова ціна активу для розрахунку funding fee
• markPx (опційно): 0-2 зовнішні mark price
• externalPerpPx (обов’язково): зважена медіана цін між кількома CEX для безпеки від розриву ціни

Система використовує для розрахунку mark price медіану між локальним ціноутворенням та markPx. Щоб запобігти маніпуляціям, встановлено обмеження:

• Частота оновлень: мінімум 2.5 секунди між викликами, при відсутності оновлень понад 10 секунд — автоматичне повернення до локального mark
• Волатильність: кожне оновлення markPx не може перевищувати ±1%, а всі ціни обмежені у діапазоні 10-кратної від ціни відкриття дня

Ці обмеження фактично захищають заставу Builder — обмежуючи можливості маніпуляцій ціною, зменшуючи ризик штрафів.

Налаштування плеча та таблиць маржі

Builder визначає max leverage через таблиці маржі (margin table), які розподіляють рівень підтримки залежно від обсягу позиції. Різні рівні мають різні вимоги до підтримки маржі (maintenance margin).

Для ринків з низькою ліквідністю високий ліміт плеча може спричинити часті тригери автоматичного зняття (ADL). Наприклад, якщо обсяг торгів за день — 10 мільйонів доларів, а плечо — 20x, то при досягненні критичного рівня відкритих позицій будь-яка цінова коливання може швидко викликати ліквідацію, що спричинить пропуски та автоматичне зняття.

При зміні marginTableId одночасно змінюється підтримка маржі для всіх користувачів, що може викликати масові ліквідації та ризик системних збоїв. Це дуже ризиковано, оскільки може призвести до масових штрафів та конфіскації застави.

Зупинка ринку та примусова ліквідація

Builder має право виключити торгівлю (haltTrading), що дозволяє зупинити торги, скасувати ордери та примусово ліквідувати всі позиції за поточним mark price. Це інструмент управління ризиками, але неправильне застосування може збільшити збитки.

Наприклад, при атаці, що створює великі короткі позиції та штучно маніпулює ціною, виклик haltTrading призведе до автоматичного розрахунку за mark price, фактично реалізуючи прибутки атакуючого. Якщо у атакуючого недостатньо ліквідності для протистояння, він буде примусово закритий, а збитки — списані з застави Builder. Це може спричинити штрафи та втрату застави через голосування валідаторів.

Ризики оракула та зв’язок із рівнем підтримки маржі

Оракул — це життєво важливий компонент цінової системи HIP-3. Builder зазвичай використовує незалежних relayer-нодів для подачі цін, але тут є кілька ризиків.

Ціноутворення активів 24/7 та не 24/7

Для активів з цілодобовою торгівлею (наприклад, BTC) можна отримати стабільні зовнішні ціни з CEX/DEX. Builder агрегує ці джерела, зменшуючи ризики.

Для нерегулярних активів (акції, індекси) ситуація складніша. Під час відкриття ринку Builder може використовувати зовнішні оракули (Pyth тощо), але під час закриття (ніч, вихідні) зовнішні ціни відсутні. Тоді застосовуються внутрішні алгоритми ціноутворення: базуються на останній ціни закриття + внутрішній ордербук, а mark price обмежується у межах ±10% від останньої ціни закриття (при 10x — ±10%).

Ризик у тому, що при відкритті ринку ціна може різко розірватися, і внутрішнє ціноутворення не відобразить реальну цінову ситуацію. Це може спричинити масові ліквідації та падіння довіри.

Централізовані ризики relay-серверів

Якщо relayer-нод Builder зазнає DDoS-атаки або приватний ключ буде скомпрометований, ціни оракула можуть бути навмисно маніпульовані або залишатися розірваними. Це створює ризик конфіскації застави.

Моніторинг у реальному часі: динамічне управління рівнем підтримки маржі

Хоча Builder має значну свободу у налаштуваннях, система пропонує інструменти для динамічного контролю. Важливо правильно їх використовувати для збереження безпеки застави.

Моніторинг цін

1. Збої оракула: при блокуванні relayer-нодів або затримках понад 10 секунд система автоматично повертається до локального mark. У цей час потрібно переключитися на резервний relayer і повідомити валідаторів. За тривалого збою слід знизити обсяг відкритих позицій через setOpenInterestCaps.

2. Розрив цін: слідкувати за відхиленнями mark price від цін на кількох перп-індексах CEX:

   • Попередження рівня 1: відхилення ≥3%, зменшити OI
   • Попередження рівня 2: відхилення ≥5% і тривалістю понад 30 секунд, зменшити max leverage у таблицях маржі, активувати clamp
   • Попередження рівня 3: тривале високий відхилення — зупинити торги

Моніторинг глибини ринку

1. Глибина та спред: аналіз реальних ордерів у діапазоні ±3%, визначення співвідношення taker/глибина. При зменшенні глибини та зростанні спреду — підвищується ризик. У цей момент потрібно зменшити OI.

2. Фейкові ордери: виявлення швидких змін у depth band, що свідчать про штучне створення фальшивої ліквідності. У разі виявлення — обмежити OI.

Позиційний моніторинг

Контроль відкритих позицій (OI) у співвідношенні з обсягом торгів за 24 години. Швидке зростання цього коефіцієнта сигналізує про перехід до довгострокових позицій, що підвищує ризик каскадних ліквідацій. Також слідкувати за прибутками/збитками більшості учасників — при їхній близькості до крайніх значень ціна може різко рухнути у зворотний бік.

Ці сигнали впливають на рішення Builder щодо коригування плеча, зменшення OI або зупинки ринку. Помилки у цих рішеннях можуть призвести до штрафів та втрати застави.

Інструмент розрахунку рівня підтримки маржі: практичне застосування ризик-менеджменту

На основі системи управління ризиками Builder потребує інструменту для швидкого обчислення та моніторингу рівня підтримки маржі.

Основні функції калькулятора

Повний калькулятор має вміти:

1. Оцінювати безпеку застави у реальному часі: вводити поточний обсяг застави, кількість розгорнутих ринків, обсяг OI кожного, ймовірність ліквідації — і визначати максимально можливий збиток за найгіршого сценарію.

2. Класифікувати ризики: автоматично оцінювати поточний стан ринку (стабільність цін, глибина, співвідношення OI та обсягу), і давати прогноз “згорання” застави.

3. Рекомендації щодо параметрів: пропонувати оптимальні max leverage, рівні підтримки маржі, OI-ліміти та ін.

4. Мульти-ринковий аналіз: для кількох ринків — оцінювати сумарний ризик, визначати найбільш вразливий.

5. Стрес-тести: моделювати сценарії розриву цін на 5%, збої ліквідності, ADL — і прогнозувати максимальні збитки.

Практичне застосування

• Перед запуском нового ринку — оцінити ризики та налаштувати параметри
• Під час роботи — моніторити індикатори та вчасно реагувати
• У кризових ситуаціях — швидко оцінити масштаби збитків та прийняти рішення
• Після подій — аналізувати та оптимізувати систему ризик-менеджменту

Висновок: відкритий розподіл з відповідальністю

HIP-3 через відкриті інтерфейси дозволяє “запускати” нові ринки безпосередньо через протокол, що вже довело свою ефективність — обсяг торгів третіх сторін перевищив 130 мільярдів доларів. Однак цей підхід вимагає більшої відповідальності від Builder, оскільки контроль за ризиками тепер частково перекладено на їхню якість введення даних та операцій.

Рамки застави та підтримки маржі — це спосіб HIP-3 забезпечити відповідальність за “ризикове аутсорсінг”. Builder підтверджує свою здатність керувати ринками, а валідатори мають право застосовувати штрафи та конфіскацію застави у разі невідповідності.

Успіх системи залежить від:

1. Якісності введення даних Builder: надійність оракулів, раціональність параметрів, ефективність моніторингу
2. Протоколу та рамок: чіткість правил штрафів, обмежень цінових коливань, системи моніторингу
3. Інструментів та систем підтримки: калькуляторів, систем аналізу ризиків, автоматичних систем реагування

Довгострокова безпека залежить від здатності Builder впроваджувати ці практики у реальну діяльність, а не лише на рівні концепцій.