Торговый журнал: какие данные Hyperliquid сохранять

При каких условиях применять сценарий

Материал для трейдера, который уже открывает позиции на Hyperliquid через perpetual или spot, знаком с funding, margin tiers и типами ордеров, но ведёт журнал по шаблону из спотовой торговли на CEX и не понимает, почему после серии сделок сложно объяснить, что именно сработало.

Почему обычный журнал сделок не объясняет результат на Hyperliquid

Стандартный шаблон — дата, актив, направление, цена входа, цена выхода, PnL — работает на спотовом рынке с централизованной книгой и понятным клирингом. На Hyperliquid этого недостаточно: исполнение зависит от глубины книги на конкретных уровнях, а не от последней цены сделки, а ликвидация и TP/SL считаются по mark price, который может заметно расходиться с ценой последней сделки в моменты волатильности.

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

Минимальный набор полей: что фиксировать при каждой сделке

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

• Mark price и oracle price на момент входа и выхода — база для расчёта ликвидации и срабатывания TP/SL
• Тип ордера и TIF-флаг (market, limit, IOC, ALO) — определяет, был ли fill maker или taker и почему цена исполнения отличалась от видимой перед отправкой
• Доступная глубина книги на 2–3 уровня выше и ниже цены входа — объясняет реальное проскальзывание на крупном размере
• Margin tier, режим маржи (cross/isolated) и maintenance requirement на момент открытия — без этого нельзя пересчитать буфер до ликвидации постфактум
• Funding за каждый час удержания позиции, а не восьмичасовой эквивалент из интерфейса
• Open interest и объём в момент входа — показывают, был приток нового капитала или перестановка существующих позиций
• Fee tier и роль fill (maker/taker), подтверждённый статус ордера через повторный запрос к info endpoint

Funding: почему запись одной ставки на входе искажает журнал

Funding на Hyperliquid — peer-to-peer платёж между long и short, пересчитываемый каждый час. Восьмичасовая ставка в интерфейсе — усреднённая для восприятия величина, а не реальная периодичность списания. Если в журнал попадает только ставка на момент открытия, итоговый расчёт прибыльности позиции, удержанной несколько дней, окажется неверным: ставка меняется ежечасно, и итог зависит от всей истории удержания.

Отдельная ошибка — считать позицию с положительным funding «арбитражем» просто потому, что funding капает в вашу сторону. Без хеджирующей ноги это направленная позиция с полным риском цены; арбитражем связка становится только тогда, когда funding-нога закрыта противоположной позицией — например spot против perpetual. Журнал должен явно фиксировать, был ли хедж, иначе направленный риск задним числом выглядит как нейтральная стратегия.

Контекст исполнения: OI, объём и глубина книги в момент входа

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

Без записи OI и объёма на момент входа два визуально одинаковых пробоя уровня выглядят в журнале идентично, хотя один подтверждён притоком капитала, а второй — простой перестановкой позиций на тонкой книге. Это объясняет, почему одна и та же стратегия breakout срабатывает в одном случае и проваливается в другом при внешне похожей свече.

Условный пример: как расширенные поля меняют вывод по сделке

Числа условные. Трейдер открывает лонг на breakout размером 10 000 USD по цене входа 100, книга на трёх уровнях выше показывает достаточный объём, OI за час до входа рос вместе с ценой — сценарий подтверждён притоком капитала. Позиция закрыта через 30 часов по цене 103. Стандартный журнал зафиксирует только валовый PnL: рост на 3% при позиции 10 000 USD даёт валовую прибыль 300, без поправок на исполнение и удержание.

Расширенный журнал добавляет арифметику. Вход исполнен IOC-ордером: средняя цена fill 100,08 против видимых 100,00 на мид-цене — проскальзывание около 8 на позицию 10 000, в пределах ожиданий по зафиксированной глубине книги. Funding за 30 часов колебался в диапазоне 0,001–0,004% в час против позиции; при среднем 0,0025% в час накопленная сумма — около 7,5, списанных со счёта лонга. С учётом slippage и funding чистый результат — около 300 − 8 − 7,5 ≈ 284,5 против валовых 300. Разница некритична для знака сделки, но показывает: рост цены сопровождался ростом OI, глубина была достаточной, funding не был скрытым риском, а издержки исполнения остались в пределах ожидаемых — на более крупном размере они не съели бы прибыль.

Типичные ошибки при ведении журнала на Hyperliquid

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

Четвёртая — оценивать вход по mid price вместо доступной глубины на нужных уровнях, из-за чего проскальзывание на крупном размере в журнале не объясняется ничем и выглядит случайным шумом. Пятая — не различать fee tier по роли fill: одна и та же валовая прибыль на maker- и taker-исполнении даёт разный чистый результат, если tier и роль не зафиксированы.

Как настроить сбор данных: пошаговый план

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

1. 01
   Снять контекст рынка перед входом

   Запросить рыночные метаданные и контексты по активу (metaAndAssetCtxs) и записать mark price, oracle price, open interest, funding и объём на момент решения — единый снимок для последующей сверки сценария.

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

   Запросить книгу ордеров и зафиксировать доступный объём на 2–3 уровнях выше и ниже цены входа перед отправкой ордера, а не оценивать проскальзывание постфактум по mid price.

3. 03
   Зафиксировать тип ордера и TIF-флаг

   Записать конкретный флаг отправленного ордера — market, limit, IOC или ALO — и полученную роль fill, maker или taker, сразу после подтверждения исполнения.

4. 04
   Записать margin tier, режим маржи и maintenance requirement

   Сохранить действующий на момент открытия margin tier, режим маржи (cross или isolated) и maintenance requirement по активу, чтобы позже пересчитать фактический буфер до ликвидации.

5. 05
   Считать funding по часам, а не по ставке на входе

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

6. 06
   Подтверждать статус ордера повторным запросом

   После снимка из ленты обновлений отдельно запросить статус ордера через info endpoint и записать в журнал именно подтверждённый результат.

7. 07
   Использовать master или subaccount address для чтения данных аккаунта

   Для записи позиций и баланса отправлять account-запросы с адресом master или subaccount; ключ, который только подписывает ордера, для этой задачи не подходит.

Как перечитывать старые записи журнала

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

Группировать записи имеет смысл не по дате, а по совпадению условий исполнения: тип ордера, направление изменения OI, глубина книги на входе. Такая группировка показывает, при каком сочетании контекста сценарий стабильно подтверждается, а при каком заканчивается убытком несмотря на формально правильный сигнал по цене. Без зафиксированных полей mark price, OI и глубины книги такая группировка невозможна — журнал просто не содержит данных, по которым её можно построить.

Ограничения подхода

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

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