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

Hyperliquid Improvement Proposal 3 (HIP-3) [1] представляет фундаментальное изменение в процессе создания и масштабирования бессрочных (perpetual) рынков на Hyperliquid. Открывая процесс листинга рынков для сторонних разработчиков, HIP-3 переводит листинг из дискреционного действия, контролируемого платформой, в управляемый правилами интерфейс на уровне протокола.

С момента запуска в основной сети рынки, развернутые сторонними разработчиками, сгенерировали более 13 миллиардов долларов торгового объема примерно за три месяца, доказав, что HIP-3 может существенно улучшить масштабируемость и гибкость расширения рынка. Однако это изменение не просто децентрализует власть; оно также перераспределяет ответственность. Риски, которые ранее поглощались или смягчались централизованными операциями платформы, теперь ложатся непосредственно на плечи разработчиков (билдеров).

В результате основной вопрос в рамках HIP-3 заключается не в том, можно ли запустить рынок, а в том, можно ли безопасно управлять им в долгосрочной перспективе. В этом отчете HIP-3 анализируется с точки зрения разработчика, причем основное внимание уделяется тому, как рынки определяются и управляются, с какими рисками сталкиваются разработчики и как эти риски (в частности, связанные с оракулами) могут быть минимизированы.

0x0 Контекст

Архитектура Hyperliquid [2] отходит от этой модели, отделяя инфраструктуру исполнения и рисков от определения рынка. Её двухуровневый дизайн состоит из:

• HyperCore — специализированный блокчейн первого уровня (Layer 1), оптимизированный для торговли деривативами и обеспечивающий унифицированный мэтчинг, ликвидацию и расчеты.
• HyperEVM — совместимый с EVM прикладной уровень, который обеспечивает расширяемую логику и взаимодействие с разработчиками.

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

Несмотря на эту архитектуру, процесс листинга для нативных бессрочных рынков Hyperliquid, также называемых перпами под управлением валидаторов, все еще напоминает традиционный подход CEX. Листинг новых контрактов в основном инициируется основной командой, а делистинг определяется голосованием валидаторов.

HIP-3 был введен для децентрализации этого процесса листинга путем обеспечения возможности создания бессрочных рынков сторонними разработчиками. Он формализует разделение между определением рынка и обязательным исполнением протокола, позволяя билдерам создавать рынки и управлять ими, в то время как протокол устанавливает жесткие границы исполнения и рисков. Таким образом, HIP-3 представляет собой ключевую веху на пути к полностью децентрализованному процессу листинга перпов.

0x1 Обязанности разработчика: Определение и эксплуатация

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

0x1.1 Процесс запуска рынка: Определение и эксплуатация

В рамках HIP-3 запуск рынка — это не однократное действие. Как показано на полной схеме рабочего процесса запуска рынка ниже, это процесс, состоящий из двух различных фаз: определение рынка (шаги с 1 по 4) и эксплуатация рынка (шаг 5).

На этапе определения рынка разработчик должен сначала застейкать 500 000 HYPE в основной сети. После выполнения этого требования разработчик может развернуть один бессрочный DEX, который образует независимый торговый домен со своей собственной системой обеспечения (маржи), книгами ордеров и настраиваемыми параметрами. На уровне DEX разработчик выбирает котируемый актив (quote asset), который будет использоваться в качестве залога для всех рынков в рамках этого DEX. Выбранный актив должен сохранять статус permissionless (без ограничений), поскольку потеря этого статуса приведет к отключению соответствующего DEX. Затем разработчик определяет основные параметры рынка, включая спецификации оракулов, параметры контрактов, такие как тикер и лимиты кредитного плеча, а также таблицы маржи. Первые три рынка можно развернуть напрямую, в то время как для создания дополнительных рынков необходимо выкупать слоты через голландский аукцион.

Голландский аукцион: каждый раунд длится 31 час, начальная цена каждый раз в 2 раза выше предыдущей финальной цены (последняя выигрышная цена / самая низкая цена).

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

На практике большинство серьезных сбоев в HIP-3 происходят не во время определения рынка, а во время длительной эксплуатации в стрессовых рыночных условиях. Важно отметить, что ответственность разработчика не заканчивается сразу после остановки рынков. Вывод стейка возможен только после закрытия всех позиций, и стейк остается доступным для слешинга (штрафа) в течение обязательного периода анстейкинга.

0x1.2 Критические области внимания: Ценообразование и платежеспособность

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

1. Конфигурация оракула и ценообразование

Hyperliquid определяет две цены:

• Цена оракула (Oracle Price): взвешенная медиана спотовых средних цен (mid-prices) с крупных внешних бирж, предназначенная для того, чтобы быть независимой от внутренних рыночных данных Hyperliquid и использоваться в основном для привязки ставки финансирования (funding rate).
• Маркировочная цена (Mark Price): внутренняя цена риска, полученная из нескольких источников, включая цену оракула и локальные рыночные данные, используемая для PnL (прибыли и убытков) по открытым позициям и контроля рисков.

Короче говоря, цена оракула привязывает финансирование, а маркировочная цена управляет маржинальными проверками, ликвидациями, а также триггерами TP (Take Profit) и SL (Stop Loss).

В рамках HIP-3 роли цены оракула и маркировочной цены не меняются, но меняется механизм вычисления:

а) Входные данные для setOracle

• oraclePx (обязательно): то же определение, что и в HyperCore.
• markPx (опционально): 0–2 кандидата на маркировочную цену, вычисляемых извне.
• externalPerpPx (обязательно): эталонное значение для предотвращения внезапных отклонений маркировочной цены.

Разработчики обычно разворачивают узлы-ретрансляторы (relayer nodes) для передачи цен: oraclePx вычисляется из нескольких внешних источников, markPx вычисляется ретранслятором с помощью пользовательского алгоритма, а externalPerpPx — из взвешенной медианы средних цен бессрочных контрактов с нескольких CEX.

b) Фактическая маркировочная цена

• Вычислить локальную марку (local mark): median(лучший бид, лучший аск, последняя сделка).
• Взять локальную марку и markPx (0–2 значения) вместе и взять медиану, чтобы получить новую маркировочную цену.

c) Ограничения setOracle

• Частота обновления: не менее 2,5 сек между вызовами; если markPx не обновляется в течение 10 сек, происходит откат к локальной маркировочной цене.
• Лимиты амплитуды: markPx может изменяться максимум на ±1% за обновление; все цены ограничены в пределах 10-кратной цены начала дня.

Почему тип актива важен для ценообразования в HIP-3?

В рамках HIP-3 бессрочные рынки могут быть запущены для любого типа активов. Эти активы можно разделить на активы 24/7 (торгуются круглосуточно) и активы не 24/7 (торгуются только в определенные часы, без спотовой торговли в остальное время). Разница в торговых часах фундаментально определяет, как цены получаются и поддерживаются.

Для активов 24/7 (например, BTC) относительно стабильные цены можно постоянно получать путем агрегирования данных с CEX, DEX или доверенных сервисов оракулов.

Для активов не 24/7 (например, акций) достаточная ликвидность и надежные внешние рыночные цены доступны только в официальные торговые часы. Чтобы поддерживать торговлю такими активами в HIP-3 непрерывно, в нерабочее время должен использоваться отдельный механизм ценообразования.

Возьмем в качестве примера рынки бессрочных акций на trade.xyz:

• В торговые часы стабильные цены оракулов предоставляются внешними сервисами оракулов, такими как Pyth.
• В неторговые часы цены корректируются на основе последней цены закрытия актива в сочетании с внутренним давлением покупателей/продавцов из книги ордеров. Маркировочная цена ограничена колебаниями в пределах ±1 / max_leverage от последней цены закрытия (например, Tesla: 10× кредитное плечо → ±10%).

2. Платежеспособность рынка в условиях стресса

Hyperliquid применяет два механизма: ликвидацию и ADL (автоматическое делевериджирование) для поддержания платежеспособности рынка. В рамках HIP-3 и ликвидация, и ADL в основном следуют дизайну HyperCore. Основное отличие заключается в ограничении на уровне протокола: HLP (Hyperliquidity Provider), который выступает в качестве хранилища протокола, не может принимать на себя рискованные позиции на рынках HIP-3. В результате промежуточный буфер хранилища, который может поглощать позиции между ликвидацией рынка и ADL в HyperCore, в HIP-3 отсутствует.

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

а) Ликвидация

Ликвидация запускается, когда чистая стоимость позиции (стоимость изолированной позиции) становится недостаточной для удовлетворения требования к поддерживающей марже, и она становится ликвидируемой. Все проверки, связанные с ликвидацией, основаны на маркировочной цене, а не на конкретной цене исполнения.

Формула цены ликвидации определена следующим образом:

Где:

• side: 1 для длинных позиций, -1 для коротких позиций
• l — коэффициент поддерживающей маржи

Значение MAINTENANCE_LEVERAGE определяется уровнем маржи, соответствующим позиции. Из этого уровня получается коэффициент поддерживающей маржи mmr:

При настройке уровней маржи применяется mmr того уровня, который соответствует ноциональной стоимости позиции по цене ликвидации.

• margin_available (изолированная): изолированная_маржа - требуемая_поддерживающая_маржа

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

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

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

б) ADL (автоматическое делевериджирование)

В экстремальных сценариях механизм ADL действует как последняя линия обороны.

ADL запускается, когда стоимость изолированной позиции становится отрицательной. Система ранжирует прибыльных контрагентов по PnL и кредитному плечу, а затем принудительно уменьшает или закрывает эти позиции по предыдущей маркировочной цене (предыдущей зафиксированной маркировочной цене перед запуском ADL). Используя прибыль выигрышной стороны для покрытия дефицита, протокол остается платежеспособным и не несет безнадежной задолженности.

Индекс сортировки рассчитывается как:

Здесь notional_position относится к абсолютной рыночной стоимости позиции по текущей маркировочной цене, вычисляемой как |размер_позиции| × маркировочная_цена. account_value означает собственный капитал счета по маркировочной цене, то есть стоимость залога плюс нереализованная прибыль/убыток.

Пример:

• Перед запуском ADL маркировочная цена системы = 3000.
• Из-за ограничений setOracle новая маркировочная цена может быть обновлена только до 2970 (−1%).
• Однако сторона бида (покупок) в книге ордеров очень тонкая. После того, как ликвидационные рыночные ордера попадают в книгу, фактическая средняя цена исполнения = 2910 (−3% относительно 3000).
• Убытки по длинным позициям закрываются по 2910, потенциально опуская стоимость изолированной позиции ниже нуля и создавая дефицит, что запускает ADL.
• Затем ADL выбирает позиции противоположной стороны (прибыльные шорты) и принудительно уменьшает/закрывает их по предыдущей маркировочной цене = 3000, перекладывая дефицит на «выигрышную сторону, пассивно получающую меньше».

0x2 Ландшафт рисков разработчика

В рамках HIP-3 риск для разработчиков больше не является абстрактным или чисто теоретическим. Из-за стейкинга и слешинга под управлением валидаторов операционные ошибки и неверные настройки могут напрямую привести к экономическим штрафам. В результате понимание того, как запускается слешинг и какие типы поведения разработчика могут к этому привести, становится центральным элементом модели риска разработчика. Соответственно, в этом разделе сначала объясняется механизм слешинга как системы подотчетности, а затем анализируются два основных источника риска разработчика в рамках HIP-3.

0x2.1 Механизм слешинга и подотчетность

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

Требование к стейку: В основной сети разработчики должны поддерживать стейк в 500 тыс. HYPE. Даже если разработчик останавливает все свои рынки, он должен продолжать поддерживать его в течение 30 дней (ответственность не исчезает сразу после остановки торговли).

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

Процент слешинга определяется голосованием валидаторов с учетом верхних пределов:

• Неверное состояние / длительный простой: до 100%
• Кратковременный простой: до 50%
• Деградация производительности: до 20%

Слэшнутые токены сжигаются, а не перераспределяются.

В рамках HIP-3 риск разработчика в основном исходит из двух источников: внутренняя неверная настройка параметров и внешние зависимости от оракулов. В следующих разделах эти два источника рассматриваются подробно и объясняется, как они могут привести к слешингу.

0x2.2 Риски внутренней неверной настройки параметров

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

Эти риски в значительной степени детерминированы и предотвратимы. При достаточной осторожности, проверке и операционной дисциплине большинство внутренних ошибок конфигурации можно избежать. Хотя они важны, это не самые структурно сложные риски в рамках HIP-3.

1. setOracle

Цены оракулов обычно поступают с серверов ретрансляторов разработчика, что вводит риск централизации. Если закрытый ключ утечет или ретранслятор подвергнется DDoS-атаке, цена оракула рынка может быть злонамеренно манипулирована или оставаться расходящейся в течение длительного времени.

2. haltTrading

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

3. setMarginTableIds & InsertMarginTable

• InsertMarginTable: определяет новую таблицу маржи, указывая требования к марже и максимальное кредитное плечо для класса активов.
• setMarginTableIds: привязывает рынок к указанному marginTableId.

Для рынка с низкой ликвидностью / недостаточным маркет-мейкингом установка слишком высокого максимального кредитного плеча увеличивает вероятность запуска ADL.

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

4. setMarginModes

В настоящее время HIP-3 допускает только изолированную маржу, а в будущем может поддерживать кросс-маржу. В рамках DEX, объединяющего рынки с высокой и низкой ликвидностью, кросс-маржа может привести к распространению рисков, когда убытки на неликвидных рынках распространяются на ликвидные рынки. Поэтому, пока официальная команда не предоставит зрелое решение, разработчикам не рекомендуется вводить кросс-маржу.

0x2.3 Риски внешних зависимостей от оракулов

Для активов 24/7 основной риск заключается в точности и стабильности сторонних сервисов оракулов, а также рисках централизации серверов ретрансляторов, обсуждавшихся ранее. Любой сбой, задержка или манипуляция в этих внешних зависимостях может напрямую повлиять на целостность ценообразования и последующие контроли рисков.

Для активов не 24/7 поверхность риска значительно шире и в основном сосредоточена на том, как цены оракулов получаются или вычисляются в неторговые часы.

Взяв в качестве примера trade.xyz, в периоды вне рынка цены определяются комбинацией последней доступной внешней цены оракула и внутренних рыночных цен. В выходные дни рынки бессрочных акций часто страдают от сильно сниженной ликвидности — книги ордеров становятся тонкими, а маркет-мейкеры сокращают котировки — в то время как внешние цены оракулов недоступны для обеспечения привязки. Несмотря на жесткое ограничение на движение цены (например, 1 / max_leverage), это ограничение все равно может быть слишком свободным для активов с низкой волатильностью. Движения цен в этом диапазоне, тем не менее, могут запустить масштабные ликвидации или даже события ADL.

14 декабря 2025 года рынок XYZ100-USDC на trade.xyz — бессрочный контракт, отслеживающий NASDAQ-100, — подвергся манипуляции. Атакующий открыл шорт на 398 XYZ100 (примерно $10 млн USDC ноциональной экспозиции), вызвав серьезную отвязку цены. Большое количество длинных позиций было ликвидировано, а сами ликвидации еще больше подтолкнули цены вниз, что в конечном итоге привело к ликвидации длинных позиций на сумму примерно $13 млн USDC.

С другой стороны, в неторговые часы отсутствие непрерывной и внешне привязанной цены оракула вынуждает рынки полагаться на ограниченную внутреннюю ценовую полосу, сформированную из «последней внешней цены + внутренней книги ордеров» (например, trade.xyz ограничивает макс. колебание до 1/max_leverage).

Наиболее критический риск возникает в момент возобновления торгов. Внешние рынки могут внезапно предоставить четкую и авторитетную эталонную цену. Если эта цена демонстрирует значительный разрыв относительно внутреннего ценообразования в нерабочее время, система сталкивается с двумя неблагоприятными путями: либо цены остаются ограниченными (clamped), что приводит к серьезному расхождению между внешней справедливой стоимостью и торгуемыми ценами, либо система быстро переключается обратно на внешнюю привязку, запуская резкое переоценивание. Оба сценария могут сконцентрировать ликвидационное давление в коротком временном окне и, в экстремальных случаях, привести к всплеску событий ADL.

0x3 Контроль рисков разработчика

Сама по себе дисциплина конфигурации не может устранить риск. Наиболее эффективные стратегии минимизации направлены на снижение зависимости от сбоев оракулов.

0x3.1 Выбор стабильных оракулов

Для активов, не торгуемых 24/7, таких как акции, основной вызов заключается в ценообразовании в нерабочие часы. В эти периоды надежные и внешне привязанные ценовые ориентиры редки, что делает рынки более восприимчивыми к манипуляциям или эндогенному дрейфу в условиях низкой ликвидности.

В настоящее время отраслевые подходы в целом делятся на два направления:

• Приостановка обновлений оракулов и ограничение торговли в нерабочее время. Например, протокол Lighter принимает только ордера "reduce-only", когда базовый рынок закрыт. Протоколы, такие как Ostium, дополнительно снижают максимальное кредитное плечо в нерабочее время и принудительно ликвидируют позиции, превышающие новые лимиты.
• Принятие механизма «внутреннего ценообразования», как это видно на trade.xyz, где протокол продолжает функционировать в нерабочее время, полагаясь на внутреннюю ликвидность и алгоритмы ценообразования, когда внешние данные недоступны.

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

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

• Blue Ocean ATS. Как площадка для внебиржевой/ночной торговли, она может обеспечить определенную степень непрерывного ценового ориентира во время закрытий (более своевременно, чем «последнее закрытие»), помогая генерировать цену оракула для периода закрытия или служа мониторинговым базисом для отвязки.
• Котировки IG Weekend CFD. Котировки CFD на выходные могут предоставить альтернативный ценовой сигнал, отражающий «ожидания рынка на выходные», подходящий в качестве внешнего якоря или мониторингового сравнения во время закрытий, чтобы помочь заранее обнаружить вероятное направление и величину «разрыва на открытии».

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

0x3.2 Проверка цен

В рамках HIP-3 цены оракулов передаются с серверов ретрансляторов под управлением разработчика, что создает опасения по поводу централизации. Чтобы смягчить это, разработчикам рекомендуется внедрить структуру проверки цен, которая позволяет любому пользователю или учреждению проверять корректность и справедливость ценообразования вне сети — аналогично RedStone, который упаковывает цены вместе с источниками данных и криптографическими доказательствами.

1. Прозрачность данных

• Спецификация алгоритма: публичное раскрытие алгоритмов ценообразования и логики вычислений.
• Список источников данных: все источники должны быть публичными, невосприимчивыми к манипуляциям разработчика и задокументированными с подробными интерфейсами и параметрами.
• Правила отправки цен: разрешения, условия запуска, частота обновления и ограничения волатильности для setOracle.

2. Доказательства цен (Price Proofs)

Для каждого вызова setOracle генерируется соответствующее доказательство, содержащее:

• Входные данные: необработанные (или нормализованные) ответы от каждого источника данных на момент взятия выборки.
• Вычисления: воспроизводимые промежуточные значения на каждом этапе вычисления.
• Выходные данные: цена оракула, представленная в сети.

Каждое доказательство сериализуется в proofHash, который затем подписывается oracleUpdater.

3. Внутрисетевые обязательства (On-Chain Commitments)

• Ведение последовательного списка записей proofHash в дереве Меркла.
• Периодическая (например, ежечасная или ежедневная) публикация MerkleRoot в сети.

4. Проверка

• Предоставление инструментов с открытым исходным кодом или веб-страницы, где пользователи вводят временной диапазон или хеш транзакции setOracle.
• Проверка подписей, временных меток, MerkleRoot и т. д.
• Пересчет цен оракула с использованием публичного алгоритма для сравнения.

0x3.3 Мониторинг рисков

Проверка цен делает setOracle пересчитываемым и аудируемым, устанавливая, заслуживают ли доверия потоки цен. Однако это не может защитить от ухудшения ситуации на живом рынке. Сбои потоков данных, расхождение цен и деградация ликвидности — в сочетании с большим открытым интересом (OI) — могут легко перерасти локализованные аномалии в системные риски, такие как каскадные ликвидации или даже события ADL.

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

Чтобы сделать мониторинг действенным, а не фрагментарным, мы организуем сигналы в три уровня, каждый из которых сопоставлен с определенным режимом сбоя и приоритетом реагирования.

• Мониторинг со стороны цен обнаруживает сбои потоков оракулов и отвязку, которые могут аннулировать контроли рисков в источнике, поэтому он считается наивысшим приоритетом и обычно решается через переключение ретрансляторов (failover), лимиты открытого интереса и снижение кредитного плеча.
• Мониторинг со стороны книги ордеров захватывает уход ликвидности и спуфинг (spoofed) глубины, которые усиливают проскальзывание ликвидации и риск дефицита, поэтому вмешательства направлены на ограничение инкрементальной экспозиции и принудительное делевериджирование при увеличении хрупкости.
• Мониторинг со стороны позиций отслеживает быстрое накопление открытого интереса и одностороннюю концентрацию, которые делают рынки уязвимыми к каскадам, и, как правило, имеет более низкий приоритет, чем сигналы по ценам и ликвидности, служа в основном слоем раннего предупреждения, который информирует о более жестких лимитах и повышенных оповещениях.

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

1. Мониторинг со стороны цен

а) Сбой потока оракула

Метрики:

• Использовать внутрисетевые наблюдаемые данные, чтобы судить о том, завис ли поток:

Пороговые значения:

• Уровень 1: ( ∆t > 5с ) — процесс ретранслятора может быть зависшим или заблокированным.
• Уровень 2: ( ∆t > 15с ) — внутрисетевые цены могут быть сильно отвязаны и все больше подвержены рыночному влиянию.

Действия:

• Уровень 1: выполнить проверки работоспособности ретранслятора, переключиться на резервные ретрансляторы и выпустить оповещения с диагностикой состояния.
• Уровень 2: вызвать setOpenInterestCaps для уменьшения лимита OI.

б) Отвязка цены (Price Depegging)

Метрики:

• Сигнал A (d1): отклонение между маркировочной ценой и ценой оракула.

• Сигнал B (d2): отклонение между средней ценой книги ордеров и ценой оракула.

• Сигнал C (d3): отклонение между маркировочной ценой и средней ценой.

• Сигнал D (ext_diff): отклонение между ценой оракула и внешней эталонной ценой.

Логика пороговых значений:

• Уровень 1: хотя бы 2 из A, B, D превышают пороговые значения.
• Уровень 2: хотя бы 3 из A, B, C, D превышают пороговые значения в течение X секунд.

Действия:

• Уровень 1: снизить лимит OI через setOpenInterestCaps.
• Уровень 2: постепенно обновлять таблицы маржи, чтобы снизить максимальное кредитное плечо по уровням, и включить механизмы ограничения (clamp) на ретрансляторах.
• Уровень 3: постоянные оповещения в условиях Уровня 2. Разработчик затем оценивает, нужно ли вызывать haltTrading.

2. Мониторинг со стороны книги ордеров

а) Уход ликвидности

Метрики:

• depth_band(±x%): ликвидность книги ордеров, доступная в пределах ±x% от средней цены.
• spread = bestAsk - bestBid: ценовой спред для измерения расширения спреда.
• aggressiveVolume_Δt: объем тейкеров (taker) в течение Δt (агрегированный по стороне сделки).
• impact_ratio: индикатор рыночной хрупкости (более высокие значения указывают на большую уязвимость к ценовому воздействию).

Паттерны риска:

• depth_band уменьшается, в то время как spread и impact_ratio увеличиваются.

Действия:

• Уровень 1: установить OI cap = current OI через setOpenInterestCaps, ограничивая инкрементальные позиции.
• Уровень 2: принудительное делевериджирование через setMarginTableIds с одновременной ликвидацией высокорисковых позиций с высоким кредитным плечом.

б) Спуфинговая ликвидность (Spoofed Liquidity)

Паттерны риска:

• Внезапные всплески в depth_band, за которыми следует коллапс в короткий промежуток времени.

Действия:

• Уровень 1: вызвать setOpenInterestCaps для установки OI cap = current OI.
• Уровень 2: если в сочетании с сильной отвязкой, рассмотреть возможность приостановки рынка.

3. Мониторинг со стороны позиций

Мониторинг со стороны позиций не пытается предсказать направление цены. Вместо этого он выявляет переходы от сбалансированной торговой активности к накоплению односторонних позиций. Когда OI накапливается быстро, позиции становятся высококонцентрированными, а PnL большинства достигает экстремальных значений, даже незначительные экзогенные шоки могут запустить каскады ликвидаций или события ADL.

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

а) Чрезмерный краткосрочный OI

Метрики:

• OI_notional: ноциональный открытый интерес.
• Volume_24h_notional: 24-часовой ноциональный объем.

Быстро растущий коэффициент указывает на переход от активного оборота к накоплению спекулятивных позиций и часто предшествует резкой волатильности.

Действия:

• Уровень 1: запуск оповещений при превышении пороговых значений.

б) PnL большинства

Сторона большинства относится к стороне (длинная или короткая), на которой больше держателей позиций в рамках наблюдаемого окна.

Метрики:

• avgEntry_major: средняя цена входа позиций стороны большинства.
• size_major: совокупный размер позиции стороны большинства.
• equity_major: совокупный собственный капитал стороны большинства.

PnL и его коэффициент для стороны большинства определяются следующим образом:

Действия:

• Уровень 1: оповещение о нарушении порогового значения.
• Уровень 2: если ситуация сохраняется, рассмотреть возможность вызова setOpenInterestCaps для снижения лимита OI.

0x4 Заключение

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

Столь же очевидно, что HIP-3 не устраняет риски. Он перепозиционирует и видоизменяет их. Ответственность, ранее поглощавшаяся контролями рисков на уровне платформы, теперь в значительной степени лежит на разработчиках через их входные данные и операционное качество. Это включает ценообразование оракулов и частоту обновлений через setOracle, выбор и ограничения markPx, дизайн многоуровневого кредитного плеча через таблицы маржи, диапазоны ценообразования в нерабочие часы для активов не 24/7 и мощные средства контроля, такие как haltTrading, которые могут либо ограничить убытки, либо усилить их. При низкой ликвидности неверная настройка или операционный сбой могут быть усилены до каскадов ликвидаций, убытков от разрывов и, в конечном итоге, событий ADL. Вопрос больше не в том: «Можно ли разместить рынок?», а скорее в том: «Может ли он оставаться стабильным после размещения?».

На уровне протокола Hyperliquid решает эту проблему перераспределения риска путем преобразования прав в подотчетные права. Стейкинг в сочетании со слешингом под управлением валидаторов устанавливает четкие экономические последствия за ошибочные действия разработчика. Ограничения на ценообразование и кредитное плечо, включая clamp-ограничения, интервалы обновления, лимиты волатильности и требования к изолированной марже, направлены на удержание наиболее опасных рисков «хвоста» в управляемых границах. В рамках этой концепции ценностное предложение HIP-3 становится ясным: масштабирование через открытость, безопасность через ограничения и долгосрочная устойчивость через проверяемость и подотчетность.

HIP-3 не делает листинг более свободным. Он делает его более стандартизированным, развертываемым, эксплуатируемым и подлежащим слешингу. Будет ли эта стандартизация работать в масштабе, в конечном итоге зависит от реального качества дизайна оракулов, параметров кредитного плеча и риска, а также операционного мониторинга. Если вы проектируете правила доступа к рынку, шаблоны параметров, системы оповещения, экстренные рабочие процессы поверх HIP-3 или если вам требуется аудит и постоянная поддержка безопасности, не стесняйтесь обращаться в BlockSec по адресу [email protected].

Ссылки

[1] https://hyperliquid.gitbook.io/hyperliquid-docs/hyperliquid-improvement-proposals-hips/hip-3-builder-deployed-perpetuals

[2] https://hyperliquid.gitbook.io/hyperliquid-docs

О компании BlockSec

BlockSec — поставщик услуг комплексной безопасности блокчейна и крипто-комплаенса. Мы создаем продукты и услуги, которые помогают клиентам проводить аудит кода (включая смарт-контракты, блокчейны и кошельки), перехватывать атаки в режиме реального времени, анализировать инциденты, отслеживать незаконные средства и соблюдать обязательства AML/CFT на протяжении всего жизненного цикла протоколов и платформ.

BlockSec опубликовала множество статей по безопасности блокчейна на престижных конференциях, сообщила о нескольких атаках нулевого дня на DeFi-приложения, заблокировала множество взломов, спасая более 20 миллионов долларов, и обеспечила безопасность миллиардов криптовалютных активов.

• Официальный сайт: https://blocksec.com/

• Официальный аккаунт в Twitter: https://twitter.com/BlockSecTeam

• 🔗 Услуги аудита BlockSec : Отправить запрос

• 🔗 Приложение безопасности Phalcon: Записаться на демо

• 🔗 Комплаенс Phalcon