第三章：技术底座与算力架构

3.1 HyperCore L1：自建Layer 1

3.1.1 架构设计理念

Hyper Liquid 选择自建 Layer 1 区块链，而非部署在现有公链之上。这一决策源于其对交易性能的核心需求。通用型区块链（如 Ethereum、Solana）在设计上需要兼顾多种应用场景，包括 NFT 铸造、社交应用、DAO 治理等，其交易排序和状态机设计无法为金融交易场景做出极端优化。

HyperCore L1 的设计理念是"为金融交易而生"。整个区块链被设计为一台专用状态机，其唯一职能是维护中央限价订单簿（CLOB）并执行交易生命周期中的所有操作：下单、撤单、撮合、清算、保证金计算和资金费率结算。HyperCore 不处理通用智能合约，不产生事件日志，不维护交易追踪轨迹。所有状态变更均通过 EIP-712 结构化签名消息表达，验证节点直接读取这些消息以认证和执行每笔操作。

这种"单用途"架构消除了通用区块链中交易排序的不确定性、Gas 竞拍带来的延迟波动以及智能合约执行可能引发的状态冲突。HyperCore 将有限的区块空间和计算资源全部用于交易处理，不受非交易类应用的资源争用影响。

3.1.2 Rust 实现

HyperCore 使用 Rust 编程语言实现。Rust 提供的内存安全保证和无垃圾回收特性使其成为高性能区块链开发的常用选择。Rust 的所有权模型在编译期消除空指针引用、数据竞争和缓冲区溢出等常见内存错误，这对于处理用户资产的交易系统至关重要。

Rust 的零成本抽象特性使 HyperCore 可以在高吞吐量场景下保持稳定的执行性能。HyperCore 每秒处理约 200,000 笔订单操作，其中每笔操作均需经过签名验证、状态读取、状态变更和状态持久化等完整流程。Rust 在此场景下不存在运行时性能抖动，适合低延迟金融应用的需求。

3.1.3 模块化设计

HyperCore 采用模块化架构，将不同功能域划分为独立模块：

• 交易引擎（Trading Engine）：负责订单接收、验证和路由。
• 撮合引擎（Matching Engine）：维护订单簿数据结构，执行买卖撮合逻辑。
• 清算所（Clearinghouse）：管理保证金账户、仓位记录、强制清算和资金费率计算。
• 预言机模块（Oracle Module）：集成外部价格数据源，维护链上价格喂送。
• 资产模块（Asset Module）：处理资产存款、提款和内部转账。

各模块之间通过定义清晰的接口通信，使系统可以在不影响整体架构的前提下对单个模块进行优化升级。清算所作为中央风险引擎，确保所有交易相关的风险操作以确定性方式在所有验证节点上获得一致处理。

3.2 HyperBFT 共识协议

3.2.1 HotStuff 变体

Hyper Liquid 使用的共识协议名为 HyperBFT，是 HotStuff 共识协议的一个变体实现。HyperBFT 属于经典拜占庭容错（BFT）协议家族，采用基于领导者的消息传递模式。

在每轮共识中，一个验证节点被选为区块提议者（Proposer），负责构建新区块并向其他验证节点广播。其余验证节点对区块进行投票。当超过三分之二（按质押权重计算）的验证节点达成一致时，区块即被最终确认。

HyperBFT 选择 HotStuff 路线而非 Tendermint 路线的原因在于通信复杂度。Tendermint 协议的通信复杂度为 O(n^2)，即在 n 个验证节点场景下需要 n^2 量级的消息交换。HyperBFT 通过领导者的消息聚合机制将通信复杂度降低至 O(n)，使系统在验证节点数量增长时仍能保持性能稳定。

Hyper Liquid 最初在开发过程中测试了 Tendermint，但因其无法满足高吞吐量需求而转向基于 HotStuff 的自研方案。

3.2.2 最终性与延迟

HyperBFT 提供确定性最终性（Deterministic Finality）。一旦区块被 HyperBFT 确认，该区块即被视为不可逆，不存在重组（Reorg）风险。这与 Ethereum 的 Gasper 共识机制形成对比，后者提供概率性最终性，理论上存在区块被回滚的可能。

HyperBFT 的端到端最终性延迟表现如下：

• 中位延迟：约 0.1—0.2 秒。
• 第 99 百分位延迟：低于 0.9 秒。
• 区块产出频率：每秒约 12 个核心区块。

确定性最终性和亚秒级确认时间对金融交易场景意义重大。交易者无需等待多个区块确认即可确信交易已生效，这消除了基于概率最终性系统所需的多区块等待窗口。做市商可以在亚秒级时间内完成仓位调整，降低因等待确认而产生的价格暴露风险。

3.2.3 理论 TPS 与拜占庭容错

HyperBFT 的理论吞吐量上限约为每秒 100,000 笔交易（TPS），而在实际运行中可处理约每秒 200,000 笔订单操作。GetPrice 带宽显著高于此数值，可达每秒约 200 万次查询。

HyperBFT 遵循标准 BFT 假设：系统中最多可容忍 f 个拜占庭故障节点，总验证节点数需满足 n = 3f + 1。当超过三分之二的验证节点保持诚实且在线的条件下，系统活跃性（Liveness）得以维持。

拜占庭容错特性确保了即使部分验证节点受到攻击或被恶意控制，系统仍能正确执行交易处理，不会产生错误的状态变更。HyperBFT 不依赖经济博弈假设（如 Ethereum 的惩罚机制），而是通过协议层面确保节点行为一致性。

3.2.4 乐观执行与乐观响应

HyperBFT 实现了两个优化特性：乐观执行（Optimistic Execution）和乐观响应（Optimistic Responsiveness）。

乐观执行允许交易在区块获得最终确认之前即被执行。验证节点在接收到提案后即可执行区块中的交易，无需等待完整的共识确认流程。这缩短了交易从提交到执行的可感知延迟。

乐观响应机制使区块产出速度不再受固定的超时参数限制。当系统达到法定人数（Quorum）时，下一个区块可以立即开始生产，无需等待预设的区块间隔时间。这使 HyperBFT 在网络状况良好时能够自动提升出块速度，在网络状况恶化时退回到更保守的出块节奏。

3.3 双链架构（HyperL1 + HyperEVM）

3.3.1 HyperL1：交易执行层

HyperL1（即 HyperCore）是交易执行层，负责所有交易操作的原生处理。它是权限链（Permissioned Chain），即只有核心协议代码可以部署和运行于该层之上。外部开发者不能在 HyperL1 上部署自定义逻辑。

HyperL1 的状态变更通过 EIP-712 签名消息表达。用户使用结构化数据签名的方式授权特定操作，包括：市价单、限价单、止盈止损单、TWAP 订单、阶梯订单、现货转账、金库存取和永续合约交易。每类操作均有明确的 Schema，验证节点据此解析和执行。

HyperL1 上不存在智能合约，不产生事件日志，也没有交易追踪记录。这种设计使交易执行路径最短化：签名验证 → 状态读取 → 状态变更 → 状态持久化，不经过任何中间层解释执行。

3.3.2 HyperEVM：EVM 兼容智能合约层

HyperEVM 是 Hyper Liquid 上的以太坊虚拟机兼容层，部署于 HyperCore 之上。与 HyperL1 不同，HyperEVM 是无权限链（Permissionless Chain），任何开发者均可在其上部署 Solidity 智能合约。

HyperEVM 支持标准以太坊开发工具链：Solidity 编译器、Hardhat、Foundry、MetaMask 等均可在无需修改的条件下直接使用。这意味着现有的以太坊 DeFi 协议可以相对便捷地迁移至 HyperEVM。

HyperEVM 的区块类型分为两类：

• 小区块（Small Block）：Gas 上限约 2,000,000，每约 1 秒产出一个，用于常规交易和简单的合约调用。
• 大区块（Large Block）：Gas 上限约 30,000,000，每约 1 分钟产出一个，用于合约部署和计算密集型操作。

需要部署大型合约的地址必须通过 HyperL1 的 evmUserModify 操作主动选择加入大区块内存池，否则其交易将被限制在小区块的 Gas 上限之内。

3.3.3 双链互操作机制

HyperL1 和 HyperEVM 共享同一套验证节点集合和同一共识协议（HyperBFT），但维护各自独立的状态空间。两者之间通过以下机制实现互操作：

预编译合约（Precompiles）：HyperEVM 上的智能合约可以通过调用预编译地址（起始于 0x0000...0800）读取 HyperL1 的状态数据。预编译合约始终读取最新的 HyperL1 状态，而非 EVM 区块创建时固定的快照。这使得智能合约可以实时获取订单簿价格、用户持仓、现货余额和预言机价格数据，无需依赖外部预言机进行跨层数据传递。

CoreWriter 系统合约：HyperEVM 上的智能合约可以通过调用部署在 0x3333...3333 地址的 CoreWriter 合约向 HyperL1 写入数据。CoreWriter 会发出事件（Event），HyperL1 节点监控这些事件并将其转换为对应的 L1 操作，在下一个区块周期中执行。

关键限制在于：CoreWriter 的跨层操作不是原子性的。EVM 交易可能执行成功，但对应的 L1 操作可能因保证金不足等原因执行失败，此时 EVM 交易不会回滚。开发者需要自行处理这种跨层操作失败的情况。

资产跨层转移：

• 从 HyperEVM 转移资产至 HyperL1：将标准 ERC-20 代币转账至代币对应的系统地址（0x200...00N），节点观察到该转账后排队，在下一个 HyperL1 区块中完成结算。
• 从 HyperL1 转移资产至 HyperEVM：在 HyperL1 端发起现货发送（Spot Send）操作，排队后在下一个 EVM 区块开始时执行。

资产跨层转移是原子性的——要么完成，要么失败，不存在资产被锁定的中间状态。总账本在所有层之间保持一致，无需依靠跨链桥机制。

3.3.4 安全性边界

双链架构的一个重要设计决策是安全边界隔离。HyperEVM 上的智能合约漏洞不会影响 HyperL1 交易引擎的运行。一个在 HyperEVM 上存在重入漏洞的借贷协议无法破坏订单簿数据、清算逻辑或保证金系统。HyperL1 的交易执行与 HyperEVM 的任意合约执行之间不存在 Gas 竞争或状态冲突。

这种隔离设计确保了即使 HyperEVM 生态中出现严重安全问题，平台的交易核心仍然可以正常运行。

3.4 节点架构与网络

3.4.1 节点类型

Hyper Liquid 网络中存在两种节点类型：

验证节点（Validator Node）：参与 HyperBFT 共识过程，负责区块提案、投票和最终确认。验证节点需要配置两个独立的钱包：Validator Wallet（冷钱包，持有资产并接收质押奖励）和 Signer Wallet（热钱包，仅用于签署共识消息）。验证节点需要打开 4001—4006 端口与其他验证节点通信，运行硬件最低要求为 4 核 CPU、32 GB RAM、200 GB 磁盘及 Ubuntu 24.04 操作系统。

全节点（Full Node / Non-Validator Node）：不参与共识过程，但同步和存储区块链全部数据。全节点可以为外部提供数据流和 API 接口服务，通常由基础设施提供商（如 QuickNode、Dwellir）或需要实时链上数据的机构用户运行。

3.4.2 验证节点分组

Hyper Liquid 定义了四组验证节点，各自承担不同角色：

• Hot Validator Set：处理高频操作，例如用户提款验证。使用热钱包签名。
• Cold Validator Set：管理系统配置变更、验证节点集合更新，可以废止提款请求。使用冷钱包签名。
• Finalizers：确认跨链桥状态变更（存款和提款在争议期之后由该组最终确认）。
• Lockers：紧急安全委员会，可以通过投票暂停或冻结桥合约。当前由 5 个地址组成，采用 2/5 多签阈值。

在系统启动时，Hot Validator 地址自动注册为 Lockers 和 Finalizers。

3.4.3 网络拓扑

验证节点之间通过点对点（P2P）网络进行通信。网络拓扑遵循以下原则：

• 验证节点之间直接建立 gRPC 连接，用于共识消息交换。
• 验证节点需与至少三分之一的验证节点（按质押权重计算）保持双向延迟低于 200 毫秒。
• 专业运营方通常采用哨兵节点（Sentry Node）架构，在验证节点前端部署全节点作为屏障。验证节点仅与受信任的哨兵节点通信，哨兵节点负责处理所有外部 P2P 消息，降低验证节点直接暴露于网络攻击的风险。

3.4.4 质押与委托

验证节点通过质押 HYPE 代币参与共识。节点注册时需发送 CValidatorAction 操作，其中包含节点 IP 地址、名称、描述、佣金率（以基点表示）和签名者地址。

代币持有者可以通过 tokenDelegate 操作将代币委托给验证节点。委托使用基于时间戳 Nonce 的重放保护机制。当前网络上约 23 个验证节点，其中 Hyper Foundation 控制约 78.54% 的质押代币并直接运营 5 个验证节点。

3.4.5 节点生命周期管理

节点的生命周期由 hl-visor 守护进程管理。hl-visor 负责生成 hl-node 主进程、处理重启、验证二进制签名以及管理更新。hl-node 是核心进程，负责连接 P2P 网络、处理链数据、参与共识（仅验证节点）以及提供 API 接口。

验证节点可以发起 jailSelf 操作主动退出共识（如计划内维护），之后通过 unjailSelf 操作重新参与共识。节点在首次注册或更换 IP 地址后也会自动进入 Jailing 状态。

3.4.6 数据流与 API

Hyper Liquid 提供多类数据流接入方式：

• gRPC 流：实时推送交易数据，支持订阅 Trades、Orders、Book_Updates、Blocks、Events 和 Writer_Actions 等数据类别。gRPC 端口为 10000，支持双向流式通信。
• WebSocket：提供订单簿快照（StreamL2Book、StreamL4Book）和实时更新。
• Info REST API：提供历史数据查询，用于补全 gRPC 滚动窗口（约 24 小时）之外的数据需求。

3.5 安全性审计与历史事件

3.5.1 审计报告

Hyper Liquid 核心桥合约已由安全审计公司 Zellic 完成审计。审计工作分为两个阶段：

• 初始审计：2023 年 8 月 14 日完成，覆盖桥合约的智能合约代码。
• 补丁复查：2023 年 11 月 27 日完成，对初始审计发现的问题的修复方案进行验证。

需要指出的是，Zellic 审计的范围仅限于桥合约的智能合约部分，不包括以下组件：链下基础设施、前端界面、密钥托管方案和系统整体架构。Hyper Liquid 的核心交易引擎、清算逻辑和订单簿实现尚未有公开的第三方审计报告。HLP Vault 智能合约同样未有公开审计报告。

Hyper Liquid 目前运行漏洞赏金计划，覆盖节点、API 服务器和测试网 HyperEVM 组件。

3.5.2 重大安全事件

2025 年 3 月 — JELLY 代币操纵攻击：

攻击者在低流动性的 JELLY 永续合约市场上使用杠杆开立多空双向头寸，在 1 小时内将 JELLY 价格推高 429%。Hyper Liquid 流动性池（HLP）作为交易对手方承受了未实现亏损，约 2.3 亿美元的 HLP 资金面临风险。验证节点投票决定下架 JELLY 永续合约，以每枚 0.0095 美元的价格结算持仓（当时市场价约 0.50 美元）。攻击者最终提取了 626 万美元，剩余资金被冻结。该事件暴露了验证节点在极端情况下对市场的干预能力，引发了关于协议去中心化程度的讨论。

2025 年 9 月 26 日 — HyperVault Rug Pull：

HyperVault 是一个建立在 Hyper Liquid 上的收益 farming 协议。其开发团队删除了所有社交媒体账号，关闭网站，并将约 360 万美元的用户资金通过 Tornado Cash 转移。HyperVault 此前声称获得了多个审计公司的审计报告，但 Spearbit、Pashov 和 Code4rena 均否认参与过该项目的审计。该协议承诺的年化收益率高达 95%，属于典型的庞氏骗局警示信号。

2025 年 9 月 27 日 — HyperDrive 漏洞利用：

HyperDrive 是一个基于 Hyper Liquid 的 DeFi 借贷协议。攻击者利用其路由器合约的任意函数调用漏洞，绕过了操作员权限限制，盗取约 77.3 万至 78.2 万美元。被盗资金通过 deBridge 跨链桥转移至 Ethereum（约 49.4 万美元）和 BNB Chain（约 27.9 万美元）。HyperDrive 暂停了所有市场并向攻击者提供了 10% 的白帽赏金。

HLP 强平事件：

一名交易者使用 50 倍杠杆开立 ETH 永续合约头寸，引发了级联强平。HLP 作为交易对手方承受了约 400 万美元的亏损，交易者获利约 180 万美元。该事件暴露了 HLP 风险管理系统在应对极端集中头寸时的局限性。

朝鲜 Lazarus Group 相关攻击：

2024 年 12 月，区块链安全研究人员检测到 Lazarus Group 在 Hyper Liquid 上进行测试交易。2025 年，一起涉及 POPCAT 代币的约 1,200 万美元的强平操纵攻击被认为与朝鲜黑客有关。攻击者开立了约 2,600 万美元的杠杆 POPCAT 头寸，主动亏损约 300 万美元以压低价格，触发连锁清算，导致 HLP 产生约 490 万美元的坏账。

3.5.3 协议层安全争议

2025 年底，一份技术分析报告对 Hyper Liquid 的安全性提出了若干质疑：

• 广播地址限制：全网仅有 8 个广播地址（Broadcast Addresses）可以提交交易。Hyper Liquid 方面解释这是防止 MEV 攻击的设计，并计划在未来切换至多提议者模式。
• CoreWriter 权限：CoreWriter 被外部研究者称为"上帝模式"（God Mode）后门。Hyper Liquid 方面承认这是 L1 与 HyperEVM 之间的接口，但权限受严格限制。
• 跨链桥逃生口缺失：用户提款完全依赖验证节点集合，不存在强制提款机制。对此 Hyper Liquid 方面未给出完整回应。
• 偿付能力争议：初期报告中提到的 3.62 亿美元偿付能力缺口被证实为计算错误——原生 USDC 迁移至 HyperEVM 后未被计入旧的 Arbitrum 桥余额。协议总偿付能力约为 43.5 亿美元。

3.5.4 风险评估总结

Hyper Liquid 在安全性方面面临的核心挑战来源于其架构选择和去中心化程度之间的权衡。HyperCore 作为专用状态机的设计使其攻击面小于通用区块链——没有智能合约风险直接威胁交易引擎。但验证节点集合规模较小（约 23 个节点，Foundation 控制多数质押权重），使其在抗审查性和去中心化安全性方面弱于 Ethereum 等大型公链。

生态系统的安全风险主要集中在 HyperEVM 层和第三方协议。HyperVault 和 HyperDrive 的安全事件表明，HyperEVM 生态中的 DeFi 协议面临着与传统 EVM 生态相同的智能合约风险，而 Hyper Liquid 的品牌效应反而可能使用户对第三方协议的安全性产生过度信任。

低流动性永续合约市场的操纵攻击是 Hyper Liquid 特有的风险类别。攻击者可以利用部分交易对流动性不足的特性，通过大额杠杆头寸操纵市场价格，迫使 HLP 承受亏损。验证节点虽然可以下架问题合约作为最后手段，但这种干预本身也构成了中心化风险。

3.6 开源与闭源策略

Hyper Liquid 在开源与闭源之间采取了分层策略，不同技术模块的开放程度取决于其核心竞争力属性与安全风险考量。这一策略直接影响外部做市商和开发者对协议的可审计性、可验证性以及信任建立方式。

3.6.1 核心模块的闭源选择

共识层（HyperBFT）和核心撮合引擎属于完全闭源范畴。 这两部分构成了 Hyper Liquid 相对于竞品的核心技术护城河——撮合引擎的订单簿管理算法、价格优先时间优先排序逻辑、清算触发条件的微秒级优化，直接决定了平台在竞争中的性能优势和市场地位。将这部分代码开源意味着向竞争对手——包括 dYdX、Jupiter 等直接竞品及潜在的 Layer 1 公链项目——提供可直接复制的性能优化方案。

此外，闭源策略也出于安全考量：撮合引擎的漏洞若被公开，可能引发系统性风险。核心团队通过严格的内部审计和持续监控来确保这部分代码的可靠性。

3.6.2 智能合约层的开源策略

与核心层相反，智能合约层——包括 HyperEVM 的实现、协议控制的流动性池合约（HLP 相关合约）、跨链桥合约——采取了开源策略。 这一选择的逻辑在于：合约层代码的可审计性直接关系到用户资金安全。做市商和流动性提供者在决定是否接入平台之前，需要对协议的风控参数、费用分配逻辑和清算优先级规则进行独立的代码审计。闭源的合约层将迫使市场参与者依赖对核心团队的信任而非代码层面的验证，这与去中心化金融的“无需信任”（Trustless）原则相悖。

HyperEVM 的开源还促进了生态项目的开发——第三方开发者可以基于开源的合约示例和标准库快速搭建自己的应用。

3.6.3 API 与 SDK 的开源

API 文档和客户端 SDK 同样保持开源状态。 Hyper Liquid 维护了面向 Python、Rust、TypeScript 等多个语言的 SDK 仓库，涵盖订单签名构建、数据流订阅、账户查询等常见操作的标准实现。这些 SDK 的开源降低了做市商的技术接入门槛——交易团队可以直接复制、修改和集成 SDK 代码到自有交易系统，无需从零解析 gRPC 接口的二进制协议。

API 文档的开源性质还允许社区贡献者对文档进行修正和补充，形成自生长的技术知识库。这种策略与中心化交易所的做市商接入模式形成对比：CEX 通常以闭源 SDK 或纯 API 规范文档的形式提供接入途径，技术细节的透明度较低。

3.6.4 对做市商的信息不对称影响

做市商在评估 Hyper Liquid 的技术可信度时面临的信息不对称问题因此呈现分化：

• 在合约层和 API 层，代码的完全可视意味着做市商可以获得与核心团队同等级别的代码阅读权限，合约风险基本可控。

• 在共识层和撮合层，代码闭源意味着做市商需要通过运行验证者节点来间接验证协议行为——观察区块提案是否包含异常交易、确认共识流程是否按规范执行。

这一策略本质上是一种 “运行即可验证”（Run-to-Verify）的信任模型，与完全开源协议的“阅读即可验证”（Read-to-Verify）模型存在差异。2025 年 JELLY 事件后，社区中出现了要求撮合层部分开源的呼声，核心团队的回应是增加了链上事件日志的详细程度——通过增加透明度而非开放源代码来回应社区关切。

3.6.5 策略合理性评估

从协议发展阶段来看，Hyper Liquid 的分层开源策略具有现实合理性。在早期阶段，闭源保护了核心算法的竞争优势，使团队能够在没有专利保护的情况下维持技术领先。随着协议成熟和竞争格局变化，未来可能逐步开放更多模块——例如在验证者集进一步去中心化后，共识层的开源将有助于增强网络的可信度。当前，做市商和开发者应根据自身风险偏好，结合链上可验证数据和开源合约层做出独立的信任判断。

第四章 交易模型与业务解析

Hyper Liquid 的核心业务围绕链上永续合约交易展开，并在 2025 年至 2026 年期间逐步扩展至现货交易和预测市场。本章从产品矩阵、交易机制、资金费率、费用结构以及用户接入方式五个维度，对 Hyper Liquid 的交易模型进行解析。

4.1 产品矩阵

4.1.1 永续合约交易对

Hyper Liquid 提供以 USDC 为保证金的线性永续合约（Linear Perpetual）。每张合约代表 1 单位标的资产。所有合约均以 USDC 作为抵押品，价格锚定由验证节点计算的指数价格。

截至 2026 年第一季度，Hyper Liquid 支持的永续合约交易对覆盖以下类别。

第一类为加密资产永续合约。主要交易对包括 BTC、ETH、SOL、XRP、AAVE、ADA、APT、AVAX、BCH、CRV、DOGE、ENA、LINK、LTC、NEAR、SUI、UNI、WLD、ARB、BNB、DOT、JUP、TON、TRX 等数十个品种。平台还上线了部分 Meme 币种及生态代币，如 FARTCOIN、PUMP、TRUMP、kPEPE、kBONK、kSHIB 等。此外，PURR-USD 和 HYPE-USD 以 USDC 直接计价。

第二类为传统资产永续合约。2026 年 3 月，S&P Dow Jones Indices 授权 TradeXYZ 在 Hyper Liquid 上推出首支经官方许可的链上 S&P 500 指数永续合约。该产品面向合格的非美国投资者，支持 24/7/365 不间断交易，以 USDC 结算。此后，纳斯达克 100、WTI 原油、布伦特原油、黄金、白银等传统资产永续合约也通过 HIP-3 机制陆续上线。截至 2026 年 3 月，Hyper Liquid 前 30 大 HIP-3 市场中，23 个为传统资产类别。

4.1.2 现货交易

Hyper Liquid 于 2025 年上线现货交易功能。现货市场与永续合约共享同一流动性账户体系，用户可在现货与永续合约之间直接划转资金。现货交易采用与永续合约相同的订单簿模型，同样由 HyperCore L1 提供执行环境。

现货交易的费率结构与永续合约独立计算，但现货交易量以双倍权重计入用户的交易量等级评定，从而间接降低永续合约的交易费率。现货交易的 Taker 费率为 0.070%，Maker 费率为 0.040%（基础等级）。

4.1.3 预测市场（HIP-4）

2026 年 5 月，HIP-4 提案正式实施，Hyper Liquid 上线预测市场（Outcome Markets）。该产品支持二元结果和多元结果的事件合约，直接与 Polymarket 等传统预测市场平台竞争。

预测市场的核心设计特征如下。第一，用户开仓时无需支付任何费用，仅在平仓或结算时产生费用。第二，所有头寸以 USDH（Hyper Liquid 原生稳定币）全额抵押，不涉及杠杆、资金费率或清算引擎。第三，任何人都可以通过质押 1,000,000 HYPE 来无许可地创建新的预测市场。

初期上线的产品包括 BTC 每日二元合约，后续计划扩展至政治事件、体育赛事和宏观数据发布等领域。

4.2 交易机制详解

4.2.1 杠杆倍数分级

Hyper Liquid 采用分层杠杆机制（Tiered Margin）。不同资产和不同名义持仓规模对应不同的最大杠杆倍数。杠杆分级的设计目的是控制大额持仓的系统性风险。

主要资产的杠杆分级规则如下。

BTC 永续合约的名义持仓在 0 至 1.5 亿美元区间时，最大杠杆为 40 倍；超过 1.5 亿美元后降至 20 倍。ETH 永续合约的名义持仓在 0 至 1 亿美元区间时，最大杠杆为 25 倍；超过后降至 15 倍。SOL 永续合约的名义持仓在 0 至 7000 万美元区间时，最大杠杆为 20 倍；超过后降至 10 倍。XRP 永续合约在 0 至 4000 万美元区间最大杠杆为 20 倍，超过后降至 10 倍。

大多数山寨币（如 AAVE、ADA、APT、DOGE、LINK 等）在持仓不超过 2000 万美元时最大杠杆为 10 倍，超过后降至 5 倍。ARB、BNB、DOT、JUP 等币种在持仓不超过 300 万美元时最大杠杆为 10 倍，超过后降至 5 倍。

初始保证金比例由用户设定的杠杆倍数决定，计算公式为 1 / 杠杆倍数。维持保证金比例设定为该资产在对应杠杆等级下最大杠杆对应初始保证金比例的一半。

4.2.2 保证金模式（逐仓/全仓）

Hyper Liquid 支持两种保证金模式：逐仓保证金（Isolated Margin）和全仓保证金（Cross Margin）。

逐仓模式下，分配给特定仓位的保证金被隔离在该仓位内。该仓位的亏损不会影响账户中其他仓位的资金。用户可以根据每个仓位的风险偏好独立设置杠杆倍数。

全仓模式下，账户内所有可用余额共享作为多个仓位的保证金。当某个仓位的亏损导致账户总权益低于维持保证金要求时，该仓位将被触发清算。全仓模式的优点是资金利用效率更高，但风险敞口也更大。

2026 年 3 月，Hyper Liquid 进一步推出了投资组合保证金（Portfolio Margin）功能。该功能允许系统在计算保证金要求时，将多个相关仓位的风险进行对冲抵消（如同时持有 BTC 多头和 ETH 空头被视为部分对冲）。投资组合保证金目前仅向加权交易量超过 500 万美元的主账户开放。

4.2.3 强平机制与清算流程

Hyper Liquid 采用三层防御体系来处理亏损仓位，称为"瀑布模型"（Waterfall Model）。

第一层为标准清算（Standard Liquidation）。当仓位的维持保证金不足时，系统在订单簿上以市价方式平仓。清算引擎将亏损仓位挂入订单簿，由对手方吃单承接。若订单簿流动性足以覆盖该仓位，清算过程即告完成。

第二层为保险基金介入。若订单簿的流动性不足以在合理价格范围内完成清算，保险基金（即 HLP 资金池）将介入，临时吸收该仓位。保险基金的规模在 2025 年至 2026 年期间持续增长，曾在 2025 年 10 月的市场暴跌中于 1 小时内产生约 4000 万美元的盈利。

第三层为自动减仓（ADL）。当保险基金耗尽或接近耗尽时，ADL 机制被触发。ADL 的具体逻辑在 4.2.4 节详述。

清算价格的计算取决于杠杆倍数和保证金模式。以 50 倍杠杆为例，约 2% 的反向价格波动即会触发清算。10 倍杠杆下，约 10% 的反向波动才会触发清算。维持保证金比例越低，清算价格距离开仓价格越远。

4.2.4 ADL（自动减仓）机制

自动减仓（Auto-Deleveraging, ADL）是永续合约交易所的最后一道风险防线。当标准清算和保险基金均无法吸收亏损时，系统强制减仓或平仓盈利方头寸，以维持交易所的偿付能力。

Hyper Liquid 的 ADL 选择目标仓位时依据三个指标。第一是未实现盈利（Unrealized PnL）：盈利越高，被选中的优先级越高。第二是杠杆倍数：杠杆越高，优先级越高。第三是仓位大小：仓位越大，优先级越高。综合而言，高杠杆、高盈利的大额头寸会被优先减仓。

2025 年 10 月，Hyper Liquid 在成立两年多以来首次触发 ADL。在这次市场暴跌中，ADL 在 12 分钟内强制平仓了约 21 亿美元的头寸。事后分析显示，ADL 算法存在过度减仓问题，导致盈利交易者额外损失约 4500 万至 5170 万美元。此次事件后，Hyper Liquid 约 50% 的未平仓量流失，而竞争平台则出现恢复。

2025 年 11 月，Hyper Liquid 部署了跨保证金 ADL 系统（Cross-Margin ADL），在所有主要永续合约市场中启用了改进后的 ADL 逻辑。该系统经过一个月的内部压力测试后上线。

学术研究（Gauntlet 的 Tarun Chitra 发表的论文）指出，没有任何 ADL 机制能同时满足交易所偿付能力、交易所收入和交易者公平性三个目标，这一结论被称为"ADL 三难困境"（ADL Trilemma）。

4.3 资金费率机制

4.3.1 费率计算方式

资金费率是永续合约维持价格锚定的核心机制。Hyper Liquid 的资金费率每小时结算一次。每小时的费率为 8 小时费率的 1/8。

资金费率计算公式如下：

资金费率（F）= 平均溢价指数（P）+ clamp（利率 − 溢价指数，−0.0005，+0.0005）

其中：

• 利率固定为每 8 小时 0.01%（即每小时 0.00125%，年化约 11.6%，方向为多头向空头支付）。
• 溢价指数每 5 秒采样一次，取 1 小时内的平均值。

溢价指数的计算方式为：

溢价 = max(影响买入价 − 预言机价格，0) − max(预言机价格 − 影响卖出价，0)
溢价指数 = 溢价 / 预言机价格

影响买入价和影响卖出价是指成交一个固定名义金额所需的平均成交价格。预言机价格由各验证节点计算的主流中心化交易所现货价格的加权中位数得出。

资金费率上限为每小时 4%。

对于 HIP-3 市场中的非加密资产永续合约，溢价指数采用另一种计算方式：

溢价 = (0.5 × (影响买入价 + 影响卖出价) / 预言机价格) − 1

4.3.2 溢价机制

溢价机制的核心作用是使永续合约价格与标的资产的现货价格保持一致。

当永续合约价格高于现货价格时（即市场总体看多），溢价指数为正，资金费率为正。此时多头需向空头支付资金费用。当永续合约价格低于现货价格时（即市场总体看空），资金费率为负，空头需向多头支付资金费用。

资金费率的高低反映了市场多空力量的失衡程度。当单边持仓过度集中时，资金费率会显著上升，激励套利者入场建立反向头寸，从而将价格拉回合理区间。

Hyper Liquid 的资金费率结构中包含一个固定的利率分量（每 8 小时 0.01% 偏向空头），这使得在正常情况下资金费率略偏正值，即多头长期而言需向空头支付少量费用。

4.3.3 资金费率对交易行为的影响

资金费率对交易行为的影响主要体现在以下方面。

第一，套利交易。当 Hyper Liquid 的资金费率与中心化交易所之间存在显著差异时，套利者可以在两个平台之间进行资金费率套利。这种套利行为有助于缩小不同平台之间的价格差异。

第二，持仓成本评估。对于长期持有多头仓位的交易者，正向资金费率构成持续的持仓成本。当资金费率持续偏高时，交易者可能减少多头敞口或转向空头策略。

第三，对 HLP 做市策略的影响。HLP 作为协议内的自动做市商，其双边报价策略需要将资金费率纳入库存管理成本的计算中。资金费率的变化会直接影响 HLP 的做市盈亏。

4.4 费用结构

4.4.1 Taker/Maker 费率

Hyper Liquid 采用基于 14 天加权滚动交易量的等级费率制度。交易量等级每 14 天重新计算一次。

永续合约的费率等级如下。

等级 0（交易量 < 500 万美元）：Taker 费率 0.045%，Maker 费率 0.015%。 等级 1（交易量 > 500 万美元）：Taker 费率 0.040%，Maker 费率 0.012%。 等级 2（交易量 > 2500 万美元）：Taker 费率 0.035%，Maker 费率 0.008%。 等级 3（交易量 > 1 亿美元）：Taker 费率 0.030%，Maker 费率 0.004%。 等级 4（交易量 > 5 亿美元）：Taker 费率 0.028%，Maker 费率 0.000%。 等级 5（交易量 > 20 亿美元）：Taker 费率 0.026%，Maker 费率 0.000%。 等级 6（交易量 > 70 亿美元）：Taker 费率 0.024%，Maker 费率 0.000%。

等级 4 及以上的 Maker 费率为零。Hyper Liquid 不采用负费率（即返佣模式），但设有独立的做市商激励计划，向符合条件的高频做市商支付最高 -0.003% 的返佣。

现货交易的费率结构与永续合约独立，但现货交易量以双倍权重计入交易量等级的计算。

4.4.2 折扣机制（HYPE 持有者）

HYPE 质押者可以享受交易费率的额外折扣。折扣比例与质押数量挂钩，并与交易量等级折扣叠加计算。

质押等级与折扣比例对应如下。质押 10 HYPE 以上（Wood 等级）享受 5% 折扣。质押 100 HYPE 以上（Bronze 等级）享受 10% 折扣。质押 1,000 HYPE 以上（Silver 等级）享受 15% 折扣。质押 10,000 HYPE 以上（Gold 等级）享受 20% 折扣。质押 100,000 HYPE 以上（Platinum 等级）享受 30% 折扣。质押 500,000 HYPE 以上（Diamond 等级）享受 40% 折扣。

折扣以乘法方式作用于基础费率。例如，一个等级 0 的账户若持有 Diamond 等级质押，Taker 费率从 0.045% 降至 0.027%。

此外，使用 USDH 作为抵押品的用户还可享受额外优惠：Taker 费率降低 20%，Maker 返佣提高 50%，交易量计算时额外增加 20% 贡献。

4.4.3 费用分配流程

Hyper Liquid 的费用分配遵循清晰的路径。所有交易费用首先归集至协议收入池。协议收入的 97% 用于在公开市场上回购 HYPE 代币并销毁。剩余 3% 分配给 HYPE 质押者作为奖励。

这一分配机制将交易活动与代币价值直接挂钩。交易量越大，回购销毁量越大，理论上对 HYPE 的通货紧缩效应越强。

对于 HIP-3 市场，交易费用在协议和做市商（市场创建者）之间平分。HIP-3 市场的标准费率为原生永续合约费率的约两倍（Taker 约 0.07% 至 0.09%），其中一半归协议，一半归市场创建者。HIP-3 Growth Mode（2025 年 11 月推出）可将费率降低约 90%，用于激励新市场的冷启动。Growth Mode 要求市场不得与已有的验证节点运营的永续合约市场重叠。

4.5 交易 UI 与 API

4.5.1 网页交易界面功能

Hyper Liquid 的官方网页交易界面提供以下核心功能。

订单类型方面，支持市价单、限价单、止损市价单、止损限价单、止盈市价单、止盈限价单、分批挂单（Scale Order）和时间加权平均价格单（TWAP）。其中 TWAP 订单将大额订单分割为多个子订单，每 30 秒执行一批，最大滑点控制在 3% 以内。

订单选项方面，支持仅减仓（Reduce Only）、即时成交否则取消（IOC）、仅挂单（Post Only / ALO）、止盈（Take Profit）和止损（Stop Loss）。订单有效期支持一直有效至取消（GTC）。

界面功能方面，提供实时订单簿可视化、K 线图与深度图、持仓管理面板、账户权益与保证金概览。用户在同一个界面内可以完成杠杆调整、保证金模式切换、资金划转等操作。

Hyper Liquid 还提供以下第三方交易终端，作为官方界面的功能补充。Insilico Terminal 提供专门的执行界面，支持 TWAP、限价追踪（Limit Chase）和分批订单，并具备可编程快捷键和多账户管理功能。HyperTerminal 是一套开源终端，集成了 TradingView 图表，支持跨多个钱包的连接（MetaMask、WalletConnect 等）。Hyperdrive Trade 提供深度订单簿可视化与多时间框架图表同步功能，延迟低于 200 毫秒。HyperDock 是一个 Chrome 浏览器扩展，以侧面板形式运行，支持市价单、限价单、买卖报价单、止损单以及括号订单（TP/SL 同时设置）。

4.5.2 API 接入方式

Hyper Liquid 为程序化交易者提供多种 API 接入方式，覆盖不同延迟要求和数据深度需求。

REST API。官方 REST 接口分为 Info 端点和 Exchange 端点。Info 端点用于查询市场数据快照、历史数据和账户状态，属于公开接口。Exchange 端点用于所有写入操作，包括下单、撤单、转账等，所有请求需使用 ECDSA 签名认证。单次调用最多可批量提交 39 个订单。速率限制基于交易量动态计算。

WebSocket API。WebSocket 端点（wss://api.hyperliquid.xyz/ws）提供实时数据推送。支持的数据流包括成交数据（Trades）、订单簿数据（l2Book）、K 线数据（Candle）、全市场中间价（allMids）、用户成交明细（userFills）、用户资金费率记录（userFundings）、清算数据（liquidations）和最优买卖报价（bbo）。每个 IP 地址最多支持 1,000 个订阅。数据推送采用先快照后增量更新的模式。

gRPC Streaming API。gRPC 流式接口面向高频交易和做市商场景，通过专用数据提供商（如 Dwellir、QuickNode、HypeRPC）接入。相比 WebSocket，gRPC 提供更多数据流，包括原始区块数据（Blocks）、聚合深度数据（StreamL2Book）、逐笔订单粒度数据（StreamL4Book，包含用户地址、订单 ID、数量、触发条件等信息）和内存池待处理交易（Mempool Txs，仅测试网）。gRPC 使用 Protocol Buffers 序列化协议和 zstd 压缩，带宽占用减少约 70%，吞吐量可达每秒 70 个区块以上。

JSON-RPC API。JSON-RPC 接口用于历史区块查询、投资组合和清算所状态查询以及批量操作。适用于数据回填和历史分析场景。

在实际生产环境中，程序化交易者通常组合使用多种 API：REST 用于下单和查询快照，WebSocket 用于实时行情监控，gRPC 用于对延迟敏感的高频交易场景。