Как собрать маркет-мейкер-бота на Hyperliquid
-
hyperliquid market maker
-
hl market maker tutorial
-
маркет-мейкер-бот для Hyperliquid
-
ончейн-маркет-мейкинг на бессрочниках
-
маркет-мейкинг через Hyperliquid API
Маркет-мейкинг — одна из самых старых торговых стратегий на финансовых рынках. Маркет-мейкер одновременно выставляет заявки на покупку и продажу, зарабатывая на спреде между bid и ask и добавляя рынку ликвидность. С ростом ончейн-бирж бессрочных контрактов вроде Hyperliquid даже независимые разработчики и небольшие квант-команды могут участвовать в маркет-мейкинге через открытый API, без институциональной инфраструктуры.
Ниже разберём, как подойти к созданию маркет-мейкер-бота для Hyperliquid: логику стратегии, техническую архитектуру, риск-менеджмент и хранение ключей подписи через аппаратный кошелёк OneKey.
Что такое маркет-мейкинг на бессрочных контрактах
На спотовом рынке маркет-мейкер держит реальный инвентарь актива. На рынке бессрочников «инвентарь» выражается как чистая длинная или короткая позиция. В идеале маркет-мейкер стремится оставаться delta neutral: регулярно обновлять заявки по обе стороны стакана, забирать спред и не делать ставку на направление цены.
Архитектура стакана Hyperliquid похожа на централизованные биржи, но расчёты происходят ончейн, а средства остаются под самокастодиальным контролем пользователя. Перед разработкой бота обязательно изучи официальную документацию Hyperliquid: типы ордеров, комиссии, лимиты и API-спецификации.
Если ты пока не хочешь сразу писать своего бота, практичный первый шаг — поторговать через OneKey Perps. Так ты сможешь понять механику бессрочников, плечо, ликвидации, комиссии и поведение рынка, прежде чем автоматизировать стратегию.
Базовая логика маркет-мейкер-бота
Расчёт спреда
Самая простая симметричная схема — выставлять заявки по обе стороны от средней цены, или mid price:
buy_price = mid_price * (1 - spread / 2)
sell_price = mid_price * (1 + spread / 2)
Параметр spread должен покрывать как минимум:
- торговые комиссии;
- риск adverse selection, когда тебя исполняют перед неблагоприятным движением цены;
- возможные издержки, связанные с funding rate;
- волатильность конкретного рынка;
- задержки между получением данных, расчётом цены и отправкой ордера.
Комиссионные уровни и параметры рынков нужно сверять с официальной документацией Hyperliquid. Чем меньше капитал, выше волатильность и хуже исполнение, тем осторожнее стоит выбирать спред.
Обновление заявок
Цена постоянно двигается, поэтому старые заявки быстро становятся неактуальными. Боту нужен механизм регулярного refresh’а котировок.
Типовые триггеры:
- по времени — например, обновлять заявки каждые 5 секунд;
- по отклонению цены — если mid price ушёл от текущих заявок сильнее заданного порога;
- по исполнению — если одна из заявок исполнилась, сразу переставить обе стороны стакана;
- по изменению позиции — если инвентарь стал слишком перекошенным.
На практике обычно комбинируют несколько условий. Слишком частое обновление может упереться в лимиты API и создать лишние расходы, а слишком редкое — сделать котировки уязвимыми для арбитража.
Управление инвентарём
Главный риск маркет-мейкинга — накопление позиции. Например, если рынок постоянно исполняет твои buy-заявки, а sell-заявки не исполняются, бот постепенно набирает лонг. Если цена потом резко падает, спред уже не спасает.
Основные методы контроля:
- price skewing — если позиция в лонге, сдвигать bid и ask ниже, чтобы меньше покупать и активнее продавать; если позиция в шорте — наоборот;
- жёсткие лимиты позиции — если net position превысила порог, бот перестаёт выставлять заявки в сторону увеличения риска;
- уменьшение размера ордера — при росте риска снижать объём новых заявок;
- аварийная остановка — при резком движении рынка или превышении дневного убытка отключать стратегию.
Пример псевдокода для skewing:
# Псевдокод: сдвиг цены на основе чистой позиции
position = get_net_position("BTC") # положительное значение = лонг, отрицательное = шорт
skew_factor = -position * inventory_risk_param # настраиваемый параметр риска
bid_price = mid_price * (1 - spread / 2) + skew_factor
ask_price = mid_price * (1 + spread / 2) + skew_factor
Важно: skewing не гарантирует возврат позиции к нейтрали. В трендовом рынке бот может продолжать получать исполнения только с одной стороны.
Архитектура системы
Полноценный маркет-мейкер-бот обычно состоит из трёх слоёв: данных, стратегии и исполнения.
┌─────────────────────────────────────────────────────┐
│ Главный цикл маркет-мейкер-бота │
├──────────────┬──────────────┬────────────────────────┤
│ Слой данных │ Слой стратегии │ Слой исполнения │
│ │ │ │
│ WebSocket │ Расчёт mid │ REST API ордера │
│ Стакан │ Расчёт спреда │ Массовая отмена/подача │
│ Fill-события │ Skew позиции │ Подпись через OneKey │
│ │ Риск-лимиты │ │
└──────────────┴──────────────┴────────────────────────┘
│ │
Рыночные данные Отправка ордеров в Hyperliquid
Слой данных
Слой данных подписывается через WebSocket на:
- снимки и обновления стакана;
- сделки рынка;
- пользовательские исполнения;
- состояние открытых ордеров и позиций.
WebSocket нужен, потому что REST-поллинг обычно слишком медленный для своевременной реакции на исполнения.
Слой стратегии
Стратегия рассчитывает:
- mid price;
- bid/ask с учётом спреда;
- skew на основе текущей позиции;
- размер ордера;
- условия отмены, перестановки или остановки.
Здесь же должны жить лимиты: максимальная позиция, максимальная просадка, лимит на число ордеров, ограничения по волатильности.
Слой исполнения
Слой исполнения отвечает за:
- отмену старых заявок;
- выставление новых bid/ask;
- пакетные операции;
- обработку ошибок API;
- EIP-712 structured signing;
- безопасную работу с ключами.
На этом уровне критично не допускать рассинхронизации: бот должен понимать, какие ордера реально открыты, какие отменены, а какие уже исполнены.
Технические моменты реализации
Отправка ордеров через REST API
Пакетная отправка позволяет одновременно обновлять обе стороны котировки и снижать задержки:
def refresh_quotes(exchange, coin, bid_px, ask_px, order_size):
# Сначала отменяем старые ордера
open_orders = get_open_orders(coin)
if open_orders:
cancel_ids = [o["oid"] for o in open_orders]
exchange.bulk_cancel(coin, cancel_ids)
# Затем отправляем новые котировки
new_orders = [
build_limit_order(coin, is_buy=True, px=bid_px, sz=order_size),
build_limit_order(coin, is_buy=False, px=ask_px, sz=order_size),
]
return exchange.bulk_orders(new_orders)
Если Hyperliquid поддерживает для нужного сценария batch cancel-and-place, лучше использовать его, чтобы уменьшить окно между отменой и новой постановкой.
Отслеживание исполнений через WebSocket
Исполнения нужно обрабатывать почти сразу, иначе позиция и локальное состояние бота быстро устареют:
def on_user_fill(fill_data):
coin = fill_data["coin"]
side = fill_data["side"] # "B" = buy fill, "A" = sell fill
sz = fill_data["sz"]
px = fill_data["px"]
update_inventory(coin, side, sz, px)
trigger_quote_refresh(coin) # после исполнения обновляем котировки
WebSocket-соединения иногда обрываются. Обязательно реализуй:
- автоматический reconnect;
- повторную подписку на каналы;
- восстановление локального состояния после reconnect;
- сверку открытых ордеров и позиций через REST.
Основные риски
Маркет-мейкинг — это не «безрисковый арбитраж». На практике стратегия может быстро уйти в минус.
Ключевые риски:
- инвентарный риск — бот набирает лонг или шорт, а рынок идёт против позиции;
- adverse selection — тебя исполняют именно тогда, когда цена вот-вот двинется против твоей заявки;
- риск ликвидности — в тонком стакане невозможно быстро выйти без сильного проскальзывания;
- технический риск — баги, лаги, падение WebSocket, неверное состояние ордеров;
- API-лимиты — слишком частые запросы могут привести к ошибкам и задержкам;
- риск плеча — бессрочники с leverage усиливают как прибыль, так и убытки;
- funding risk — funding rate может ухудшать результат при удержании позиции.
Поэтому начинать стоит с тестнета или минимального размера позиции, а не с большого капитала.
OneKey: безопасное управление ключами для бота
Маркет-мейкер-боту нужно часто подписывать операции, но частые подписи не означают, что приватный ключ должен лежать на сервере в открытом виде.
Аппаратный кошелёк OneKey хранит приватный ключ в изолированной среде. Даже если сервер с ботом будет скомпрометирован, атакующий не сможет просто экспортировать приватный ключ.
Рекомендуемая схема:
- Использовать API Agent в Hyperliquid и создать отдельный кошелёк/агента для бота.
- Привязать его к основному аккаунту с ограниченной логикой доступа.
- Управлять основным аккаунтом и критичными операциями через OneKey.
- Пусть бот формирует сообщение для подписи локально.
- Подписанный запрос отправляется в Hyperliquid.
Такой подход снижает риск полной потери средств при взломе торгового сервера. Даже если код бота будет изменён вредоносно, критичные операции с основным кошельком не должны проходить без контроля через аппаратный уровень.
Для практической торговли без собственного бота можно использовать OneKey Perps: это более простой способ получить доступ к бессрочным контрактам, протестировать подход к риску и понять механику Hyperliquid-подобных рынков до разработки автоматизации.
Оптимизация производительности
Несколько практичных советов:
- используй пакетные операции для отмены и выставления ордеров;
- где уместно, выбирай
Alo/ post-only ордера, чтобы не забирать ликвидность случайно; - логируй каждую сделку: время, цену, объём, сторону, комиссию, funding;
- регулярно анализируй PnL: сколько заработано на спреде, сколько потеряно на инвентаре;
- добавь circuit breaker: при превышении дневного лимита убытка бот останавливается и отправляет уведомление;
- контролируй частоту запросов через token bucket или похожий алгоритм;
- при HTTP 429 делай backoff и не пытайся бесконечно спамить API;
- храни конфиги стратегии отдельно от кода и версионируй изменения.
FAQ
Q1: Сколько капитала нужно, чтобы начать маркет-мейкинг на Hyperliquid?
У Hyperliquid нет универсального официального минимума именно для маркет-мейкинга. Практический порог зависит от рынка, цены актива, минимального размера ордера, комиссий и выбранного риска. Лучше сначала тестировать стратегию на очень маленьком размере и повышать объём только после стабильной работы.
Q2: Откуда берётся прибыль маркет-мейкер-бота?
Основной источник — спред между покупкой и продажей. Если бот покупает чуть ниже mid price и продаёт чуть выше, разница может стать доходом после вычета комиссий. Но это не гарантировано: инвентарные убытки, резкие движения цены и funding могут перекрыть спред.
Q3: Как тестировать бота без риска для реальных средств?
Используй тестовую среду Hyperliquid, если она доступна для нужной интеграции. В документации Hyperliquid нужно найти раздел про testnet и переключить API endpoint на тестовую сеть. Даже после тестнета стоит начинать в проде с минимального размера.
Q4: OneKey не станет узким местом для бота?
Для большинства не-HFT стратегий скорость подписи OneKey достаточна. Если стратегия требует десятки подписей в секунду, можно рассмотреть архитектуру с API Agent и горячим кошельком для ограниченных торговых операций, а OneKey использовать для основного аккаунта, управления средствами и критичных действий. Это компромисс между безопасностью и производительностью.
Q5: Как работать с API-лимитами?
Нужно ориентироваться на актуальные лимиты из официальной документации Hyperliquid. На стороне бота стоит реализовать контроль частоты запросов, очередь операций, backoff при ошибках и отдельный мониторинг HTTP 429.
Заключение
Создание маркет-мейкер-бота на Hyperliquid — это смесь кванта, системной инженерии и криптобезопасности. Нужно уметь считать спред, управлять инвентарём, быстро обновлять заявки, переживать сбои API и не превращать приватный ключ в слабое место всей системы.
Если ты не готов сразу писать инфраструктуру с нуля, начни проще: скачай и попробуй OneKey, изучи работу кошелька и протестируй бессрочники через OneKey Perps. Это нормальный практический путь — сначала понять рынок, комиссии, плечо и риски руками, а уже потом решать, нужен ли тебе собственный бот.
Риск-предупреждение: маркет-мейкинг на бессрочных контрактах — высокорисковая стратегия. Убытки могут возникнуть из-за волатильности, технических сбоев, ошибок кода, лимитов API, ликвидаций и неработающей логики стратегии. Плечо усиливает потенциальные потери. Этот материал предназначен только для технического ознакомления и не является инвестиционной, финансовой или торговой рекомендацией. Оценивай свои риски самостоятельно и соблюдай законы своей юрисдикции.



