Бэктест Hyperliquid: история, fills, funding и ограничения модели

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

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

Зачем бэктест на Hyperliquid отличается от обычного

Стандартный бэктест на историческом OHLCV работает по простой формуле: сигнал на закрытии свечи, вход по цене этого закрытия, комиссия фиксированным процентом, выход по правилам стратегии. Эта модель родом со спотового рынка с централизованной книгой и понятным клирингом, и на Hyperliquid она даёт систематическую ошибку сразу в двух направлениях.

Во-первых, исполнение определяется не последней ценой сделки, а доступным объёмом на уровнях книги в момент отправки ордера. HyperCore ведёт onchain книгу ордеров, и market-ордер исполняется против реальных встречных заявок: если объём крупный относительно глубины, ордер проходит несколько уровней подряд, и средняя цена fill отклоняется от той, что видна на графике. Во-вторых, ликвидация, TP и SL считаются по mark price, а не по цене последней сделки — а именно последнюю цену чаще всего берут исторические датасеты по умолчанию.

Из чего собрать данные для модели

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

Третий источник — сведения о фактической ликвидности на уровнях книги в исторический момент. Публичного архива снимков глубины книги как единого сервиса обычно нет, и это главное практическое ограничение: приходится либо оценивать глубину приблизительно через volume и spread на момент входа, либо собирать собственный архив снимков книги через WebSocket заранее, до начала тестируемого периода.

Почасовой funding — источник самой частой ошибки модели

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

Правильный подход — тянуть funding по часовым значениям и суммировать их за весь период удержания позиции, а не умножать восьмичасовую ставку на число периодов. Для стратегий вроде spot-perp hedge, где доход формируется именно из funding, эта разница в модели напрямую определяет, окажется ли бэктест прибыльным или убыточным на бумаге при том же реальном исходе.

Сценарий: бэктест breakout-стратегии на четырёхчасовом таймфрейме

Возьмём условный пример: вход по пробою локального сопротивления, подтверждённому ростом open interest, стоп по mark price с отступом на maintenance requirement текущего margin tier, выход по TP или по возврату цены под уровень. Условный уровень пробоя — 100 USD, условный размер позиции — 50 000 USD номинала. Упрощённая реализация возьмёт цену закрытия свечи пробоя как цену входа (те же условные 100 USD), применит комиссию по фиксированной ставке из документации по fee tier и посчитает стоп по цене той же свечи.

Более точная реализация учитывает, что реальный вход происходит IOC- или лимитным ордером с контролем проскальзывания, а не по цене закрытия. Если на уровнях 100.00–100.15 в книге условно стоит суммарно лишь 20 000 USD объёма, а оставшиеся 30 000 USD нужно добирать выше, средняя цена fill сдвинется, например, к условным 100.20–100.30 — разница в 20–30 базисных пунктов против сигнальной цены, которую бэктест на цене закрытия просто не учитывает. Аналогично стоп срабатывает по mark price, который в моменты волатильности может на короткое время отклоняться от цены на свечном графике, и переоценка этого расхождения в обе стороны искажает итоговый P&L модели.

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

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

1. 01
   Собрать исторические свечи и контекст рынка

   Получите OHLCV для нужного актива и параллельно контекст через metaAndAssetCtxs — mark price, oracle price, open interest, funding, volume. Проверьте, что сопоставление universe и contexts идёт по позиции в массиве, а не по тикеру, особенно если вы предварительно фильтруете список активов.

2. 02
   Заменить восьмичасовой funding на почасовой

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

3. 03
   Смоделировать проскальзывание от объёма, а не фиксированным процентом

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

4. 04
   Проверить ликвидацию и TP/SL по mark price, а не по цене сигнала

   Стоп должен срабатывать по смоделированному mark price с учётом maintenance requirement конкретного margin tier, а не по цене той же свечи, на которой сработал сигнал входа.

5. 05
   Прогнать стратегию на нескольких режимах рынка отдельно

   Разделите период теста на трендовые и range-участки, на спокойные и новостные окна. Единая агрегированная метрика по всему периоду скрывает то, что стратегия может системно проигрывать именно в моменты, когда глубина книги временно сокращается.

6. 06
   Сверить журнал модельных сделок с реальными полями

   В журнал модели заносите те же поля, что нужны для журнала реальных сделок: mark price и oracle price на момент решения, глубину книги на нужных уровнях, тип ордера и TIF, фактический funding по часам, margin tier и maintenance requirement, open interest и объём в моменте. Это позволяет позже сравнить бэктест с живой торговлей по одинаковым метрикам.

Единая точка данных Hyperliquid и её границы для бэктеста

Практическое удобство для построения модели в том, что историческая и текущая рыночная информация проходят через одну точку — POST /info, где метаданные рынков (universe, asset contexts, свечи) не требуют подписи и одинаковы для всех вызывающих. Это упрощает сбор архива для бэктеста: не нужно объединять данные с нескольких разрозненных источников с разной частотой обновления.

Оборотная сторона той же унификации — структура ответа зависит от типа запроса, и для account-специфичных данных (позиции, баланс, ордера) нужен конкретный master или subaccount address, а не agent wallet, который годится только для подписи ордеров. Для бэктеста это несущественно, поскольку истории по своему аккаунту вы не запрашиваете, но при переходе от бэктеста к живому исполнению эта разница в требованиях к адресу становится источником типичной путаницы в коде.

Что бэктест не может воспроизвести в принципе

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

Второе ограничение — TWAP-ордера, которые по документации отправляют suborders каждые 30 секунд с ограничением slippage, в бэктесте почти всегда упрощаются до единого мгновенного исполнения, что скрывает риск отставания от целевого объёма при недостаточной ликвидности. Третье — комиссии зависят от rolling 14-дневного взвешенного объёма, роли maker/taker, staking tier и других переменных; фиксированная ставка в модели даёт лишь приближение к реальному fee tier на момент теста.

Типичные ошибки при построении бэктеста

Ошибки, которые чаще всего искажают результат бэктеста в сторону завышенной прибыли.

• Использовать цену закрытия свечи как цену входа и выхода без поправки на проскальзывание — на тонких активах это переоценивает результат сильнее всего.
• Считать funding по восьмичасовой агрегированной ставке вместо почасовых значений при удержании позиции несколько дней.
• Ставить стоп по последней цене сделки вместо mark price, из-за чего модель либо срабатывает раньше реального стопа, либо пропускает реальную ликвидацию.
• Игнорировать зависимость проскальзывания от размера ордера и подставлять фиксированный процент комиссии на все объёмы одинаково.
• Тестировать стратегию только на одном непрерывном периоде без разделения на спокойные и новостные окна, где глубина книги ведёт себя по-разному.
• Смешивать метаданные рынка (universe, contexts) без проверки, что сопоставление идёт по позиции в массиве, а не по тикеру, после промежуточной фильтрации.