Бюджет задержки на Hyperliquid: от REST-опросов до чтений за доли секунды

Существует класс торговых стратегий на Hyperliquid, где разница между прибыльностью и убыточностью измеряется сотнями миллисекунд. Арбитраж ставок финансирования между Hyperliquid и централизованными площадками для бессрочных контрактов. Затухание каскадов ликвидаций, требующее входа до срабатывания второй волны. Сигналы смены когорт, где нужно занять позицию в ту же минуту, когда когорта Money Printer переворачивается в чистый лонг.

Для этих стратегий архитектура чтения данных важнее самой стратегии. Идеально рассчитанный вход по сигналу смены когорты с опозданием на три секунды — худшая сделка, чем умеренный вход, выполненный вовремя. Задержка — не приятное дополнение, а жёсткое ограничение, определяющее, какие стратегии вы можете запускать.

Эта статья разбирает бюджетирование задержки для стратегий на базе Hyperliquid: сколько времени фактически стоит каждый источник данных, где REST-опросы терпят неудачу и как WebSocket-подписки и событийные архитектуры сдвигают границы того, что возможно реализовать.

Стек задержки

Типичный торговый конвейер на Hyperliquid имеет четыре уровня задержки, каждый добавляет миллисекунды (или секунды) между моментом, когда что-то происходит на блокчейне, и моментом реакции вашей системы:

1. Блокчейн → индексатор. Время от исполнения сделки на L1 Hyperliquid до появления этой сделки в индексе вашего провайдера данных. Обычно 200-800 мс для HyperTracker.
2. Индексатор → ваш код. Время от получения данных индексатором до их появления в вашем коде. REST-опрос: зависит от интервала опроса (обычно 1-30 с). WebSocket: 5-50 мс.
3. Ваш код → решение. Время обработки сигнала и принятия решения о действии. Зависит от сложности вашего кода. Должно быть менее 100 мс для любой чувствительной к задержке стратегии.
4. Решение → исполнение. Время от отправки ордера вашим кодом до размещения этого ордера в стакане Hyperliquid. Обычно 80-300 мс, в зависимости от сетевого расстояния до L1 Hyperliquid.

Общий бюджет задержки для быстрой стратегии: ~500 мс-1 с по пути WebSocket, 2-30 с по пути REST-опросов.

Где REST-опросы терпят неудачу

REST-опросы — стандарт для большинства аналитических интеграций, потому что это просто: вы делаете HTTP-запросы по расписанию и обрабатываете полученное. Это отлично работает для стратегий, где окно от сигнала до действия измеряется минутами (большинство розничного копи-трейдинга), но полностью ломается для всего, что чувствительно ко времени.

Точки отказа:

Расчёт финансирования. Финансирование на Hyperliquid рассчитывается каждый час по ставке 1/8. Если ваша стратегия зарабатывает на финансировании, находясь на правильной стороне экстремального значения непосредственно перед расчётом, у вас есть окно в несколько секунд для позиционирования. REST-опрос с интервалом в 5 секунд уже заставляет вас пропускать 50% окон.

Каскады ликвидаций. Когда на Hyperliquid срабатывает крупная ликвидация, вторичные ликвидации (позиции, цены ликвидации которых были в пределах диапазона ценового воздействия) срабатывают в течение сотен миллисекунд. Стратегиям, желающим затухнуть каскад, нужна задержка уровня WebSocket, чтобы занять позицию до отскока.

Смены когорт на новостных катализаторах. События реального времени (отчёты о прибылях, регуляторные объявления, одобрения ETF) запускают сдвиги позиционирования когорт, которые усиливаются в течение следующих 10-60 минут. Поймать первую волну требует присутствия в потоке данных в реальном времени, а не опросов.

Общее правило: если преимущество вашей стратегии снижается более чем на 50% при задержке исполнения на 5 секунд, REST-опросы для неё не подходят.

Что реально дают WebSocket-подписки

API HyperTracker предоставляет WebSocket-подписки на все данные в реальном времени: позиции, сделки, позиционирование когорт, ставки финансирования, ликвидации. Архитектурная разница в сравнении с REST:

REST (опросы): каждые N секунд ваш код спрашивает сервер "каково текущее состояние?" Сервер возвращает снимок. Вы сравниваете с предыдущим снимком, чтобы найти изменения. Нижняя граница задержки = интервал опроса.

WebSocket (push): ваш код поддерживает постоянное соединение. Сервер отправляет каждое изменение по мере его возникновения. Нижняя граница задержки = время сетевого обмена, обычно 20-100 мс в зависимости от вашего местоположения.

Для высокочастотного мониторинга когорт разница значительна. REST-опрос каждые 5 секунд к эндпоинту позиционирования когорт обходится вам в устаревание данных до 5 секунд. WebSocket-аналог обходится вам в ~50 мс.

С точки зрения кода переход добавляет сложность, но не очень большую:

import websockets, json

async def subscribe_cohort_changes(asset="BTC"):
    async with websockets.connect("wss://api.hypertracker.cmm.app/ws") as ws:
        await ws.send(json.dumps({
            "subscribe": "cohort_positioning",
            "asset": asset,
            "cohorts": ["money_printer", "smart_money"]
        }))
        async for message in ws:
            event = json.loads(message)
            # event = {"cohort": "money_printer", "asset": "BTC",
            #         "long_ratio": 0.62, "delta_24h": +0.08, ...}
            handle_cohort_update(event)

Это вся подписка. Обновления поступают по мере их возникновения.

Бюджеты задержки по типам стратегий

Разные стратегии переносят разную задержку. Приблизительная классификация:

| Стратегия | Допустимая задержка | Требуемая архитектура | |---|---|---| | Копи-трейдинг (удержание несколько дней) | 10-60 с | REST-опрос 30 с | | Сигналы по смещению когорт (решения 4ч-1 день) | 1-5 с | REST-опрос 1 с ИЛИ WebSocket | | Арбитраж финансирования | 200-500 мс | Требуется WebSocket | | Затухание каскадов ликвидаций | <200 мс | WebSocket + колокационное исполнение | | Смены когорт, вызванные новостями | <2 с | Требуется WebSocket |

Ошибка, которую допускает большинство разработчиков, — избыточная инженерия. Если вы создаёте панель копи-трейдинга, которая открывает позиции на удержание в течение 12 часов, WebSocket — ненужные инфраструктурные издержки. REST-опросы с интервалом 30 секунд вполне адекватны. Сохраните бюджет сложности для стратегий, где это действительно важно.

Архитектура: событийная против опросной

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

Событийные системы сложнее писать правильно, потому что:

• Управление состоянием параллельное (несколько событий могут прийти, пока вы обрабатываете одно)
• Гонки между обновлениями данных и вашими действиями становятся возможными
• Отладка сложнее, когда события срабатывают в непредсказуемом порядке

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

Чистый событийный паттерн для мониторинга когорт на Hyperliquid:

class CohortMonitor:
    def __init__(self):
        self.state = {}  # текущее позиционирование когорт по активам
        self.position_book = {}  # ваши открытые позиции

    async def on_cohort_event(self, event):
        asset = event["asset"]
        cohort = event["cohort"]

        # Обновить состояние
        self.state[(asset, cohort)] = event["long_ratio"]

        # Проверить триггер
        if cohort == "money_printer":
            await self.check_money_printer_flip(asset, event)

    async def check_money_printer_flip(self, asset, event):
        # Была ли Money Printer в чистом шорте, а теперь в чистом лонге? Это сигнал.
        prev = self.state.get((asset, "money_printer_prev"), 0.5)
        if prev < 0.5 and event["long_ratio"] >= 0.55:
            await self.open_position(asset, side="long", size=...)

Триггер срабатывает в момент доставки события WebSocket. Никакой задержки опроса, никаких пропущенных окон.

Соображения о затратах

WebSocket-подписки стоят дороже REST-опросов на большинстве тарифов API. Тариф Pulse от HyperTracker ($179/мес) включает доступ к WebSocket. Математика: если вы используете стратегию, которой нужна задержка менее секунды, и вы опрашиваете REST вместо этого, вы теряете сделки стоимостью более $179/мес. Посчитайте.

Бесплатный тариф и низший платный тариф — только REST. Это нормально для всего, кроме чувствительных к задержке стратегий, описанных выше.

Более широкий взгляд

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

Хорошие новости: разрыв между REST-опросами и WebSocket не так велик в плане усилий разработки, а изменения в бюджете задержки открывают целые категории стратегий. Для разработчиков, работающих над нативными стратегиями Hyperliquid, инвестиции в WebSocket обычно являются инфраструктурным решением с наивысшей рентабельностью.

Получить доступ к WebSocket для данных по когортам + позициям →

Задержка — невидимый потолок качества стратегии. Измеряйте её, проектируйте с её учётом и платите за тариф, который удерживает вас ниже неё.