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

Когда 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, чтобы остановить торговлю, отменить все ордера и рассчитаться по текущей цене маркера.

Протокол накладывает ограничения — цена маркера не может измениться более чем на ±1% за обновление, и все цены ограничены в пределах 10x от начального значения дня. Но эти ограничения — не наручники. В рамках этих рамок ваши решения определяют, будет ли ваш рынок процветать или рухнет в каскад ликвидаций.

Определение оракула: критический момент для стабильности рынка

Определение оракула — это точка, где судьба вашего рынка расходится. Это первое, что вы устанавливаете, и самое сложное исправить. Вот почему это так важно.

Что на самом деле означает определение оракула

В HIP-3 определение оракула включает три слоя:

1. oraclePx (обязательное): основной ценовой якорь. Обычно он берется с вашего relayer-сервера, который агрегирует внешние источники (Pyth, DEX AMMs, цены с CEX). Это ваша точка отказа, если relayer упадет или подвергнется DDoS.

2. MarkPx (необязательное): пользовательские цены, которые вы отправляете — до 2 наборов — для расчета фактического уровня ликвидации. Здесь проявляются разработчики с собственными моделями ценообразования, но также и те, кто допускает плохие решения, убивающие рынки.

3. ExternalPerpPx (обязательное): взвешенное медианное значение цен по нескольким CEX. Это служит проверкой здравого смысла, не позволяя вашему изолированному рынку отклоняться слишком далеко от общего консенсуса.

Затем система объединяет эти слои в финальную цену маркера: медиану из (локального ордербука, ваших отправленных цен )и ExternalPerpPx###. Если любой слой выходит из строя, система переходит к следующему. Если все сломаются — вы торгуете вслепую.

( 24/7 vs. Не-24/7 активы: два разных определения оракула

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

Для не-24/7 активов )акции, индексы, товары(: определение оракула становится экзистенциальным. Например, NASDAQ-акции. В рабочие часы Pyth дает чистые цены. После закрытия рынка внешних цен нет. Теперь ваше определение оракула должно выжить в вакууме.

Ловушка в том, что в нерабочие часы механизм setOracle не может получить реальную рыночную цену. Поэтому вы полагаетесь на «последний закрытие + внутреннее давление ордербука». Но без внешнего якоря внутреннее давление — это зеркало: цена отражает только то, что внутри вашего рынка, а не реальную стоимость актива.

Протокол накладывает ограничение на движение цены — ±1/maxLeverage, например, 10x — максимум 10%. В часы высокой волатильности, это разумно. Но на низколиквидной акции в выходные, при нулевых внешних ценах, 10% — это достаточно, чтобы ликвидировать весь портфель и запустить каскад ADL.

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

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

) Триггер ликвидации

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

Цена ликвидации = )номинальная стоимость × требование маржи( / размер позиции

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

) Когда ликвидация превращается в ADL

Настоящий ужас начинается, когда ликвидационные ордера не находят покупателей. Представьте, что ваша цена маркера показывает $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 перед их декабрьским инцидентом.

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

Лучшее определение для не-24/7 активов включает дополнительные якоря:

• Blue Ocean ATS: обеспечивает цены на акции после часов. Менее ликвиден, чем в рабочие часы, но это реальные рыночные цены, а не оценки внутреннего ордербука.
• IG Weekend CFD: дает сигналы о предполагаемом движении открытия. В совокупности с последним закрытием + внутренним ценой, они дают шанс вашему определению оракула оставаться привязанным.

Эти дополнения не заменяют тщательное проектирование оракула — они его дополняют. Ваше определение оракула должно быть: «В рабочие часы — Pyth. В нерабочие — последний Pyth, скорректированный по Blue Ocean ATS mid + внутреннему давлению ордербука, ограниченный в пределах ±X%».

Контроль рисков оракула: стратегии мониторинга стабильности ценовых потоков

Здесь теория встречается с практикой. Ваше определение оракула — только часть системы мониторинга.

Обнаружение сбоев ценовых потоков

Ваш relayer — это единственная точка отказа. Если он упадет или потеряет соединение, setOracle перестанет работать. В течение 10 секунд система перейдет к чистому ценообразованию ордербука. Для ликвидных рынков с узкими спредами это приемлемо. Для остальных — ловушка ликвидации.

План действий:

• Уровень 1: при сбое потока цен >2.5 секунд — немедленно проверить relayer, переключиться на резервную инфраструктуру, опубликовать отчет.
• Уровень 2: при сбое >10 секунд — вызвать setOpenInterestCaps, чтобы остановить новые позиции. Существующие позиции могут закрываться. Это предотвратит каскады ликвидаций, пока вы восстанавливаете поток данных.

Дезякоринг оракула: когда ваше определение сдвигается

Даже если 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% от цены маркера. Типично: ±0.5%.
• Спредом: bestAsk - bestBid. Здорово: <0.1%. Опасно: >1%.
• Агрессивным объемом: объем тейкеров за последние Δt секунд. Если он превышает глубину, есть проблема.

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

Не-24/7 активы: определение оракула во время закрытия рынка

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

Инцидент December 2025 trade.xyz

14 декабря 2025 злоумышленники использовали именно этот сценарий. Они создали крупную короткую позицию в XYZ100 (на перпуту NASDAQ-100), когда рынок был малоликвиден. Атака:

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

Причина — слишком слабое определение оракула для не-24/7 активов. Цена с лимитом 10% левереджа кажется жесткой, пока не поймешь, что это — 10 процентных пунктов на акцию, которая может двигаться всего на 2-3%.

) Лучшее определение для не-24/7 активов

Ваше определение оракула должно включать:

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

Построение системы мониторинга рисков: отслеживание цен, глубины и позиций

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

( Канал 1: Индикаторы цен

Отслеживайте здоровье оракула каждые 1-2 секунды:

• задержка потока )время с последнего вызова setOracle$13M
• отклонение цены от внешних эталонов
• нарушения ограничений ###в пределах ±1% на продолжительное время###

( Канал 2: Индикаторы ордербука

Следите за глубиной и спредом каждые 5-10 секунд:

• глубина внутри ±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. Публикуйте ваше определение оракула: подробно укажите источники данных, частоту обновлений и fallback-логику. Прозрачность вызывает доверие и помогает выявить недостатки до того, как они вызовут сбой рынка.

2. Реализуйте системы доказательств: для каждого вызова setOracle генерируйте доказательство ###источники данных, шаги расчетов, результат(. Подписывайте его и публикуйте в Меркле-дереве на блокчейне ежечасно. Это позволяет публично аудитировать ваши решения по ценообразованию.

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

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

5. Разработайте процедуры эскалации: задокументируйте, когда и как вызываете haltTrading. Никогда не используйте это как произвольный рычаг — это аварийная тормозная система рынка.

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

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

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