Посібник для розробників HIP-3: Чому визначення Oracle формує долю вашого перпетуального ринку

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

Після трьох місяців з моменту запуску основної мережі, ринки, розгорнуті розробниками за HIP-3, вже накопичили понад $13 мільярдів у транзакційному обсязі. Такий масштаб не стався випадково. Це відображає як інновації протоколу, так і тих розробників, які успішно орієнтувалися у його складності. Але для кожного успішного ринку є й попереджувальна історія — наприклад, інцидент у грудні 2025 року на trade.xyz, де зловмисник експлуатував слабке визначення оракула для не-24/7 активу, витягуючи $13 мільйонів у довгих позиціях через маніпуляції ціною.

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

Розуміння інфраструктури Hyperliquid: основа для визначення оракула

Hyperliquid не вимагає від розробників винаходити велосипед. Він пропонує двошарову інфраструктуру:

HyperCore: власний Layer 1 блокчейн, оптимізований для безперервної торгівлі, що обробля 200 000 ордерів за секунду з детермінованою остаточністю. Збігання, очищення та розрахунок усі відбуваються на рівні протоколу — тобто розробники не будують торгові двигуни з нуля.

HyperEVM: рівень додатків, що виконує смарт-контракти, сумісний із існуючими інструментами Ethereum.

Завдяки повторному використанню цих шарів інфраструктури, розробники зосереджуються на тому, що дійсно важливо: визначенні ринку та операційній дисципліні. Внутрішній ринок безперервної торгівлі Hyperliquid все ще слідує традиційним процесам лістингу CEX — валідатори голосують за включення контрактів. Але HIP-3 інвертує цю модель: будь-який розробник, що відповідає порогу, може запустити ринок.

Щоб запустити за HIP-3, потрібно поставити 500 000 токенів HYPE. Перші три ринки розгортаються безкоштовно; додаткові — через аукціон у голландській системі (31-годинних циклах, починаючи з 2x від кінцевої ціни попереднього раунду). Вимога щодо ставки залишається протягом 30 днів навіть якщо ви призупините всі ринки — це не опціональна страховка, а механізм вашої відповідальності.

Ваша роль як розробника: дві окремі відповідальності

HIP-3 ділить роботу розробника на два етапи: визначення ринку та його операційна діяльність.

Визначення ринку — це правильне налаштування з перших днів. Ви маєте вказати:

1. Визначення оракула: Яке джерело даних закріпить ціни? Яка початкова ціна оракула (oraclePx)? Для безперервного контракту на акції — це Pyth? Для менш ліквідної альткоїну — ціна з CEX? Це рішення є незворотнім після того, як трейдери почнуть відкривати позиції.

2. Характеристики контракту: Символ, мінімальний розмір ордера, максимальний кредитний плечо, актив забезпечення (USDC, наприклад), і таблиці маржі, що зв’язують межі плеча з розміром позиції.

Операційна діяльність — це постійний контроль:

• Подача цін: Ви викликаєте setOracle повторно для подання цін оракула. Між викликами має бути щонайменше 2.5 секунди; якщо ціна (optional) не оновлюється протягом 10 секунд, система повернеться до локальної ціни книги ордерів.
• Регулювання плеча: Ви прив’язуєте таблиці маржі до вашого ринку, встановлюючи рівні межі плеча залежно від номінальної величини позиції.
• Аварійні механізми: Ви можете викликати haltTrading для зупинки ринку, скасування всіх ордерів і розрахунку позицій за поточною ціною.

Протокол накладає обмеження — ціна ###mark price( не може змінюватися більш ніж на ±1% за оновленням, і всі ціни обмежені у межах 10x від початкового значення дня. Але ці обмеження — не кайдани. В межах цих рамок ваші рішення визначають, чи процвітає ваш ринок або руйнується.

Визначення оракула: критична точка для стабільності ринку

Визначення оракула — це місце, де розділяється доля вашого ринку. Це перше, що ви встановлюєте, і найскладніше виправити. Ось чому це так важливо.

) Що насправді означає визначення оракула

В HIP-3 визначення оракула охоплює три рівні:

1. oraclePx (обов’язковий): основний ціновий якор. Зазвичай береться з вашого relayer-сервера, що агрегує зовнішні потоки (Pyth, DEX AMMs, ціни з CEX). Це ваша єдина точка відмови — якщо relayer зламається або піддасться DDoS.

2. MarkPx (необов’язковий): власні ціни, які ви подаєте — до 2 наборів — для обчислення фактичної ціни ліквідації. Тут розквітають розробники з власними моделями ціноутворення, але й тут погане рішення може зруйнувати ринок.

3. externalPerpPx (обов’язковий): зважена медіана цін середніх цін перпід з кількох CEX. Це служить санітарним коригуванням, щоб ізольований ринок не відхилявся занадто далеко від ширшого ринкового консенсусу.

Система поєднує ці три рівні у фінальну ціну: медіана між ###локальною ціною книги ордерів, вашими поданими markPx і externalPerpPx(. Якщо будь-який рівень виходить з ладу, система переходить до наступного. Якщо всі — ви торгуєте всліпу.

) 24/7 проти активів без 24/7: два різні визначення оракула

Для активів з 24/7 (BTC, ETH, більшість альткоїнів): визначення оракула просте. Pyth, Chainlink або прямі потоки з CEX забезпечують безперервні, ліквідні сигнали цін. Ваш relayer агрегує їх. Маніпуляції дорогі, оскільки миттєво можна помітити неправильну ціну у десятках зовнішніх ринків.

Для активів без 24/7 (акцій, індексів, товарів): визначення оракула стає екзистенційним. Візьмемо NASDAQ. Під час робочого часу Pyth дає чисті ціни. Після закриття ринку зовнішніх цін немає. Ваша модель оракула має працювати у вакуумі.

Ловушка у тому, що під час позаробочих годин ваш механізм setOracle не може отримати реальну ціну ринку. Тому ви повертаєтеся до “останнього закриття + внутрішній тиск книги ордерів”. Але без зовнішнього якоря внутрішній тиск — це дзеркало: ціна відображає лише внутрішні дані, а не справжню цінність активу.

Протокол накладає обмеження — ціна не може змінюватися більш ніж на ±1/maxLeverage, наприклад, 10x — максимум 10%. Це цілком логічно для високоволатильних активів у робочий час. Але для низьколіквідних акцій у вихідні — 10% коливання цілком може ліквідувати портфелі і спричинити каскад ADL.

Ліквідація та ADL: як визначення оракула впливає на ризики каскаду

Після відкриття позицій визначення оракула визначає, коли трейдери отримують маржін-колл.

Триггер ліквідації

Ліквідація відбувається, коли вартість ізольованої позиції падає нижче рівня підтримки маржі. Перевірка базується на ціні (розрахованій з вашого визначення оракула), а не на конкретній ціні транзакції. Математично:

Ціна ліквідації = (номінальна вартість × marginRequirement) / розмір позиції

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

Коли ліквідація стає ADL

Найстрашніше — коли ліквідаційні ордери не можуть знайти покупців. Уявімо, що ваша ціна (mark price) показує $3,000, але глибина книги тонка. Ліквідаційні ордери виконуються за $2,910 — різниця 3%. Якщо ця різниця достатня, щоб збитки від ліквідації перевищили маржу трейдера, ви створюєте “поганий борг”.

Система не терпить поганого боргу. Вона активує ADL (Автоматичне зниження левериджу): прибуткові позиції з протилежного боку закриваються силою за попередньою ціною ($3,000), а не за поточною ринковою. Прибутки “збираються” для покриття програшу, і втрати перерозподіляються між переможцями.

З точки зору розробника, ADL — це попередження про поширення. Кожна подія ADL сигналізує, що ваш ринок під тиском — або через несправність визначення оракула, або через надмірне використання плеча на малій глибині.

Ключові параметри: налаштування визначення оракула і плеча для вашого ринку

Ваш setOracle — це регулювальний диск, що має величезний важіль. Помилки мають каскадний ефект.

Частота оновлення та правила

Ви маєте викликати setOracle щонайменше кожні 10 секунд, інакше система повернеться до ціни книги ордерів (залишаючи ціну маркування без оновлення, якщо ваші потоки кращі). Більшість розробників оновлюють кожні 2-5 секунд під час волатильних періодів.

Але тут пастка: кожен виклик setOracle може змінити ціну не більш ніж на ±1%. Якщо реальні умови ринку змінюються на 5% за секунду (що не рідкість для альткоїнів з низькою капіталізацією або чорних лебедів), ваш визначник оракула стає застарілим за необхідністю. Ліквідатори бачать застарілі ціни і починають тиснути на ринок.

Визначення оракула для активів без 24/7: проблема вихідних днів

Акції та традиційні активи не торгуються у вихідні. Розробник, що планує безперервний контракт на акції за HIP-3, має вирішити: як визначати ціни оракула у суботу вранці, коли біржа закрита?

Поточні підходи:

Підхід 1: Консервативний — призупинити торгівлю або ліквідації у позаробочий час. Це роблять Lighter protocol і Optium. Трейдери втрачають доступ 24/7, але ринок залишається стабільним.

Підхід 2: Внутрішнє ціноутворення — використовувати “останню зовнішню ціну + внутрішній тиск книги ордерів” для підтримки роботи. Це те, що намагався trade.xyz перед їхнім грудневим інцидентом.

Другий підхід відкриває критичну слабкість визначення оракула: межа ±1/maxLeverage стає стелею ризику. На низьколіквідному акції у неділю навіть рух цін на 10% може відбутися з кількома великими ордерами. Ваш визначник оракула має запобігати цьому, але обмеження не є достатньо жорсткими.

Кращий визначник для активів без 24/7 включає додаткові опори:

• Blue Ocean ATS: забезпечує ціни після закриття — не так ліквідно, як у робочий час, але реальні ринкові ціни, а не внутрішні оцінки.
• IG Weekend CFD: дають “очікуваний рух відкриття”. У поєднанні з останнім закриттям і внутрішньою ціною вони дають шанс тримати визначник у прив’язаності.

Ці доповнення не замінюють ретельний дизайн оракула — вони його доповнюють. Ваша модель визначення оракула має бути: “Під час ринкових годин — Pyth. У позаробочий час — остання ціна Pyth, скоригована за серединою Blue Ocean ATS + внутрішній тиск, обмежена у межах ±X%.”

Контроль ризиків оракула: моніторинг у реальному часі для стабільності цін

Тут теорія зустрічається з практикою. Ваша модель визначення оракула — це лише частина системи моніторингу.

Виявлення збоїв потоку цін

Ваш relayer — це єдина точка відмови. Якщо він зламається або втратить зв’язок, setOracle припинить працювати. За 10 секунд система повернеться до ціни книги ордерів. Це допустимо для ліквідних ринків із вузькими спредами. Для інших — це пастка ліквідації.

План дій:

• Рівень 1: сигнал про збої потоку цін >2.5 секунд. Негайно перевірте relayer, переключіться на резервну інфраструктуру, опублікуйте звіт.
• Рівень 2: збої >10 секунд. Викличте setOpenInterestCaps, щоб зупинити нові позиції. Існуючі можна закривати. Це запобігає каскаду ліквідацій, поки ви відновлюєте pipeline.

Відхилення ціни: коли ваш визначник оракула відхиляється

Навіть якщо relayer працює, ціни можуть сильно відхилятися від реальності через:

• Застарілість Pyth (у разі навантаження).
• Відхилення внутрішнього середнього через низьку ліквідність.
• Швидший рух зовнішніх цін CEX (у externalPerpPx).

Кількісно визначаємо відхилення:

• Поріг A: |oraclePx - externalPerpPx| > 2%.
• Поріг B: |markPx - локальна середина книги| > 1%.
• Поріг C & D: подовжені відхилення >5 секунд.

План дій:

• Рівень 1: при спрацьовуванні 2+ порогів — викликайте setOpenInterestCaps, щоб зупинити зростання позицій.
• Рівень 2: поступово оновлюйте таблиці маржі, зменшуючи максимальне плечо по рівнях. Вмикайте обмеження ±1% у setOracle.
• Рівень 3: продовжуйте дії рівня 2 і подавайте сигнали. Якщо відхилення тривають >30 секунд — викликайте haltTrading як останній захід.

( Зниження глибини книги: виявлення тонких ринків

Ліквідність може зникнути без збоїв у визначенні оракула. Відстежуйте:

• Глибина у межах ±x%: сумарний обсяг ордерів у межах x% від середини.
• Спред: різниця між найкращим ask і bid. Здоровий — <0.1%. Небезпечний — >1%.
• Агресивний обсяг: обсяг taker-ордерів за останні Δt секунд. Якщо він перевищує глибину, — проблема.

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

Активи без 24/7: визначення оракула під час закриття ринку

Розглянемо конкретний сценарій: безперервний контракт на акції у п’ятницю ввечері. Ринок закривається о 16:00 ET. Ваш визначник оракула має провести ринок через вихідні.

) Інцидент Trade.xyz у грудні 2025

14 грудня 2025 року зловмисники використали саме цей сценарій. Вони відкрили велику коротку позицію у XYZ100 ###перпід NASDAQ-100( під час низької ліквідності. Атака:

1. Поза робочим часом: після закриття ринку, з мінімальними зовнішніми цінами і тонкою книгою, вони створили масовий тиск на продаж.
2. Збій визначення оракула: внутрішня ціна )на основі обмежених внутрішніх угод + остання зовнішня ціна### почала відхилятися вгору від реальних покупців.
3. Каскад ліквідацій: довгі позиції отримали маржін-колл за штучно завищеними цінами. Ліквідаційні ордери ще більше знизили ціну.
4. Каскад ADL: система силою закрила прибуткові короткі позиції (включно з позицією зловмисника) за застарілою ціною. Різниця була настільки великою, що спричинила каскад ADL.

Причина — визначення оракула для позаробочих годин було надто слабким. Ригель у 10% на плечі здається жорстким, але на акції, що рухаються лише на 2-3%, це дає простір для маніпуляцій.

( Покращене визначення оракула для позаробочих годин

Ваш визначник має включати:

1. Основний джерело під час роботи: Pyth або біржові потоки.
2. Допоміжний позаробочий якор: Blue Ocean ATS або IG CFD для сигналів очікуваного відкриття.
3. Внутрішня перевірка: якщо внутрішня ціна відхиляється >X% від допоміжного якоря, активуйте сигнали і зменшуйте плечі.
4. Асиметричне управління ризиком: під час роботи — 10x. Поза робочим часом — 2-5x. Це зменшує ризик каскаду ліквідацій, коли визначник оракула обмежений.

Створення панелі ризиків: моніторинг цін, глибини і позицій

Професійні розробники використовують три канали моніторингу одночасно:

) Канал 1: індикатори цін

Щохвилини відстежуйте:

• Затримку потоку цін (час з останнього виклику setOracle).
• Відхилення ціни від зовнішніх орієнтирів.
• Порушення обмежень $13M ±1%###.

Канал 2: індикатори книги ордерів

Щохвилини:

• Глибина у межах ±0.5%, ±1%, ±2%
• Тенденції спреду
• Кореляція обсягів покупок/продажів

Високий обсяг і зменшення глибини — передсигнал ліквідації.

( Канал 3: індикатори позицій

Щогодини:

• Загальний номінальний OI і співвідношення з 24-годинним обсягом )зростання — спекулятивний режим(.
• Розмір найбільшої позиції у % від доступної маржі.
• Більшість — довгі або короткі )незакриті P&L### у % від маржі.

Якщо P&L більшості перевищує 80-90% маржі при екстремальних цінах, будь-який шок ринку активує ADL.

Більшість розробників використовують ці панелі реактивно — спрацьовують сигнали і реагують. Просунуті автоматизують:

• Збої потоку цін >10 секунд → автоматичне зменшення OI до 50%.
• Зниження глибини + високий обсяг → автоматичне зменшення плеча.
• P&L >80% — сигнал і можливо зупинка ринку.

Від визначення оракула до стабільності ринку: рамки відповідальності розробника

HIP-3 дав розробникам автономію, але й відповідальність.

Якщо ваш ринок працює неправильно — через неправильне визначення оракула, необережне використання плеча або недостатній моніторинг — валідатори можуть проголосувати за зняття вашого 500k HYPE. Протокол не розрізняє злість і некомпетентність. Він оцінює результати: чи закрилися позиції правильно? Чи ціни оракула закріпилися коректно? Чи був ринок стабільним?

Шлях до відповідальності — через стандартизацію:

1. Публікуйте визначення оракула: точно розкрийте джерела даних, частоту оновлень і логіку запасних варіантів. Прозорість створює довіру і виявляє недоліки до краху ринку.

2. Впроваджуйте системи доказів: для кожного виклику setOracle генеруйте доказ ###джерела даних, кроки обчислень, результат(. Підписуйте і публікуйте у Merkle-дереві щогодини. Це дозволяє публічний аудит.

3. Обов’язково моніторте: створіть реальні панелі для відстеження цін, глибини і стану позицій. Встановіть автоматичні circuit-breakers, що зменшують OI і плечі до кризи.

4. Обережно проектуйте для активів без 24/7: для акцій використовуйте додаткові опори — Blue Ocean ATS, CFD-ціни і знижене плечо. Вчіться на інциденті trade.xyz у грудні.

5. Встановіть процедури ескалації: документуйте, коли і як викликаєте haltTrading. Це не просто важіль — це аварійна гальмівна система.

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

Мільярди у обсязі, розгорнутому розробниками, — це можливість. Інцидент trade.xyz — ризик. Ваш успіх залежить від того, чи сприймаєте ви визначення оракула не просто як технічний чекбокс, а як фундаментальну обіцянку, що визначає, чи керуєте ви ринком, чи — фермою ліквідацій.

Для подальшої підтримки безпеки, аудиту та інфраструктури ризик-менеджменту розгляньте залучення спеціалізованих компаній, таких як BlockSec, які допоможуть трансформувати ці принципи у виробничі системи. Вартість консультації — це частка від потенційних витрат у разі добре скоординованої атаки.