速率限制与用户限制
以下速率限制按 IP 地址适用：
- REST 请求共享每分钟 1200 的聚合权重限制。
- 所有已记录在文档中的
exchangeAPI 请求的权重为1 + floor(batch_length / 40)。例如，非批量操作的权重为1，长度为 79 的批量下单请求的权重为2。这里的batch_length是 action 中数组的长度，例如批量下单 action 中的订单数量。 - 以下
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。 candleSnapshotinfo 端点会按响应中每返回 60 个条目额外计入速率限制权重。- 所有
explorerAPI 请求的权重为 40。blockList有每区块 1 次的额外速率限制。注意，近期未被查询过的较旧区块可能被赋予更高的权重。对于大批量请求，请改用 S3 存储桶。 - 最多 10 个 WebSocket 连接
- 每分钟最多新建 30 个 WebSocket 连接
- 最多 1000 个 WebSocket 订阅
- 用户特定的 WebSocket 订阅中最多 10 个不同用户
- 所有 WebSocket 连接每分钟最多向 Hyperliquid 发送 2000 条消息
- 所有 WebSocket 连接上同时进行中（inflight）的 post 消息最多 100 条
rpc.hyperliquid.xyz/evm每分钟最多 100 个 EVM JSON-RPC 请求。注意，其他 JSON-RPC 提供商拥有更精细的速率限制逻辑以及归档节点功能。
要获得最低延迟的实时数据，请使用 WebSocket。完整的功能示例参见 Python SDK。
基于地址的限制
基于地址的限制按用户适用，子账户被视为独立用户。
速率限制逻辑允许自地址创建以来每累计交易 1 USDC 对应 1 次请求。例如，订单价值为 100 USDC 时，成交率需达到 1%。每个地址初始拥有 10000 次请求的缓冲额度。被限速时，地址每 10 秒允许一次请求。撤单的累计限制为 min(limit + 100000, limit * 2)，其中 limit 是其他操作的默认限制。这样，即使触达基于地址的速率限制，仍然可以撤销挂单。注意，该速率限制仅适用于操作（action），不适用于 info 请求。
每个用户默认的挂单限制为 1000 笔，且每 5M USDC 的交易量增加 1 笔，总计上限为 5000 笔挂单。当某用户已至少有 1000 笔其他挂单时再下单，如果该订单是只减仓订单或触发订单，则会被拒绝。
在高拥堵期间，地址被限制最多使用其前一日 Maker 份额占比 2 倍的区块空间。Maker 份额按与该资产对手续费等级的交易量贡献相同的系数进行缩放。例如，处于增长模式的 HIP-3 资产对该速率限制的计入更少。Maker 份额按每个 UTC 日期计算一次。因此，在高流量期间，对于已通过 API 返回结果的撤单，不再重复发送会有所帮助。在拥堵期间，批量操作的权重同时与其批量大小和每操作的固定权重成正比。因此，将撤单或订单合并批量处理会严格降低其权重并减少速率限制的占用。
批量请求
包含 n 笔订单（或撤单）的批量请求在基于 IP 的速率限制中被视为 1 次请求，但在基于地址的速率限制中被视为 n 次请求。