Как сравнивать ликвидность разных HIP-3 DEX

Когда этот сигнал нужен трейдеру

Материал для трейдеров, уже работающих с perpetual на Hyperliquid и знакомых с funding, margin tiers и структурой HyperCore. Предполагается понимание разницы между mark price и oracle price, базовое знание API endpoints и опыт оценки глубины книги перед крупным ордером. Подходит тем, кто планирует торговать на нескольких HIP-3 DEX одновременно и хочет выстроить системный подход к сравнению ликвидности вместо ориентации на название тикера.

Почему один тикер на HIP-3 — это не один рынок

HIP-3 позволяет deployer запускать отдельный perpetual DEX поверх общего стека HyperCore. Deployer отвечает за market definition, oracle, лимиты leverage и settlement своего DEX самостоятельно, и у каждого DEX собственные order books, margining и настройки. Инфраструктура снизу общая, параметры сверху — нет.

Если вы видите один и тот же тикер, развёрнутый двумя разными deployer, это не дублирование одного рынка, а два независимых order books с потенциально разным oracle источником, разной margin table и разными caps на open interest. Дальше в этом материале разбирается, какие именно параметры нужно проверять и в каком порядке, чтобы не спутать эти рынки между собой.

Какие параметры реально определяют ликвидность DEX

Deployer actions включают регистрацию актива, oracle updates, funding multipliers, haltTrading, margin tables и OI caps. Каждая настройка напрямую влияет на то, сколько капитала может безопасно двигаться на рынке и по какой цене.

OI cap ограничивает суммарный размер открытых позиций на DEX: при низком cap крупная позиция физически не может быть открыта независимо от глубины книги в моменте. Margin table определяет требования по марже на разных уровнях позиции, что влияет на реально доступное плечо и устойчивость рынка к резким движениям. Oracle источник задаёт, от какой цены считается mark price и funding — если oracle обновляется реже или зависит от менее ликвидного внешнего рынка, риск разрыва между ценой на DEX и справедливой ценой выше.

Почему mid price не говорит о реальной ликвидности

HyperCore ведёт onchain книгу ордеров, и анализ исполнения должен строиться на доступном объёме по уровням, очереди maker-заявок и spread, а не только на mid price. На HIP-3 это особенно важно: разные deployer DEX могут показывать формально похожую mid price при кардинально разной глубине за этой ценой.

Сравнивая два HIP-3 DEX с одним активом, вы можете увидеть почти идентичную mid price, а фактическую ликвидность на расстоянии одного-двух процентов от текущей цены — отличающуюся в разы. Это станет заметно только в момент попытки исполнить объём: market ордер поглотит доступные уровни на тонком DEX и даст среднюю цену fill, заметно отклонившуюся от той mid price, которую вы видели перед отправкой.

Пошаговый план сравнения ликвидности перед сделкой

Сравнение двух или более HIP-3 DEX с похожим активом требует последовательной проверки нескольких слоёв, а не одного взгляда на цену.

1. 01
   Определить конкретный deployer DEX

   Через dex namespace убедиться, на каком именно deployer DEX вы собираетесь торговать — один тикер может существовать на нескольких DEX одновременно с разными order books, oracle и margin table.

2. 02
   Проверить глубину книги на нужную дистанцию

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

3. 03
   Сверить oracle источник и margin table

   Через deployer actions или официальный интерфейс проверить, откуда берётся oracle price для funding и mark price, и какие margin requirements действуют на разных уровнях позиции этого DEX.

4. 04
   Оценить OI cap относительно планируемого объёма

   Убедиться, что текущий open interest DEX и его cap оставляют пространство для вашей позиции без риска упереться в лимит или столкнуться с halt trading.

5. 05
   Сравнить итоговую стоимость исполнения между DEX

   Рассчитать ожидаемую среднюю цену fill на каждом DEX с учётом глубины, а не сравнивать только заголовочную комиссию или mid price.

Условный сценарий: один тикер, две глубины книги

Условный пример показывает механику расчёта, а не реальные данные конкретного DEX. Deployer DEX A по активу условно показывает 500 000 USD суммарного объёма на первых трёх уровнях выше mid price. На deployer DEX B с тем же тикером верхние уровни книги тоньше — около 120 000 USD на той же дистанции, хотя заявленная цена почти совпадает с DEX A. OI cap на DEX B при этом условно установлен на уровне 2 000 000 USD, и текущий open interest уже составляет 1 700 000 USD — свободного пространства остаётся немного.

Если отправить market ордер на 300 000 USD на оба условных DEX без предварительной проверки глубины, на DEX A он пройдёт по уровням с суммарным объёмом 500 000 USD, и средняя цена fill отклонится от исходной mid price незначительно. На DEX B тот же ордер поглотит все 120 000 USD на верхних уровнях и продолжит забирать более глубокие уровни книги, из-за чего среднее отклонение цены fill окажется заметно больше, а часть объёма ещё и упрётся в оставшиеся 300 000 USD свободного OI cap. При таких вводных на DEX B разумнее разбить ордер на части и использовать лимитные заявки с контролем проскальзывания, либо перенести основной объём на DEX A с более глубокой книгой и запасом по OI cap.

Типичные ошибки при сравнении HIP-3 рынков

Частая ошибка — воспринимать совпадение тикера как гарантию одинаковой ликвидности и риска, хотя каждый DEX ведёт собственную книгу, oracle и margin table независимо от названия актива.

Вторая ошибка — сравнивать DEX по одной опубликованной комиссии без учёта funding и проскальзывания: итоговая стоимость сделки складывается из этих трёх компонентов вместе, и структура комиссий зависит от rolling 14-day weighted volume, роли maker/taker и других параметров аккаунта. DEX с формально меньшей комиссией может оказаться дороже в реальном исполнении из-за более тонкой книги. Третья ошибка — игнорировать OI cap при планировании крупной позиции: попытка открыть объём, приближающийся к cap DEX, может привести к частичному исполнению или к halt trading, который deployer вправе применить при приближении к лимиту.

Когда разница между DEX становится критичной для позиции

Разница в глубине книги, oracle и margin table между двумя HIP-3 DEX не всегда заметна на небольших размерах позиции — на объёме, который укладывается в верхние уровни книги, итоговая цена fill будет близкой независимо от того, какой DEX выбран. Разница становится критичной именно при масштабировании: чем крупнее планируемый объём относительно доступной глубины и OI cap конкретного DEX, тем сильнее расходятся реальные условия исполнения даже при идентичном тикере и близкой mid price.

Это особенно важно учитывать при построении позиции частями или при увеличении размера в рамках уже открытой сделки: open interest DEX может приблизиться к cap, а книга на нужных уровнях — истончиться из-за действий других участников между вашими входами. Проверку глубины, oracle источника и margin table стоит повторять перед каждым существенным увеличением позиции, а не только перед первой сделкой — сама логика проверки та же, что описана в пошаговом плане выше, но применённая к новому снимку рынка.

Как проверять параметры DEX через API

Для трейдера, который держит позиции на нескольких HIP-3 DEX, важно получать через API актуальный mark price, oracle price, open interest и funding именно того DEX, где планируется сделка. Метод metaAndAssetCtxs возвращает universe и параллельный массив contexts, сопоставление между ними строится строго по позиции в массиве и привязано к dex namespace — смешивать значения с разных deployer DEX в одной таблице без явной привязки к namespace нельзя, иначе легко приписать одному активу параметры другого.

Практический вывод из этого ограничения — не искать единый агрегатор всех HIP-3 DEX, а закрепить для себя фиксированный порядок ручной проверки перед каждой сделкой: namespace, глубина книги, oracle, margin table, OI cap. Такая проверка требует обращения к каждому DEX по отдельности через официальный интерфейс или API, что менее удобно, чем работа с одним централизованным рынком, где параметры контракта закреплены в одном месте, но именно повторяемость этой последовательности, а не визуальное сходство тикеров, снижает риск спутать параметры разных DEX в момент, когда решение нужно принять быстро.

Комиссии, funding и проскальзывание как единая стоимость сделки

На HIP-3 DEX итоговая стоимость исполнения складывается не из одной цифры комиссии, а из трёх компонентов вместе: опубликованной ставки, funding и проскальзывания от глубины книги. Ставка комиссии зависит от rolling 14-day weighted volume и роли maker или taker, и эти параметры общие для аккаунта на HyperCore, но глубина книги и oracle-риск у каждого DEX свои. Поэтому DEX с более низкой заголовочной комиссией может обходиться дороже в реальном исполнении, если книга на нём тоньше и проскальзывание перекрывает разницу в ставке.

Funding на HyperCore рассчитывается ежечасно и привязан к premium между ценой perpetual и oracle price; отображаемая восьмичасовая ставка — это удобная для восприятия величина, а не фактическая периодичность списания. На HIP-3 DEX с менее надёжным или более редко обновляемым oracle источником funding может резче реагировать на локальные отклонения цены от справедливой, что добавляет ещё один слой риска сверх глубины книги. При сравнении двух DEX с одинаковым тикером стоит закладывать это в расчёт итоговой стоимости позиции, а не рассматривать funding как отдельную и второстепенную переменную.