Latency Budgeting on Hyperliquid: From REST Polls to Sub-Second Reads

By @CoinMarketMan - 08-Jun-2026

Бюджетування затримок на Hyperliquid: від REST-опитування до зчитування за частку секунди

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

Для цих стратегій архітектура зчитування даних має більше значення, ніж сама стратегія. Ідеально розрахований вхід за сигналом розвороту когорти, що спрацював із затримкою три секунди — це гірша угода, ніж помірний вхід, що спрацював вчасно. Затримка — це не приємний бонус, а жорстке обмеження, що визначає, які стратегії ви можете реалізувати.

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

Стек затримок

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

Он-чейн → індексатор. Час від виконання угоди на L1 Hyperliquid до появи цієї угоди в індексі вашого провайдера даних. Зазвичай 200-800мс для HyperTracker.
Індексатор → ваш код. Час від наявності даних в індексаторі до отримання їх вашим кодом. REST-опитування: залежить від інтервалу опитування (типово 1-30с). WebSocket: 5-50мс.
Ваш код → рішення. Час на обробку сигналу та прийняття рішення про дію. Залежить від складності вашого коду. Має бути менше 100мс для будь-якої чутливої до затримок стратегії.
Рішення → виконання. Час від відправлення ордера вашим кодом до розміщення цього ордера в книзі 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 →

Затримка — це невидима межа якості стратегії. Виміряйте її, проєктуйте з її врахуванням і платіть за рівень, що дає вам потрапити під неї.