理解链上撮合
HL 按区块逐拍撮合 竞争颗粒从纳秒变为「区块」 我们围绕协议原生的延迟下限设计 而非空打无谓的微优化
同区节点 + 策略
节点与策略机分离 同处 apne1-az1 与 Foundation 节点同区 本地节点把行情数据面延迟降约 59%
工程级防护
订单超时机制 异步监听 ACK 以仓位上限为第一风控 应对秒级尾部异常 而非依赖撤单即时生效
与 CEX 的根本不同
HL 的撮合引擎 HyperCore 完全运行在链上 由 HyperBFT 共识定序 单区块终局
把 HL 理解成「定时拍卖行」
拍卖师约每个区块落槌一次（样本实测中位 ~78ms） 落槌瞬间统一处理当前所有报价 你的订单必须在下一次落槌前到达 才能参与本轮竞价
| 维度 | 传统 CEX（如 Binance） | Hyperliquid |
|---|---|---|
| 撮合位置 | 中心化服务器内存 | 链上（HyperCore） |
| 撮合模型 | 连续撮合 微秒级响应 | 逐区块撮合 实测区块间隔中位 ~78ms |
| 端到端延迟（最优） | <1ms（同机房） | 官方：同区客户端中位 ~200ms · P99 ~900ms |
| 竞争颗粒 | 纳秒 — 快 0.1ms 即可优先成交 | 区块 — 关键是进入「目标区块」 |
| 订单簿透明度 | 不透明 | 链上完全可验证 |
| 延迟下限来源 | 工程问题 可逼近 0 | 协议原生 共识过程本身耗时 |
关于「78ms」：此为我们样本（2026-03-13，n=642,275 个间隔）的区块间隔中位数。HL 官方未公开承诺固定区块周期，应视为对当前环境的观测，而非协议常量。
实测延迟结构
样本来自 Vultr Tokyo + AWS Tokyo apne1-az1 · 2026 年 3 月实测 · 为当时样本统计 不代表官方承诺或协议参数
78.5ms
区块间隔中位（做市报价节奏基线）
~59%
本地节点行情数据面延迟降幅
374ms
控制面中位 · apne1-az1 全测最优
184ms
控制面最优 · 接近同区理论值 200ms
142ms
本地节点行情中位（从 345ms 降低）
0.07ms
本地 API 仓位查询 · 无速率限制
延迟总览（实测）
数据面与本地 API 来自 Vultr Tokyo 节点实测 · 控制面来自各环境独立测试 · 本地 API 无速率限制
| 类别 | 场景 | median | min | P95 |
|---|---|---|---|---|
| 数据面 | 公共 WebSocket API（基线） | 345ms | 214ms | 619ms |
| 数据面 | 本地节点直读文件（推荐） | 142ms | 35ms | 214ms |
| 控制面 | AWS apne1-az1 · Rust REST | 374ms | 184ms | 583ms |
| 控制面 | Vultr Tokyo · Rust REST | 453ms | 207ms | 688ms |
| 本地 API | 账户仓位 clearinghouseState | 0.07ms | — | 0.07ms |
| 本地 API | 市场元数据 meta | 0.28ms | — | 0.32ms |
数据面 vs 控制面：本地节点主要优化数据面（你「看到」行情的速度），把行情中位从 345ms 降到 142ms（约 −59%）。下单走 HL 公共 API（api.hyperliquid.xyz）这条路径所有团队共享 本地节点不替代它 但能通过更及时的状态间接提升执行质量。
诚实说明：我们的实测并非极致数据。HL 的延迟下限来自协议本身 任何团队都无法突破。我们交付的价值不是「更快的纳秒」 而是把基础设施按协议特性正确工程化：同区部署、数据面优化、尾部异常防护与费率路径规划。
推荐架构
节点与策略分离 同处 apne1-az1 可用区 同区内网延迟远小于控制面延迟
Machine A
节点机 · Node
Non-Validating Node
区块同步 / 本地 API
高 IO · 本地 NVMe
区块同步 / 本地 API
高 IO · 本地 NVMe
Machine B
策略机 · Strategy
策略逻辑 / 风控
信号 / 下单
规格灵活 · 独立伸缩
信号 / 下单
规格灵活 · 独立伸缩
同 AZ 内两台 EC2 的内网延迟 远小于 374ms 的控制面中位 — 分离部署几乎不增加延迟开销
下单指令 → api.hyperliquid.xyz
所有团队共享的公共 API
01
互不干扰
节点进程 IO 密集 策略进程 CPU / 内存密集 分离后不争抢资源
02
故障隔离
节点崩溃或重启 不影响策略的信号处理与风控逻辑
03
独立伸缩
策略机可独立升级扩容 不受节点硬件约束 也便于按职责分配运维权限
节点规格与端口
HL 官方建议 16 vCPU / 64GB / 500GB SSD · 生产环境建议留更多核心余量
推荐节点机规格
| 参数 | 建议 | 说明 |
|---|---|---|
| 区域 | ap-northeast-1 | HL 官方推荐的低延迟区域（东京） |
| 可用区 | apne1-az1 | 与 Foundation 节点同区 减少传播跳数 |
| CPU | ≥ 32 核（推荐） | 官方最低 16 核 生产建议更多余量 |
| 内存 | ≥ 64GB | 节点数据缓存 |
| 存储 | 本地 NVMe（Instance Store） | 节点实时写入 不可用 EBS 替代 |
| 数据备份 | S3 | Instance Store 重启即失 成交需持久化 |
带本地 NVMe 的实例系列（c6id / m6id / r6id 等）均可满足基础需求 · 更高规格在节点稳定性与处理速度上优势明显 · 可联系我们做压测评估
关键端口配置
| Port | 协议 | 访问控制 | 说明 |
|---|---|---|---|
| 4001-4002 | TCP/UDP | 0.0.0.0/0 | P2P 同步 必须公网开放 关闭会导致节点在网络中降级 |
| 3001 | TCP | 仅内网 | 本地 API 供策略机直连 |
费率与做市返佣
14 天加权成交量决定基础费率层级 · 做市量份额额外叠加返佣 · 两套独立体系相加
永续合约基础费率
| 层级 | 14 天加权量 | Taker | Maker |
|---|---|---|---|
| 0 | — | 0.045% | 0.015% |
| 2 | >$25M | 0.035% | 0.008% |
| 3 | >$100M | 0.030% | 0.004% |
| 4 | >$500M | 0.028% | 0% |
| 6 | >$7B | 0.024% | 0% |
子账户成交量计入主账户 · 多账户共享同一费率层级 · 完整费率见 HL 官方文档
Maker 返佣（独立层级 额外叠加）
满足 14 天加权 Maker 量市场份额阈值即可获得额外返佣 · 最终 Maker 净费率 = 基础层 Maker 费率 + 额外返佣
| 返佣层级 | 14 天加权 Maker 量份额 | 额外 Maker 费率调整 |
|---|---|---|
| Tier 1 | >0.5% | -0.001% |
| Tier 2 | >1.5% | -0.002% |
| Tier 3 | >3.0% | -0.003% |
叠加示例：成交量达 Tier 4（Maker 0%）且满足返佣 Tier 1（−0.001%）→ 净 Maker 费率 −0.001% 每笔做市成交都获得返佣。返佣实时发放至交易钱包。
重要安全风险 · Staking Linking：质押账户与交易账户可通过 Staking Linking 共享折扣 但该操作永久不可撤销 一旦关联 质押账户将对交易账户拥有完全单边控制权（含资金处置）。机构团队须将质押地址私钥安全等级与交易账户同等对待 操作前充分评估内部权限流程。
进阶路径 · Foundation 节点
Hyper Foundation 在 apne1-az1 运行的 Non-Validating Node · 为你的本地节点减少获取区块数据的跳数 提升数据面稳定性
HYPE 质押量
≥ 10,000 HYPE
Maker 量份额
14 天加权 Maker 份额 > 0.5%（即返佣 Tier 1 及以上）
节点在线率
≥ 98%（时间加权）
P2P 网络
端口 4001-4002 公网可达 节点须为可靠 peer
战略意义：返佣 Tier 1（Maker 份额 > 0.5%）既是 Foundation 节点的申请门槛 也是额外 Maker 返佣的起点 — 两项福利共享同一规模阈值。越早建立做市规模 越早同时解锁两项收益。
官方免责：Foundation 节点按尽力而为提供 官方不保证可用性、延迟、性能或数据完整性 不应作为交易的唯一或权威数据源 接入可能随时被调整、限流或终止。
策略适配与风控防护
HL 执行环境对不同策略类型适配度不同 · 风控须以工程化机制应对秒级长尾
策略类型适配参考
| 策略类型 | 适配度 | 说明 |
|---|---|---|
| 做市（Maker 挂单） | ✅ 适合 | 天然契合 价差空间充足 有 Maker 返佣加持 |
| 链内统计套利（HL 多合约） | ✅ 适合 | 两腿都在链上 延迟对称 |
| 资金费率套利 | 适合 | 套利窗口以小时计 链上延迟可忽略 |
| 中短线趋势跟随 | 适合 | 信号有效期 > 秒级 374ms 可接受 |
| 跨所套利（HL vs CEX） | 有限 | HL 侧约 374ms 中位 套利窗口需足够宽 |
| 微秒级 HFT | ❌ 不适合 | 协议原生延迟远高于 CEX 不在同一量级 |
工程化风控建议
以下为基于样本观测的工程建议 非 HL 官方指引 · 撤单不等于即时生效 撤单与成交可能落在同一区块 顺序不定
订单超时
对无响应订单设超时阈值 按策略对尾部延迟的敏感度设定
异步确认
异步监听订单状态 不依赖单次 ACK 作为最终确认
仓位优先
以仓位上限为第一风控手段 不假设撤单立即生效
独立钱包
每个策略进程使用独立 API 钱包 避免 Nonce 竞争（官方明确建议）
从测试机开始
优先开放 apne1-az1 节点测试机 用你自己的策略与生产数据验证 让结果说话
Market Make on Hyperliquid We Ship the Infrastructure
节点部署 同区架构 费率路径 风控工程 — 专属团队按你的策略量身交付
@CloudHeisenberg