Определение оракула и стабильность рынка: создание надежных постоянных рынков на 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 перестает обновлять. Создатели должны отслеживать on-chain: если два последовательных обновления оракула разделены более чем 10 секундами, активируется уровень 1 тревоги. Создатель проверяет инфраструктуру relayer, при необходимости переключается на резервные узлы.

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

При уровне 1 — ограничить открытый интерес с помощью setOpenInterestCaps. При уровне 2 — постепенно снижать максимальное кредитное плечо по рисковым позициям. При уровне 3 — останавливать торговлю через haltTrading.

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

Определение оракула зависит от ликвидности рынка. Если книга сужается, спреды расширяются, а влияние агрессивных ордеров растет — даже точные цены становятся опасными. Создатели должны отслеживать depth_band (накопленный объем внутри ±x% от средней цены), spread (лучший ask минус лучший bid) и impact_ratio (агрессивный объем / depth_band). При сокращении глубины и росте спредов и impact_ratio риск ликвидации возрастает.

На уровне 1 — ограничить рост открытого интереса. На уровне 2 — принудительно снижать кредитное плечо по высоким рискам.

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

Также важно отслеживать, переходит ли рынок от хеджирования к спекуляции. Следить за отношением номинала открытых позиций к 24-часовому объему торгов. При быстром росте OI по сравнению с объемом рынок становится односторонним. В сочетании с экстремальными прибылью/убытками по большинству позиций это предшествует каскадам ликвидаций. Создатели должны предупреждать при превышении порогов; при постоянных отклонениях — снижать лимиты OI.

Геймификация ответственности за решения по определению оракула через стейкинг

Механизм HIP-3 для ответственности создателей основан на стейкинге. Создатели обязаны держать 500k HYPE в залоге постоянно. Валидаторы могут голосовать за снижение этого залога, если действия создателя приводят к недопустимым состояниям рынка, длительным простоям или ухудшению производительности.

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

Это превращает определение оракула из технического решения в вопрос геймификации ответственности. Валидаторы косвенно подтверждают или наказывают выбор создателя через голосование за slash. Со временем это создает эволюционное давление: те, кто реализует надежные определения — выживают; те, кто халтурит — получают больше голосов за slash.

Конечно, механизм не идеален — валидаторы могут не обладать достаточной технической экспертизой или голосовать по иным причинам. Но он устанавливает минимальный уровень ответственности.

Более широкое значение: децентрализация как перераспределение рисков

Ключевое нововведение HIP-3 — не устранение риска, а его перераспределение. Там, где централизованные биржи берут на себя операционный риск (поддержка ценовых фидов, предотвращение манипуляций, управление ликвидациями), HIP-3 переносит эти обязанности на создателей. Протокол предоставляет инфраструктуру; создатели обеспечивают операционное качество.

Это работает только если создатели понимают, за что они отвечают. Определение оракула — одна из самых недооцениваемых точек атаки. Оно кажется простым — выберите фид — но включает выбор источников, управление relayer, риски вне рыночных часов, механизмы резервирования, системы проверки и геймификацию ответственности.

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

Создатели, входящие в HIP-3, должны рассматривать определение оракула не как техническую деталь, а как архитектурное решение, определяющее, будет ли их рынок работать с честностью или провалится под стрессом.

Пути развития

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

Это включает внедрение систем проверки, позволяющих внешним аудиторам проверять методологию ценообразования. Это — установление порогов мониторинга и процедур эскалации с четкими правилами принятия решений. Самое важное — признать, что сложность поддержания доверия к определению оракула в стрессовых условиях никуда не исчезла — она просто переместилась с биржи к создателям.

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