Лимиты запросов и пользовательские лимиты

Следующие лимиты запросов применяются в расчёте на IP-адрес:

• REST-запросы имеют общий агрегированный весовой лимит 1200 в минуту.
• Все описанные в документации запросы exchange API имеют вес 1 + floor(batch_length / 40). Например, непакетированные действия имеют вес 1, а пакетный запрос ордеров длины 79 — вес 2. Здесь batch_length — длина массива в действии, например количество ордеров в пакетном действии order.
• Следующие info-запросы имеют вес 2: l2Book, allMids, clearinghouseState, orderStatus, spotClearinghouseState, exchangeStatus.
• Следующие info-запросы имеют вес 60: userRole .
• Все остальные описанные info-запросы имеют вес 20.
• Следующие info-конечные точки имеют дополнительный вес лимита запросов на каждые 20 элементов, возвращённых в ответе: recentTrades, historicalOrders, userFills, userFillsByTime, fundingHistory, userFunding, nonUserFundingUpdates, twapHistory, userTwapSliceFills, userTwapSliceFillsByTime, delegatorHistory, delegatorRewards, validatorStats .
• Конечная точка candleSnapshot info имеет дополнительный вес лимита запросов на каждые 60 элементов, возвращённых в ответе.
• Все запросы explorer API имеют вес 40. blockList имеет дополнительный лимит запросов 1 на блок. Обратите внимание, что старые блоки, которые недавно не запрашивались, могут иметь больший вес. Для больших пакетных запросов используйте вместо этого S3-бакет.
• Максимум 10 WebSocket-соединений
• Максимум 30 новых WebSocket-соединений в минуту
• Максимум 1000 подписок WebSocket
• Максимум 10 уникальных пользователей в пользовательских подписках WebSocket
• Максимум 2000 сообщений, отправляемых в Hyperliquid в минуту, по всем WebSocket-соединениям
• Максимум 100 одновременно находящихся в обработке (inflight) post-сообщений по всем WebSocket-соединениям
• Максимум 100 запросов EVM JSON-RPC в минуту для rpc.hyperliquid.xyz/evm. Обратите внимание, что у других провайдеров JSON-RPC есть более сложная логика лимитирования и функциональность архивных нод.

Используйте WebSocket для получения данных реального времени с минимальной задержкой. Полнофункциональный пример см. в Python SDK.

Лимиты по адресу

Лимиты по адресу применяются в расчёте на пользователя, при этом суб-счета считаются отдельными пользователями.

Логика лимитирования допускает 1 запрос на каждые 1 USDC торгового объёма, накопленного с момента создания адреса. Например, при стоимости ордера 100 USDC требуется доля исполнения 1%. Каждый адрес получает начальный буфер в 10000 запросов. При срабатывании лимита запросов адресу разрешается один запрос каждые 10 секунд. Отмены имеют кумулятивный лимит min(limit + 100000, limit * 2), где limit — лимит по умолчанию для других действий. Таким образом, при достижении лимита по адресу остаётся возможность отменять открытые ордера. Обратите внимание, что этот лимит запросов применяется только к действиям, а не к info-запросам.

Каждый пользователь имеет лимит открытых ордеров по умолчанию 1000 плюс один дополнительный ордер на каждые 5M USDC объёма, с общим лимитом в 5000 открытых ордеров. Если ордер размещается, когда у того же пользователя уже есть не менее 1000 других открытых ордеров, он будет отклонён, если является reduce-only или триггерным ордером.

В периоды высокой перегрузки адреса ограничены использованием 2x своей доли маркет-мейкера за предыдущий день в процентном отношении к пространству блока. Доля маркет-мейкера масштабируется тем же фактором, что и вклад объёма соответствующего актива в тиры комиссий. Например, активы HIP-3 в режиме роста засчитываются в этот лимит в меньшей степени. Доля маркет-мейкера вычисляется один раз за UTC-дату. Поэтому в периоды высокого трафика может быть полезно не пересылать отмены, результаты которых уже были возвращены через API. При перегрузке вес пакетного действия пропорционален как размеру пакета, так и фиксированному весу на действие. Следовательно, пакетирование отмен или ордеров вместе строго уменьшает их вес и снижает расходование лимита запросов.

Пакетные запросы

Пакетный запрос с n ордерами (или отменами) считается одним запросом для лимитирования по IP, но n запросами для лимитирования по адресу.