Как ранжировать рынки по объёму, OI, funding и spread

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

Материал для трейдеров, уже работающих с perpetual на CEX или DEX, знакомых с механикой funding, margin tier и книгой ордеров. Подходит тем, кто строит собственный скрининг рынков или дашборд метрик и хочет понимать, какие данные Hyperliquid отдаёт через API и как их правильно сопоставлять, а не полагаться на единственную опубликованную цифру.

Почему одной метрики недостаточно для выбора рынка

Объём отвечает на вопрос «сколько торговали», а не «можно ли торговать сейчас с приемлемым исполнением». Open interest отдельно тоже не различает рост OI при падении цены и рост OI при росте цены — это разные события с разной устойчивостью движения. Funding при изолированном чтении вводит в заблуждение: положительная ставка говорит о текущем перекосе спроса в сторону лонгов, а не о качестве рынка — устойчиво высокий funding удобен для carry-стратегии и опасен для направленного входа из-за риска резкого разворота ставки.

Рабочий порядок фильтрации ниже — авторская практика, а не официальная методология Hyperliquid: сначала отсекаются рынки, где нельзя исполнить нужный размер без чрезмерного проскальзывания, затем среди оставшихся сравниваются OI и funding для оценки направленного риска, и только в последнюю очередь объём используется как подтверждающий сигнал.

Откуда брать данные для ранжирования

Для контекста рынка используется метод metaAndAssetCtxs через POST /info. Он возвращает universe — список активов, и параллельный массив contexts, где для каждого актива есть mark price, oracle price, open interest, funding и volume. Сопоставление universe и contexts происходит строго по позиции в массиве, а не по тикеру: объединять их нужно сразу после получения ответа, до любой сортировки или фильтрации, иначе привязка метрик к активам ломается.

На рынках, запущенных через HIP-3, добавляется dex namespace: один и тот же тикер на разных deployer dex — это разные order books с разным oracle и margin table. Их нельзя смешивать в одном скоринге без явного разделения по dex — этот момент подробнее разобран ниже применительно к параметрам deployer.

Как оценивать глубину и spread, а не только цену

HyperCore ведёт onchain книгу ордеров, и это определяет, как оценивать стоимость входа. Market-ордер исполняется против реальных встречных заявок, и цена зависит от объёма, доступного выше или ниже текущей цены на момент отправки. Для скоринга нужно оценивать не mid price, а доступный объём на уровнях, очередь maker-заявок и итоговый spread между лучшими bid и ask.

Условный пример, иллюстративный: позиция на 50 000 USD, а суммарный объём на первых трёх уровнях книги выше mid price составляет только 20 000 USD. Оставшиеся 30 000 USD исполняются на более глубоких уровнях по худшей цене, и средняя цена сделки может отклониться от лучшего ask на условные 0,4–0,6% вместо долей процента, характерных для глубокой книги. При этом суточный объём такого рынка может быть высоким за счёт множества сделок за много часов, а не текущей глубины в момент входа — это и есть систематическая ошибка скоринга, смешивающего исторический оборот с текущим состоянием книги.

Шесть сочетаний цены и OI как элемент скоринга

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

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

Funding как сигнал позиционирования, а не отдельная метрика доходности

Funding на Hyperliquid — peer-to-peer платёж между long и short, рассчитываемый каждый час и привязанный к premium между ценой perpetual и oracle price. Отображаемая восьмичасовая ставка — удобная для восприятия величина, а не фактическая периодичность списания. Для скоринга важна история ставки за период, сопоставимый с горизонтом удержания позиции, а не разовое значение в момент запроса: ставка может быть близка к нулю сейчас, но иметь устойчивый перекос за предыдущие дни.

Держать сторону с положительным funding — это направленная позиция с риском цены, а не арбитраж. Арбитражем становится только связка, где funding-нога захеджирована противоположной позицией, например spot против perpetual, закрывающей ценовой риск. Без хеджа вы получаете funding, но принимаете риск ликвидации, разворот ставки и maintenance requirement, зависящий от margin tier. В скоринге funding работает как фильтр перекоса позиционирования: устойчиво высокая ставка в одну сторону на протяжении нескольких дней требует дополнительного запаса по марже при входе против неё.

Особенность ранжирования на HIP-3 рынках

Отдельная сложность — рынки, запущенные через HIP-3, механизм, позволяющий deployer создать отдельный perpetual dex внутри инфраструктуры Hyperliquid. Как уже отмечено выше, один тикер на разных deployer dex — это разные order books с разным oracle и margin table, и их метрики нельзя усреднять без разделения по dex namespace.

Deployer actions включают регистрацию актива, oracle updates, funding multipliers, halt trading, margin tables и OI caps. Качество рынка на HIP-3 нужно оценивать не только по объёму, OI и funding, но и по параметрам deployer dex — какой oracle используется, какой margin table применяется и установлен ли OI cap, ограничивающий масштабируемость позиции даже при формально хороших метриках ликвидности. Перед сравнением метрик HIP-3 рынка с основным dex нужно явно проверить dex namespace актива.

Последовательная фильтрация вместо единого балла

Попытка свернуть все метрики в один взвешенный числовой балл теряет ровно ту информацию, которая делает связку метрик полезной: разницу между ростом OI при росте и при падении цены, разницу между стабильным и колеблющимся funding, разницу между суточным объёмом и текущей глубиной книги. Если два актива получают одинаковый итоговый балл, но один прошёл бы фильтр по глубине, а другой нет, единая формула эту разницу скрывает.

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

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

Порядок шагов, который переносится в скрипт или таблицу для регулярного скрининга рынков.

1. 01
   Собрать universe и contexts

   Отправить metaAndAssetCtxs через POST /info и сразу объединить массивы universe и contexts по позиции, до какой-либо сортировки. Отдельно зафиксировать dex namespace для каждого актива, чтобы не смешать основной рынок с HIP-3 рынком того же тикера.

2. 02
   Извлечь объём, OI и funding

   Для каждого актива сохранить mark price, oracle price, open interest, суточный объём и текущую funding rate вместе с историей ставки за период, сопоставимый с горизонтом удержания позиции.

3. 03
   Проверить spread и глубину книги

   Через L2 book или WebSocket-подписку получить лучшие bid и ask, а также объём на первых нескольких уровнях. Сопоставить доступный объём с планируемым размером позиции для оценки проскальзывания.

4. 04
   Отфильтровать тонкие и устаревшие рынки

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

5. 05
   Сравнить OI и funding у оставшихся кандидатов

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

6. 06
   Ранжировать и проверить лидеров вручную

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

Дисциплина чтения API и агентский кошелёк

POST /info — единая точка входа, но за ней скрыты запросы разного типа: публичная metadata рынков не требует подписи, а account queries требуют master или subaccount address. Типичная ошибка — фильтрация или сортировка массива contexts или universe до их объединения по позиции, что разрывает привязку метрик к активам без явной ошибки в логах. Для WebSocket важно помнить, что подписки не переживают разрыв соединения автоматически: устаревший снимок после реконнекта может дать неверную оценку глубины на волатильном рынке, поэтому свежесть данных проверяется по метке времени внутри сообщения.

Agent wallet, также называемый API wallet, предназначен для подписи действий от имени master или subaccount через exchange endpoint — это не адрес, привязанный к балансу и позициям, поэтому запрос account state через него часто возвращает пустой результат. Для чтения позиций, баланса и открытых ордеров дашборду нужен именно master или subaccount address. После deregistration адрес agent wallet не следует повторно использовать из-за жизненного цикла nonce state.