Dashboard funding, OI и volume: архитектура данных

Что должна уметь система

Статья рассчитана на разработчиков и трейдеров, которые уже работают с Hyperliquid API и хотят построить дашборд или бота, использующего funding, open interest и volume как входные сигналы. Предполагается знакомство с REST/WebSocket, устройством perpetual-рынков и понятием margin tier.

Модель данных: два типа запросов в одном эндпоинте

POST /info — единая точка входа, но за фасадом скрыты два разных типа запросов. Первый — публичная metadata рынков: universe, asset contexts, свечи. Она не требует подписи и одинакова для всех вызывающих. Второй — account queries: позиции, баланс, открытые ордера. Для них обязателен конкретный адрес — master или subaccount, а не agent wallet. Смешивать эти типы в одной абстракции парсера — ошибка: структура ответа и требования к идентификации у них разные.

Для дашборда funding/OI/volume нужен именно первый тип — публичный market context. Метод metaAndAssetCtxs возвращает universe (список активов с параметрами) и параллельный массив contexts, где для каждого актива лежат mark price, oracle price, open interest, funding и volume. Это единый снимок по всем активам сразу: не нужен отдельный запрос на каждый тикер.

Сопоставление universe и contexts: где ломается привязка

Главная архитектурная ловушка metaAndAssetCtxs — сопоставление universe и contexts происходит строго по позиции в массиве: universe[i] соответствует contexts[i], и никак иначе. Если код фильтрует или сортирует один из массивов до объединения в пары, привязка ломается молча: данные остаются валидными по формату, но приписываются не тому активу — и ошибка не ловится визуальной проверкой значений.

Первым шагом обработки ответа должна быть сборка списка пар (universe[i], contexts[i]) в единую структуру — и только эта структура передаётся дальше по пайплайну. Любая логика, которая сортирует или фильтрует universe и contexts как два отдельных массива и полагается на сохранение порядка к моменту объединения, воспроизводит ту же ошибку под другим именем. Только после жёсткой связки каждого элемента universe с соответствующим contexts можно фильтровать по объёму, сортировать по funding или искать конкретный тикер.

HIP-3 dex namespace: один тикер — разные книги

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

Для равнозначных рынков стоит хранить в модели данных не просто symbol, а пару (dex, symbol) или полный идентификатор с namespace. Open interest и funding могут отличаться между dex даже для внешне идентичного актива, и без явного разделения дашборд покажет некорректно усреднённые или перепутанные цифры. Оценивать качество такого рынка стоит по совокупности параметров deployer dex: collateral, oracle, OI caps и фактическая книга, а не только по названию тикера.

Realtime-слой: WebSocket поверх снимка

Периодический опрос metaAndAssetCtxs через REST даёт снимок состояния рынка, но для дашборда, обновляющегося в реальном времени, добавляется WebSocket-слой с подписками на книгу, trades, candles и user fills. Его задача — не заменить REST-снимок, а дополнить его инкрементальными обновлениями между опросами.

Устойчивое подключение требует трёх слоёв защиты: переподписки на все каналы после reconnect, проверки свежести данных по временной метке или sequence внутри сообщения — а не по факту наличия соединения, и разделения источников для критичных решений. Документация прямо указывает, что reconnect, повторную подписку и freshness-контроль обязан обрабатывать клиент. Без этого дашборд после разрыва соединения продолжает показывать последний снимок как актуальный, и внешне это неотличимо от живого обновления — разница проявится только при сверке метки времени сообщения с текущим временем.

Онchain-книга как источник данных: что это меняет

HyperCore ведёт книгу ордеров onchain, поэтому info endpoint отдаёт единый снимок mark price, oracle price, open interest и funding по всем активам сразу — это тот же массив contexts, по которому реально происходит matching, а не отдельная витринная проекция под интерфейс. Это отличает пайплайн от схемы, где биржа держит внутренний матчинг-движок отдельно от публичного API и отдаёт наружу закэшированную витрину с собственной задержкой. Здесь дашборд получает те значения, на основе которых считается ликвидация и funding, без промежуточного слоя агрегации.

Не нужно сверять несколько разрозненных ручек (order book depth, funding history, OI) с разной частотой обновления — metaAndAssetCtxs возвращает их консистентно в одном ответе на один timestamp. Оборотная сторона: количество полей и их формат может меняться между версиями API, и дашборд, завязанный на порядок полей вместо именованных ключей, рискует сломаться при обновлении контракта ответа. Анализ фактического исполнения ордеров должен учитывать доступный объём по уровням книги, очередь maker-заявки и среднюю цену нескольких fills, а не только mid price.

Типичная ошибка интерпретации funding без OI и volume

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

Понять, что стоит за этой премией, можно только сопоставив funding с open interest и volume: растёт ли OI вместе с ценой (приток нового капитала в лонг) или падает (закрытие шортов без нового спроса). Поэтому funding, OI и volume должны отображаться как связка полей одного контекста, а не как независимые виджеты.

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

Account-специфичные данные: адрес вместо agent wallet

Если дашборд помимо рыночных метрик показывает позиции пользователя, для этих запросов нужен master или subaccount address. Agent wallet (API wallet) создаётся для подписи торговых действий от имени master или subaccount, а не для чтения состояния аккаунта: попытка использовать его для account queries часто возвращает пустой результат вместо явной ошибки, что усложняет отладку, потому что запрос формально выполняется успешно. После deregistration его адрес не стоит использовать повторно из-за состояния nonce — привязка «кто подписывает» и «кто читает баланс» должна храниться раздельно и не подменяться при ротации ключей.

Пошаговая сборка пайплайна данных

Ниже — последовательность операций, при которой сопоставление данных остаётся корректным на каждом этапе, от получения снимка до отображения на экране.

1. 01
   1. Получить снимок через metaAndAssetCtxs

   Запрос к POST /info без подписи, так как это публичная market metadata. В ответе — universe и параллельный массив contexts за один timestamp, основа для всех вычислений funding/OI/volume.

2. 02
   2. Сразу собрать пары (universe[i], contexts[i])

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

3. 03
   3. Учесть dex namespace для HIP-3 рынков

   Хранить пару (dex, symbol) или полный идентификатор с namespace вместо голого symbol, чтобы не смешивать метрики разных order books под одним ярлыком.

4. 04
   4. Открыть WebSocket-подписки поверх снимка

   Подписаться на нужные каналы (книга, trades, candles, user fills при необходимости) для инкрементальных обновлений между REST-опросами.

5. 05
   5. Обрабатывать reconnect, переподписку и freshness

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

6. 06
   6. Разделить источники для отображения и для решений

   Для витрины funding/OI/volume достаточно snapshot + WebSocket-обновлений. Для действий с ордерами или капиталом критичные решения должны опираться на подтверждение через info endpoint, а не только на последний WebSocket-снимок; для account queries — master или subaccount address.