Самое большое узкое место вашего торгового бота — это уровень API

Вы тратите недели на настройку движка сигналов. Дивергенция когорт, скоринг риска ликвидации, экстремальные значения ставок финансирования. Бэктест выглядит отлично. Вы разворачиваете бота, и в течение 48 часов он пропускает три сделки: цикл опроса данных упёрся в ограничение частоты запросов и молча возвращал устаревшие данные на протяжении двадцати минут. Сигнал был правильным. Архитектура вокруг него — нет.

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

Это руководство посвящено правильному проектированию этого уровня с самого начала — конкретно для ботов, использующих аналитический API HyperTracker на Hyperliquid.

Почему уровень данных важнее самого сигнала

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

Уровень данных находится между вашим ботом и каждым фрагментом рыночной информации, на которую он опирается. На Hyperliquid наши данные обновляются с определёнными интервалами: снимки состояния каждые 15-20 минут и снимки потока ордеров в 5-минутных окнах. Это означает, что ваш интервал опроса, логика кэширования и обработка ошибок должны быть спроектированы с учётом этих конкретных ритмов обновления. Опрос чаще, чем обновляются данные, расходует квоту запросов впустую. Опрос реже означает пропуск окон сигналов.

Согласование интервала опроса с обновлением данных

Самое расточительное, что может делать бот, — опрашивать эндпоинт чаще, чем обновляются базовые данные. Если метрики когорт обновляются каждые 15-20 минут, а бот опрашивает каждые 60 секунд, пятнадцать из шестнадцати вызовов вернут идентичные данные. Вы сжигаете квоту, добавляете задержку в цикл событий и ничего не получаете взамен.

Расписание обновлений, на которое следует ориентироваться

У API HyperTracker разные интервалы обновления в зависимости от категории эндпоинта:

| Категория эндпоинта | Интервал обновления | Рекомендуемый интервал опроса | | --- | --- | --- | | Метрики когорт (/cohort-metrics) | ~15-20 мин | Каждые 5 мин (своевременно захватывает обновления) | | Снимки потока ордеров (/orders) | Скользящие 5-мин окна | Каждые 5 мин (синхронизировано с окном) | | Риск ликвидации (/liq-risk) | ~15-20 мин | Каждые 5 мин | | Метрики позиций (/position-metrics) | ~15-20 мин | Каждые 5 мин | | Таблицы лидеров (/leaderboard) | ~15-20 мин | Каждые 15-30 мин (менее чувствительны ко времени) |

Рекомендуемый интервал опроса в 5 минут для большинства эндпоинтов — это компромисс. Вы хотите захватить свежие данные сразу после обновления, но не знаете точной секунды обновления внутри 15-20-минутного окна. Опрос каждые 5 минут означает, что вы получите новый снимок в течение 5 минут после его появления — этого достаточно для стратегий с временным горизонтом от 1 часа и более.

Проектирование бюджета запросов

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

| Тариф | Запросов в месяц | Ограничение частоты | Эффективный бюджет в день | | --- | --- | --- | --- | | Pulse ($179/mo) | 50 000 | 60/мин | ~1 667 запросов | | Surge ($399/mo) | 150 000 | 100/мин | ~5 000 запросов | | Flow ($799/mo) | 400 000 | 200/мин | ~13 333 запросов | | Stream ($1,999/mo) | 2 000 000 | 500/мин | ~66 667 запросов |

Бот на тарифе Pulse, опрашивающий 4 эндпоинта каждые 5 минут, использует 4 x 288 = 1 152 запроса в день. Это оставляет 515 запросов для разовых обращений, дозаполнения данных или второго цикла опроса для дополнительных активов. Пространство для манёвра есть, но становится тесно при добавлении эндпоинтов или активов без предварительного планирования.

На тарифе Surge тот же цикл из 4 эндпоинтов с 5-минутным интервалом использует те же 1 152 запроса, но дневной бюджет составляет ~5 000 — так что можно мониторить несколько активов или добавить второй, более частый цикл для потока ордеров по основному активу. Суть в следующем: смоделируйте бюджет до написания кода опроса, потому что добавить осведомлённость о лимитах запросов в бота, который изначально строился без неё, — это болезненно.

Паттерн таблицы бюджета запросов

Прежде чем писать код опроса, набросайте такую таблицу:

Эндпоинт           | Активы | Интервал | Вызовов/день
-------------------+--------+----------+-------------
/cohort-metrics    |   3    |  5 мин   |    864
/orders            |   1    |  5 мин   |    288
/liq-risk          |   3    |  5 мин   |    864
/position-metrics  |   1    | 15 мин   |     96
-------------------+--------+----------+-------------
Итого              |        |          |  2 112
Бюджет (Pulse)     |        |          |  1 667   <- ПРЕВЫШЕН

Решение: перевести /liq-risk на 15-мин интервал:
/liq-risk          |   3    | 15 мин   |    288
Новый итог         |        |          |  1 536   <- ОК

Это простая арифметическая задача, но большинство разработчиков пропускают её и обнаруживают превышение бюджета только когда бот начинает возвращать ошибки 429 в продакшене. Сначала моделируйте, потом стройте.

Кэширование: слой, который большинство ботов игнорирует

Ваш бот должен поддерживать локальное хранилище данных (даже простой словарь в памяти), содержащее последний ответ от каждого опрашиваемого эндпоинта. Это служит трём целям.

Первая — дедупликация. Если вы опрашиваете /cohort-metrics каждые 5 минут, а данные обновляются каждые 15-20 минут, три из четырёх запросов вернут идентичные данные. Кэш должен сравнивать входящий ответ с сохранённой версией и передавать данные движку сигналов только при реальном изменении. Это предотвращает повторную оценку сигналов на устаревших данных и генерацию избыточного шума в логах.

Вторая — обнаружение устаревания. Прикрепляйте временную метку к каждой записи кэша. Если кэш для данного эндпоинта не обновлялся дольше, чем вдвое превышает ожидаемый интервал обновления (например, 40 минут для 20-минутного цикла), что-то пошло не так. Либо API недоступен, либо нестабильна сеть, либо цикл событий бота завис. Оповещение об устаревании запускает расследование до того, как бот начнёт торговать на данных часовой давности.

Третья — изящная деградация. Если опрос завершился неудачей (ошибка сети, код 500, лимит запросов), кэш всё ещё содержит предыдущий корректный ответ. Бот может продолжать работу на этих данных, явно осознавая, что работает на устаревшей информации. Это осознание важно: бот, торгующий на заведомо устаревших данных, может уменьшить размер позиций или расширить стопы. Бот, не знающий об устаревании данных, не может адаптироваться.

class DataCache:
    def __init__(self, stale_threshold_seconds=2400):
        self.store = {}
        self.stale_threshold = stale_threshold_seconds

    def update(self, endpoint, data):
        prev = self.store.get(endpoint)
        changed = prev is None or prev["data"] != data
        self.store[endpoint] = {
            "data": data,
            "fetched_at": time.time(),
            "changed": changed,
        }
        return changed

    def get(self, endpoint):
        entry = self.store.get(endpoint)
        if entry is None:
            return None, True  # no data, considered stale
        age = time.time() - entry["fetched_at"]
        return entry["data"], age > self.stale_threshold

    def is_stale(self, endpoint):
        _, stale = self.get(endpoint)
        return stale

Обработка ошибок и экспоненциальный откат

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

Три сценария отказа

Лимит запросов (HTTP 429). API сигнализирует о необходимости снизить темп. Правильная реакция — экспоненциальный откат: ждать 1 секунду, затем 2, затем 4, затем 8, с потолком в 60 секунд. Не повторяйте запрос немедленно. Не повторяйте с фиксированным интервалом в 1 секунду. Каждый немедленный повтор при уже достигнутом лимите только усугубляет ситуацию.

Ошибка сервера (HTTP 5xx). Что-то пошло не так на стороне API. Повторяйте с откатом, до 3 попыток. Если все 3 завершились неудачей, запишите ошибку в лог, пометьте запись кэша как потенциально устаревшую и продолжайте работу. Не блокируйте весь цикл событий в ожидании восстановления.

Ошибка клиента (HTTP 4xx, кроме 429). Ваш запрос некорректен. Повторные попытки не помогут. Запишите ошибку с полным телом запроса для отладки и пропустите этот цикл опроса.

async def poll_with_backoff(endpoint, params, max_retries=3):
    for attempt in range(max_retries):
        try:
            response = await fetch(endpoint, params)
            if response.status == 200:
                return response.json()
            elif response.status == 429:
                wait = min(2 ** attempt, 60)
                logger.warning(f"Rate limited on {endpoint}, waiting {wait}s")
                await asyncio.sleep(wait)
            elif response.status >= 500:
                wait = min(2 ** attempt, 30)
                logger.warning(f"Server error {response.status} on {endpoint}")
                await asyncio.sleep(wait)
            else:
                logger.error(f"Client error {response.status} on {endpoint}")
                return None
        except NetworkError as e:
            logger.error(f"Network error on {endpoint}: {e}")
            await asyncio.sleep(min(2 ** attempt, 30))
    logger.error(f"All retries exhausted for {endpoint}")
    return None

Выбор эндпоинтов: запрашивайте только то, что нужно

HyperTracker предоставляет 21 эндпоинт. Вашему боту, вероятно, нужно 3-5 из них. Один из главных источников расточительства бюджета — опрос эндпоинтов "на всякий случай", когда движок сигналов фактически не использует эти данные.

Отталкивайтесь от сигнала, а не от API. Спросите себя: какие данные нужны моей сигнальной функции на входе? Если она использует позиционирование когорт, опрашивайте /cohort-metrics. Если использует риск ликвидации, опрашивайте /liq-risk. Если не использует данные таблиц лидеров, не опрашивайте /leaderboard. Каждый добавленный в цикл опроса эндпоинт стоит вам дневного бюджета запросов и добавляет потенциальную точку отказа.

Типичные соответствия сигналов и эндпоинтов

| Тип сигнала | Обязательный эндпоинт(-ы) | Опциональное обогащение | | --- | --- | --- | | Дивергенция когорт | /cohort-metrics | /position-metrics (контекст OI) | | Угасание риска ликвидации | /liq-risk | /cohort-metrics (подтверждение направления) | | Дисбаланс потока ордеров | /orders | /cohort-metrics (кто движет потоком) | | Экстремум ставки финансирования | Нативный API Hyperliquid | /cohort-metrics (позиция Smart Money) | | Копирование сделок / следование за кошельками | /positions | /leaderboard (отбор целевых кошельков) |

Обратите внимание, что /cohort-metrics присутствует почти в каждом типе сигнала — либо как основной, либо как обогащающий источник. Если вы строите систему вокруг когортной аналитики, это ваш главный рабочий эндпоинт. Наши данные классифицируют каждый кошелёк Hyperliquid в одну из 16 поведенческих когорт (8 по размеру счёта, 8 по совокупному PnL за всё время), и именно на уровне агрегатов когорт сосредоточена плотность сигналов.

Структурирование цикла опроса

Цикл опроса — это сердцебиение вашего бота. Сделаете правильно — система будет работать бесперебойно неделями. Допустите ошибку — будете отлаживать гонки состояний и пропущенные опросы в три часа ночи.

Паттерн смещённых интервалов

Не запускайте все запросы к эндпоинтам в одну секунду. Если вы опрашиваете 4 эндпоинта с 5-минутным интервалом, распределите их по этому интервалу. Опрашивайте /cohort-metrics в момент t+0, /orders в t+75s, /liq-risk в t+150s, /position-metrics в t+225s. Это сглаживает интенсивность запросов и предотвращает всплески, которые могут спровоцировать срабатывание поминутного лимита.

POLL_SCHEDULE = [
    {"endpoint": "/cohort-metrics", "offset_sec": 0,   "interval_sec": 300},
    {"endpoint": "/orders",         "offset_sec": 75,  "interval_sec": 300},
    {"endpoint": "/liq-risk",       "offset_sec": 150, "interval_sec": 300},
    {"endpoint": "/position-metrics","offset_sec": 225, "interval_sec": 900},
]

async def run_polling_loop(cache, signal_engine):
    while True:
        now = time.time()
        for task in POLL_SCHEDULE:
            elapsed = (now - start_time) % task["interval_sec"]
            if abs(elapsed - task["offset_sec"]) < 2:
                data = await poll_with_backoff(task["endpoint"], params)
                if data and cache.update(task["endpoint"], data):
                    signal_engine.evaluate(cache)
        await asyncio.sleep(1)

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

Альтернативы: вебхуки и WebSocket

На тарифах Flow ($799/mo) и Stream ($1,999/mo) HyperTracker поддерживает вебхуки и WebSocket-соединения. Они полностью меняют модель опроса: вместо того чтобы бот запрашивал данные по таймеру, API сам отправляет данные боту при их изменении.

Вебхуки полностью устраняют цикл опроса для покрываемых ими эндпоинтов. Вы регистрируете URL обратного вызова, и при обновлении метрик когорт бот получает POST с новыми данными. Никакого опроса, никаких лишних запросов, никаких окон устаревания.

WebSocket-соединения (тариф Stream) обеспечивают постоянный канал для непрерывных обновлений. Если вы строите высокочастотную систему, которой нужно реагировать в течение секунд после обновления данных, WebSocket устраняет задержку периодического опроса полностью.

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

Собираем всё вместе: эталонная архитектура

Вот полный стек хорошо спроектированного торгового бота на Hyperliquid, от API до исполнения:

+----------------------------------------------------------+
|                  УПРАВЛЕНИЕ РИСКАМИ                       |
|  (блокирует сигналы, контролирует лимиты позиций,        |
|   может остановить бота)                                  |
+----------------------------------------------------------+
        |                                    ^
        v                                    |
+------------------+   +------------------+  |
|  ДВИЖОК СИГНАЛОВ |-->|    ИСПОЛНЕНИЕ    |--+
|  (чистая функция)|   |  (Python SDK     |
|                  |   |   Hyperliquid)   |
+------------------+   +------------------+
        ^
        |  (только при изменении кэша)
+----------------------------------------------------------+
|                      КЭШ ДАННЫХ                           |
|  - дедупликация (пропуск неизменившихся ответов)          |
|  - обнаружение устаревания (оповещение при возрасте       |
|    данных > 2x интервала обновления)                      |
|  - изящная деградация (последние корректные данные        |
|    при ошибке)                                            |
+----------------------------------------------------------+
        ^
        |  (смещённый опрос с откатом)
+----------------------------------------------------------+
|                   УРОВЕНЬ ОПРОСА API                      |
|  - смещённые интервалы для каждого эндпоинта             |
|  - экспоненциальный откат при 429/5xx                     |
|  - отслеживание бюджета запросов (дневной + поминутный)   |
|  - выбор эндпоинтов на основе требований сигнала         |
+----------------------------------------------------------+
        |
        v
   HyperTracker API
   (REST / Webhooks / WebSocket)

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

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

Стройте бота на основе предварительно вычисленной аналитики

API HyperTracker предоставляет когортную аналитику, скоринг риска ликвидации, снимки потока ордеров и метрики позиций по всему Hyperliquid. 16 поведенческих когорт, каждый кошелёк классифицирован, доставка через REST, вебхуки или WebSocket. Начните с бесплатного тарифа и масштабируйтесь по мере развития бота.

Изучить API

Типичные ошибки (и как их избежать)

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

Игнорирование ежемесячного лимита до последнего момента. Бот, который нормально работает три недели, а потом исчерпывает месячную квоту на четвёртой неделе, хуже, чем бот, работающий чуть медленнее весь месяц. Отслеживайте накопленные запросы ежедневно и настройте оповещение при превышении порога (например, когда использовано больше пропорциональной доли месячного бюджета на текущий день месяца).

Молчаливое поглощение ошибок. Худший вариант: блок try/except, перехватывающий все исключения и возвращающий None, который затем передаётся движку сигналов как "нет данных". Движок сигналов интерпретирует "нет данных" иначе, чем "данные говорят, что ничего интересного не происходит". Различайте "API вернул пустые результаты" (корректно) и "вызов API завершился ошибкой" (ошибка). Это разные состояния.

Получение исторических данных в горячем цикле. HyperTracker хранит исторические данные за несколько месяцев по позициям и сделкам. Эти данные предназначены для бэктестинга и исследований: их нужно получить однократно, сохранить локально и никогда не запрашивать повторно в живом цикле опроса. Исторические эндпоинты имеют те же лимиты частоты, что и эндпоинты реального времени, поэтому многократные обращения к ним съедают бюджет без какой-либо пользы.

Построение сигнала первым, а уровня данных — последним. Сигнал — это интересная часть. Скоринг дивергенции когорт, составные сигналы, настройка порогов. Но если вы строите сигнал, не зная, сколько вызовов API вы можете себе позволить, как часто обновляются данные и как распространяются ошибки, вам придётся адаптировать уровень данных под ограничения, которые должны были быть заложены с самого начала. Сначала стройте трубопровод. Тестируйте его в режиме только логирования (без торговли) несколько дней. Затем подключайте сигнал.

Вывод

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

Смоделируйте бюджет запросов до написания кода. Кэшируйте агрессивно. Обрабатывайте ошибки явно. Опрашивайте с тем интервалом, с которым реально обновляются данные, и распределяйте запросы, чтобы никогда не создавать всплесков. Сделайте эти пять вещей — и уровень API станет невидимым. Именно так и должна работать хорошая инфраструктура.