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

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

Архітектура децентралізованого лістингу: від схвалення до стандартів

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

Механізм простий на перший погляд: поставте 500k токенів HYPE, розгорніть DEX (який має власний маржін і книгу ордерів), запустіть три ринки безкоштовно, а потім отримайте додаткові слоти через голландські аукціони. Але ця структурна простота приховує глибоку складність у реалізації. Тепер розробник володіє не лише створенням ринку, а й операціями — подачею цін, управлінням параметрами, постійним моніторингом стабільності. Те, що раніше було відповідальністю платформи, тепер стає відповідальністю розробника.

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

Визначення оракула: критичне перше рішення

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

Що фактично означає визначення оракула:

Визначення оракула у HIP-3 включає три компоненти: oraclePx (сирий ціновий потік з зовнішнього джерела), опційний markPx (індивідуальні ціни, які надає розробник), і externalPerpPx (вагомедіана з централізованих біржових перпетюальних цін). Це не взаємозамінні входи — вони виконують різні функції у ієрархії розрахунку ризиків HIP-3.

oraclePx закріплює плату за фінансування і служить орієнтиром для цінових меж. markPx обчислюється relayer-ом розробника, що поєднує сигнали з блокчейну і поза ним. externalPerpPx дає резервний орієнтир. Потім HIP-3 формує фактичну ціну за допомогою медіанного розрахунку: спершу медіана локальної книги ордерів, потім у поєднанні з зовнішніми марками, наданими розробником, і порівнює з externalPerpPx. Такий багатокореневий підхід теоретично запобігає тому, щоб будь-яке одне джерело цін диктувало ліквідації.

Теоретично.

Чому визначення оракула важливіше за технологію:

Технічна складність визначення оракула менш критична, ніж здатність розробника підтримувати його. Вибір розробником оракула, що залежить від централізованого relayer-сервера, означає, що він успадковує доступність, безпеку і частоту оновлень цього сервера. Якщо приватний ключ relayer буде скомпрометовано, або DDoS-атаки заблокують оновлення цін, oraclePx застигне. При неможливості оновлення марок система повернеться до локальних медіан книг ордерів — саме тоді, коли ліквідність найменша і ризик маніпуляцій найвищий.

Інцидент 14 грудня 2025 року на trade.xyz це продемонстрував. Зловмисники накопичили коротку позицію приблизно на 398 XYZ100 контрактів (~10 млн доларів), навмисно створюючи дисбаланс. Ціна відокремилася від зовнішніх джерел через недостатню глибину книги ордерів. Тримачі довгих позицій зазнали каскадних ліквідацій, закривши приблизно 13 млн доларів позицій. Механізм працював технічно — ліквідації виконані — але система передала збитки найменш підготовленим учасникам, а не запобігла початковому зсуву.

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

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

Гнучкість HIP-3 у лістингу будь-яких активів створює категоріальну різницю у вимогах до визначення оракула.

Активи 24/7 (криптовалюти з безперервною торгівлею):

Для Bitcoin, Ethereum та інших активів, що торгуються цілодобово, визначення оракула може базуватися на кількох цінових потоках CEX/DEX у поєднанні з спеціалізованими сервісами, як Pyth. Ці активи торгуються безперервно на кількох майданчиках. Розробник може агрегувати кілька джерел цін, застосовувати медіанні розрахунки і виявляти аномалії. Якщо один джерело зсунується, інші забезпечують швидке орієнтування.

Визначення оракула для активів 24/7 залишається складним — вибір вагових джерел, управління частотою оновлень, обробка збоїв бірж — але зовнішній ринок забезпечує стабільні сигнали навіть при збої окремого фіду.

Активи не 24/7 (акції і товари):

Для перпетюальних контрактів на акції потрібно зовсім інше підґрунтя. Під час робочих годин ціни з сервісів, як Pyth, забезпечують стабільний зовнішній орієнтир. Але коли Нью-Йоркська біржа закривається, розробник стикається з вибором: або припинити подачу цін (і обмежити торгівлю), або продовжувати ціноутворення на основі внутрішніх сигналів з зовнішніми посиланнями лише за “попередньою ціною закриття”.

Більшість розробників, що працюють з не 24/7 активами, використовують внутрішній механізм ціноутворення, схожий на trade.xyz — поєднання останньої зовнішньої ціни з внутрішньою динамікою книги ордерів, з обмеженнями для запобігання надмірному зсуву (зазвичай 1/max_leverage). Це математично обґрунтовано, але операційно небезпечно.

Під час закриття ринку глибина книги зазвичай зменшується. Маркет-мейкери зменшують котирування, роздрібні учасники сплять, ринок стає тонким. Визначення оракула, яке обмежує рух цін “1/10 попереднього закриття” (для 10-кратного плеча), здається консервативним. Але коли ліквідність зникає, навіть невеликі потоки ордерів викликають непропорційні рухи цін у межах цього обмеження. А коли ринок відкривається в понеділок і зовнішні дані знову орієнтують ціну, виникають розриви. Це спричиняє каскадні ліквідації або, у найгірших випадках, події ADL (автоматичне зменшення позицій), коли прибуткові угоди примусово закривають для покриття збитків від неплатоспроможних позицій.

Створення захищеної системи визначення оракула

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

Додаткові цінові орієнтири під час закриття ринку:

Для не 24/7 активів корисно вводити зовнішні сигнали навіть під час неробочих годин. Варіанти:

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

• Цінові котирування CFD у вихідні від провайдерів, як IG: прогнозують очікуваний відкриття наступного тижня. Хоча вони не є прямими замінниками спотових цін, вони слугують орієнтирами для “очікуваних розривів” у визначенні оракула.

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

Проєктування прозорого і піддаваного аудиту механізму отримання цін:

Головна вразливість у сучасних реалізаціях — централізація relayer. Якщо цінові потоки походять виключно з приватного сервера розробника, цей сервер стає єдиною точкою відмови і атаки. Розробники повинні створювати системи перевірки визначення оракула, що дозволяють стороннім аудиторам перевіряти автентичність цін.

Для цього потрібно публічно розкривати: джерела даних, алгоритм їх об’єднання, часові мітки зразків і отримані ціни. Для кожного виклику setOracle генерувати криптографічний доказ, що включає сирі дані, кроки обчислень і кінцевий результат. Це серіалізувати у proofHash, який підписує relayer. Периодично об’єднувати ці хеші у Merkle-дерева і публікувати корінь на блокчейні.

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

Що робити, коли визначення оракула дає збій: моніторинг і втручання

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

Моніторинг цінової частини: виявлення зсуву оракула:

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

Більш підступним є поступове відхилення ціни: оракул відхиляється від зовнішніх орієнтирів. Наприклад, Pyth для акцій може давати дані, що відрізняються від актуальних ринкових умов. В такому разі визначення оракула стає застарілим без явних ознак збоїв. Моніторинг має порівнювати кілька зовнішніх джерел із оракулом: якщо два або більше відхиляються більш ніж на X%, слід піднімати тривогу.

При рівні 1 — обмежити відкритий інтерес через setOpenInterestCaps. При рівні 2 — поступово знижувати максимальне кредитне плече, зменшуючи ризик. При рівні 3 — запускати аварійні зупинки через haltTrading.

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

Визначення оракула залежить від ліквідності ринку. Якщо глибина книги зменшується, спреди розширюються, а агресивний вплив ордерів зростає, навіть точні ціни стають небезпечними. Розробники мають слідкувати за такими показниками: depth_band (загальний обсяг у межах ±x% від середньої ціни), spread (краща пропозиція — найкращий запит), impact_ratio (агресивний обсяг / depth_band). При зменшенні глибини і розширенні спредів і impact_ratio ризик ліквідацій зростає.

На рівні 1 — обмежити зростання відкритого інтересу. На рівні 2 — примусово зменшити кредитне плече для високоризикових позицій.

Моніторинг концентрації позицій: виявлення спекулятивних каскадів:

Також потрібно слідкувати, чи ринок не переходить від реального хеджування до чистої спекуляції. Відношення номінального відкритого інтересу до обсягу торгів за 24 години. Якщо OI зростає швидше за обсяг, ринок накопичує односторонню експозицію. У поєднанні із крайніми прибутками/збитками переважаючих сторін це передує каскадам ліквідацій. Розробники мають сигналізувати, коли співвідношення перевищує пороги; при їх постійному порушенні — знижувати обмеження OI.

Гарантії через стейкінг: відповідальність за рішення щодо визначення оракула

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

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

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

Механізм не ідеальний — валідатори можуть не мати технічної компетенції для об’єктивної оцінки або голосувати з інших мотивів. Але він встановлює мінімальний рівень відповідальності.

Глобальний висновок: децентралізація як перерозподіл ризиків

Головна інновація HIP-3 — не усунення ризику, а його перерозподіл. Там, де централізовані біржі внутрішньо беруть на себе операційний ризик (підтримка цінових фідів, запобігання маніпуляціям, управління ліквідаціями), HIP-3 делегує ці обов’язки розробникам. Протокол надає інфраструктуру, а розробники — операційну майстерність.

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

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

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

Шлях уперед

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

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

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