深入探讨HIP-3：以构建者为中心的视角博客

加密货币支付合规手册：业界首个加密货币支付综合合规指南。下载报告下载

2026年1月18日

深入探讨 HIP-3：以构建者为中心的视角

Hyperliquid 改进提案 3 (HIP-3) [1] 引入了一个根本性的变化，即在 Hyperliquid 上创建和扩展永续市场的方式。通过向第三方构建者开放市场上市流程，HIP-3 将上市从一种可自由决定的、平台控制的行为转变为一种协议级别的、基于规则的接口。

自从在主网上部署以来，构建者部署的市场在大约三个月内产生了超过 130 亿美元的交易量，这表明 HIP-3 可以显著提高市场扩展的可扩展性和灵活性。然而，这种转变不仅仅是权力下放；它还重新分配了责任。以前由中心化平台运营承担或减轻的风险现在直接由构建者承担。

因此，HIP-3 的核心问题不再是市场是否可以启动，而是它是否可以长期安全运行。本报告从以构建者为中心的角度分析 HIP-3，重点关注市场的定义和运营方式、构建者面临的风险，以及如何减轻这些风险，特别是与预言机相关的风险。

0x0 背景

Hyperliquid 的架构 [2] 通过将执行和风险基础设施与市场定义分离来脱离此模型。它的双层设计包括：

• HyperCore，一个专门构建的 Layer 1 区块链，针对衍生品交易进行了优化，提供统一的撮合、清算和结算。
• HyperEVM，一个与 EVM 兼容的应用层，支持可扩展的逻辑和构建者交互。

由于执行和清算在协议级别统一执行，因此新市场可以重用相同的核心基础设施，而无需重新实现关键的安全逻辑。但是，定价无法完全标准化。预言机输入、杠杆设计和运行时操作不可避免地因市场而异，这使得定价成为去中心化与风险相遇的主要接口。

尽管有这种架构，Hyperliquid 原生永续市场的上市过程（也称为验证者运营的 perps）仍然类似于传统的 CEX 方法。新合约的上市主要由核心团队推动，而退市则通过验证者投票决定。

引入 HIP-3 是为了通过启用构建者部署的永续市场来去中心化此上市过程。它通过允许构建者定义和运营市场，同时协议强制执行硬性执行和风险边界，从而正式隔离了市场定义和协议强制执行之间的关系。因此，HIP-3 代表了迈向完全去中心化 perp 上市流程的关键里程碑。

0x1 构建者责任：定义和运营

根据 HIP-3，构建者承担市场生命周期管理的端到端责任。在本节中，我们首先介绍市场启动工作流程，然后重点介绍直接决定生产中市场稳定性的运营杠杆。

0x1.1 市场启动流程：定义和运营

根据 HIP-3，启动市场不是一个单一的行动。如下图所示的完整市场启动工作流程所示，它是一个跨越两个不同阶段的过程：市场定义（步骤 1 到 4）和市场运营（步骤 5）。

在市场定义阶段，构建者必须首先在主网上质押 500,000 个 HYPE。满足质押要求后，构建者可以部署一个永续 DEX，该 DEX 形成一个独立的交易域，具有自己的保证金系统、订单簿和部署者控制的设置。在 DEX 级别，构建者选择一种报价资产，用作该 DEX 上所有市场的抵押品。所选的报价资产必须保持无需许可的状态，因为失去此状态将禁用相应的 DEX。然后，构建者定义核心市场参数，包括预言机规范、合约参数（如符号和杠杆限制）以及保证金表。前三个市场可以直接部署，而其他市场则需要通过荷兰式拍卖获得插槽。

荷兰式拍卖：每轮持续 31 小时，每次的起始价格是前一次最终价格（上次中标价格/最低价格）的 2 倍。

一旦市场上线，构建者就进入市场运营阶段。此阶段涉及通过 setOracle 接口持续更新预言机价格，维护杠杆和保证金配置，监控流动性和未平仓头寸，并在必要时执行紧急操作，例如停止交易和结算头寸。

在实践中，HIP-3 下最严重的故障并非发生在市场定义期间，而是发生在压力市场条件下长期运营期间。重要的是，构建者的责任不会在停止市场后立即结束。只有在所有市场结算后才能取消质押，并且在强制取消质押期间，质押仍然可以被罚没。

0x1.2 关键关注领域：定价和偿付能力

构建者在市场定义和市场运营中面临两个相关的关注领域：预言机配置和价格形成，以及压力下的市场偿付能力。这两个领域紧密相关，因为定价失败可能会通过协议级别的风险控制迅速蔓延到偿付能力压力。

1. 预言机配置和价格形成

Hyperliquid 定义了两个价格：

• 预言机价格：主要外部交易所现货中间价的加权中位数，旨在独立于 Hyperliquid 的内部市场数据，主要用于锚定资金费率。
• 标记价格：从包括预言机价格和本地市场数据在内的多个输入中得出的内部风险价格，用于未实现的损益（利润和损失）和风险控制。

简而言之，预言机价格锚定资金费率，而标记价格驱动保证金检查、清算以及 TP（止盈）和 SL（止损）触发。

在 HIP-3 下，预言机价格和标记价格的角色没有改变，但计算机制发生了变化：

a) setOracle 的输入

• oraclePx（必需）：与 HyperCore 中的定义相同。
• markPx（可选）：0–2 个外部计算的标记价格候选值。
• externalPerpPx（必需）：一个参考值，以防止标记价格突然偏差。

构建者通常部署中继节点来提供价格：oraclePx 是从多个外部来源计算得出的，markPx 由中继器使用自定义算法计算得出，externalPerpPx 来自多个 CEX 的 perp 中间价的加权中位数。

b) 实际标记价格

• 计算 本地标记：median(best bid, best ask, last trade)。
• 将 本地标记 和 markPx（0–2 个值）放在一起，取 中位数 以获得新的标记价格。

c) setOracle 约束

• 更新频率：调用之间至少 2.5 秒；如果 markPx 在 10 秒内未更新，它将回退到 本地标记价格。
• 幅度限制：markPx 每次更新最多可以更改 ±1%；所有价格都限制在当日起始价格的 10 倍以内。

为什么资产类型对 HIP-3 中的定价很重要？

根据 HIP-3，可以为任何类型的资产启动永续市场。这些资产通常可以分为 24/7 资产（全天候可交易）和非 24/7 资产（仅在特定市场时段可交易，这些时段之外没有现货交易）。交易时间的差异从根本上决定了价格的来源和维护方式。

对于 24/7 资产（例如，BTC），可以通过聚合来自 CEX、DEX 或受信任的预言机服务的数据来持续获得相对稳定的价格。

对于非 24/7 资产（例如，股票），充足的流动性和可靠的外部市场价格仅在官方交易时间内可用。为了让此类资产在 HIP-3 上持续交易，必须在非市场时段使用单独的定价机制。

以 trade.xyz 上的股票 perp 市场为例：

• 在市场时段，稳定的预言机价格由 Pyth 等外部预言机服务提供。
• 在非市场时段，价格根据资产的最后收盘价进行调整，并结合来自订单簿的内部买/卖压力。标记价格被限制在最后收盘价的 ±1 / max_leverage 范围内（例如，特斯拉：10 倍杠杆 → ±10%）。

2. 压力下的市场偿付能力

Hyperliquid 采用两种机制，清算和 ADL（自动去杠杆化），来维持市场偿付能力。在 HIP-3 下，清算和 ADL 在很大程度上遵循 HyperCore 的设计。主要区别在于协议级别的限制：HLP（Hyperliquidity Provider），即协议金库，不能接管 HIP-3 市场中的风险头寸。因此，在 HyperCore 中可以在市场清算和 ADL 之间吸收头寸的中间金库缓冲区在 HIP-3 中不存在。

鉴于这种清算到 ADL 路径在压力市场条件下的重要性，我们将在下面详细审查清算和 ADL。此处讨论的所有偿付能力机制都假定隔离保证金，这是 HIP-3 市场中当前唯一支持的保证金模式。

a) 清算

当头寸的净值（隔离头寸价值）不足以满足维持保证金要求时，将触发清算，它将变为可清算的。所有与清算相关的检查均基于标记价格，而不是基于特定的执行价格。

清算价格公式定义如下：

其中：

• side：多头头寸为 1，空头头寸为 -1
• $l$ 是维持保证金率

MAINTENANCE_LEVERAGE 的值由与头寸对应的保证金等级确定。从该等级中，获得维持保证金率 mmr：

配置保证金等级时，应用与清算价格下头寸名义价值对应的等级的 mmr。

• margin_available（隔离）：isolated_margin - maintenance_margin_required

一旦某个头寸变为可清算的，系统首先尝试通过订单簿上的市价订单来平仓。如果执行成功地将风险带回到安全范围内，则任何剩余保证金将返还给交易者。

但是，在订单簿深度不足或价格缺口的情况下，实际平均执行价格可能比标记价格差得多，从而导致 “清算缺口”。

隔离头寸价值是指当前标记价格下隔离头寸的净值，表示在考虑未实现损益后分配给该头寸的保证金。

b) ADL（自动去杠杆化）

在极端情况下，ADL（自动去杠杆化）机制充当最终保障。

当隔离头寸价值变为负值时，将触发 ADL（自动去杠杆化）。系统按损益和杠杆对盈利的对手方进行排名，然后以之前的标记价格强制减少或平仓这些头寸（触发 ADL 之前的先前记录的标记价格）。通过使用获胜方的利润来抵消赤字，协议保持偿付能力，并且不会产生坏账。

排序索引计算如下：

此处，notional_position 是指在当前标记价格下头寸的绝对市场价值，计算为 |position_size| × mark_price。account_value 表示该账户在标记价格下的权益，即抵押品价值加上未实现损益。

示例：

• 在触发 ADL 之前，系统的 标记价格 = 3,000。
• 由于 setOracle 约束，新的标记价格只能更新为 2,970 (−1%)。
• 但是，订单簿的买方非常薄弱。在清算市价订单冲击订单簿后，实际平均执行价格 = 2,910（相对于 3,000，−3%）。
• 多头头寸的损失以 2,910 结算，可能会使隔离头寸价值降至零以下并产生缺口，从而触发 ADL。
• 然后，ADL 选择反向方（盈利的空头）头寸，并以之前的标记价格 = 3,000 强制减少/平仓这些头寸，从而将缺口转移到 “获胜方被动地赚得更少”。

0x2 构建者风险概览

在 HIP-3 下，风险不再是抽象的或纯粹是理论上的构建者。通过质押和验证者管理的罚没，运营失败和错误配置可以直接转化为经济处罚。因此，了解如何触发罚没，以及哪些类型的构建者行为可能导致罚没，已成为构建者风险模型的中心。因此，本节首先解释作为问责制框架的罚没机制，然后分析 HIP-3 下构建者风险的两个主要来源。

0x2.1 罚没机制和问责制

HIP-3 通过质押金和验证者管理的削减来加强问责制。罚没完全基于结果。 Hyperliquid 不区分恶意行为、运营错误、私钥泄露或第三方依赖项失败。

质押要求：在主网上，构建者必须保持 50 万个 HYPE 的质押金。即使构建者停止了所有市场，他们也必须继续维持 30 天（责任不会因为停止交易而立即消失）。

如果构建者的行为导致无效状态、长时间停机或严重的性能下降，则可能触发罚没。根据严重程度，罚没的范围从部分质押金减少到全部质押金烧毁。这种设计使构建者在经济上对他们市场的全部运行时行为负责。

罚没百分比由验证者投票决定，并参考上限：

• 无效状态/长时间停机：高达 100%
• 短时间停机：高达 50%
• 性能下降：高达 20%

被罚没的代币会被烧毁，而不是重新分配。

在 HIP-3 下，构建者风险主要来自两个来源：内部参数配置错误 和 外部预言机依赖项。以下各节将详细检查这两个来源，并解释它们如何转化为罚没结果。

0x2.2 内部参数配置错误的风险

配置错误风险包括低流动性市场中的过度杠杆、不正确的保证金表设计、突然的参数更改导致大量头寸可清算，以及不当使用紧急控制（例如停止交易）。

这些风险在很大程度上是确定性的和可预防的。只要有足够的谨慎、审查和运营纪律，就可以避免大多数内部配置错误。虽然重要，但它们不是 HIP-3 下最具结构性挑战的风险。

1. setOracle

预言机价格通常来自构建者的中继服务器，这会引入中心化风险。如果私钥泄露或中继服务器遭受 DDoS 攻击，则市场的预言机价格可能会受到恶意操纵或长时间保持发散状态。

2. haltTrading

构建者可以通过 haltTrading 取消市场中的所有订单，并以当前的标记价格平仓。此操作应谨慎使用。例如，如果检测到市场受到攻击者的恶意操纵，并且调用 haltTrading 以按标记价格平仓，则它可能直接实现攻击者的未实现利润（否则攻击者可能难以找到足够的反方向订单），并且还可能导致坏账。

3. setMarginTableIds & InsertMarginTable

• InsertMarginTable：定义一个新的保证金表，指定一类资产的保证金要求和最大杠杆。
• setMarginTableIds：将市场绑定到指定的 marginTableId。

对于低流动性/市场做市不足的市场，将最大杠杆设置得过高会增加触发 ADL 的可能性。

突然切换 marginTableId 相当于修改用户头寸的维持保证金率，这可能会同时将许多账户从安全转为可清算，从而触发级联清算。

4. setMarginModes

HIP-3 目前仅允许隔离保证金，并且将来可能会支持跨保证金。在同时托管高流动性和低流动性市场的 DEX 中，跨保证金可能会导致风险蔓延，其中非流动性市场的损失会蔓延到流动性市场。因此，在官方团队提供成熟的解决方案之前，不建议构建者引入跨保证金。

0x2.3 来自外部预言机依赖项的风险

对于 24/7 资产，主要风险在于 外部预言机服务的准确性和稳定性，以及前面讨论的 中继服务器的中心化风险。这些外部依赖项中的任何中断、延迟或操纵都可能直接影响定价完整性和下游风险控制。

对于 非 24/7 资产，风险面显着扩大，并且主要集中在 如何在非交易时段获取或计算预言机价格。

以 trade.xyz 为例，在非市场期间，价格来自 上次可用的外部预言机价格 和 内部市场价格 的组合。在周末，股票永续市场经常遭受流动性严重降低的影响——订单簿变得稀薄，做市商减少报价——而没有外部预言机价格可提供锚定。即使对价格变动施加了硬性上限（例如，1 / max_leverage），此约束对于低波动性资产仍然可能过于宽松。此范围内的价格变动仍然可能触发 大规模清算甚至 ADL 事件。

2025 年 12 月 14 日，trade.xyz 上的 XYZ100-USDC 市场（一种跟踪 NASDAQ-100 的永续合约）遭到操纵。一名攻击者做空了 398 个 XYZ100（名义敞口约为 1000 万美元 USDC），导致严重的价格脱钩。大量的多头头寸被清算，并且清算本身进一步压低了价格，最终导致多方清算约 1300 万美元 USDC。

这可能是周末“增长模式”制度下的首次此类行动。有人猛烈冲击市场，在一分钟内将 XYZ100 的价格下跌超过 3%，并清算了约 300 万美元的头寸 pic.twitter.com/XttBHfTB0D

— bart.hl (equity perps era) (@bartdothl) 2025 年 12 月 14 日

另一方面，在非交易时段，由于缺少连续且外部锚定的 预言机价格，市场被迫依赖由“上次外部价格 + 内部订单簿”形成的 受约束的内部定价范围（例如，trade.xyz 将最大波动限制为 1/max_leverage）。

最关键的风险出现在 市场重新开放过渡 时。外部市场可以突然提供 清晰且权威的参考价格。如果此价格相对于内部非交易时段定价存在显着差距，则系统将面临两条不利的路径：要么价格保持 受限，导致外部公允价值和可交易价格之间存在严重偏差，要么系统迅速切回外部锚定，从而触发 突然的重新定价。这两种情况都可能在短时间内集中清算压力，并且在极端情况下，会导致 ADL 事件激增。

0x3 构建者风险控制措施

仅靠配置纪律无法消除风险。最有效的缓解策略是侧重于减少对预言机依赖项失败的风险敞口。

0x3.1 选择稳定的预言机

对于 股票等非 24/7 交易资产，主要挑战在于 在非市场时段进行定价。在这些时段，稳定且外部锚定的价格参考非常稀缺，从而使市场更容易受到操纵或在流动性不足的情况下的内生漂移的影响。

目前，行业方法通常分为两个方向：

• 暂停预言机更新并限制在非市场时段进行交易。 例如，Lighter 协议仅在基础市场关闭时接受仅减少订单。Ostium 等协议进一步降低了非市场时段的最大杠杆，并强制平仓超过新限制的头寸。
• 采用“内部定价”机制，如 trade.xyz 上所示，该协议在外部数据不可用时，通过依赖内部流动性和定价算法，继续在非交易时段运行。

这两种方法反映了 安全性 和 用户体验 之间的根本权衡。第一种方法优先考虑严格的风险控制，但会显着降低交易连续性和用户体验。第二种方法保留了持续交易，但由于缺少外部参考，增加了内部价格与资产基本价值相背离的风险。

在停盘期间，协议定价应避免完全退化为纯粹的内部价格。相反，引入外部参考锚定可以减少脱钩和缺口风险。可能的参考包括：

• Blue Ocean ATS。作为盘后/隔夜交易场所，它可以提供一定程度的持续价格参考在收盘期间（比“上次收盘价”更及时），有助于生成收盘期预言机价格或作为脱钩的监控基线。
• IG 周末差价合约报价。周末 CFD 报价可以提供反映“周末市场预期”的替代价格信号，适合作为收盘期间的外部锚定或监控比较，以帮助提前检测到“开盘缺口”的可能方向和幅度。

这些来源的共同特征是它们能够在非市场时段提供价格信号。但是，它们与基础现货市场不共享相同的市场结构，因此更适合作为锚定、参考或预警信号，而不是无条件替代品。

0x3.2 价格验证

在 HIP-3 下，预言机价格来源于 构建者运营的中继服务器，这引起了对 中心化 的担忧。为了缓解这种情况，鼓励构建者实施 价格验证框架，该框架允许任何用户或机构在链下验证定价的正确性和公平性 — 类似于 RedStone，它将价格与数据源和加密证明打包在一起。

1. 数据透明度

• 算法规范：公开披露定价算法和计算逻辑。
• 数据源列表：所有来源都应该是公开的、不受构建者操纵的，并使用详细的接口和参数进行记录。
• 价格提交规则：setOracle 的权限、触发条件、更新频率和波动性约束。

2. 价格证明

对于每个 setOracle 调用，生成一个包含以下内容的相应证明：

• 输入：来自每个数据源在采样时间戳时的原始（或标准化）响应。
• 计算：每个计算步骤的可重复中间值。
• 输出：链上提交的预言机价格。

每个证明都序列化为 proofHash，然后由 oracleUpdater 签名。

3. 链上承诺

• 在 Merkle 树中维护 proofHash 条目的顺序列表。
• 定期（例如，每小时或每天）在链上发布 MerkleRoot。

4. 验证

• 提供开源工具或网页，用户可以在其中输入时间范围或 setOracle 交易哈希
• 验证签名、时间戳和 MerkleRoot 等。
• 使用公共算法重新计算预言机价格以进行比较。

0x3.3 风险监控

价格验证使 setOracle 可重新计算 和 可审计，从而确定价格馈送是否值得信赖。但是，它无法防止实时市场恶化。馈送中断、价格偏差和流动性下降 — 当与大量未平仓合约 (OI) 结合使用时 — 很容易将局部异常升级为 系统性风险，如级联清算甚至 ADL 事件。

因此，必须 尽早 检测到市场异常并将其转换为 可观察的信号，并在一段时间内处理以将风险控制在可管理的范围内。

为了使监控可操作而不是分散，我们将信号组织成三层，每层映射到不同的故障模式和响应优先级。

• 价格端监控 检测可能使风险控制失效的预言机馈送故障和脱钩，因此被视为最高优先级，通常通过中继器故障转移、未平仓合约上限和杠杆降低来解决。
• 订单簿端监控 捕获流动性撤回和欺骗性深度，这会放大清算滑点和缺口风险，因此干预措施侧重于限制增量风险敞口并在脆弱性增加时强制去杠杆化。
• 头寸端监控 跟踪未平仓合约的快速建立和单边集中，这会使市场容易受到级联的影响，并且通常比价格和流动性信号的优先级低，主要用作早期预警层，为更严格的上限和更高的警报提供信息。

以下各节将依次详细介绍每一层，以及相应的监控点和建议的操作。

1. 价格端监控

a) 预言机馈送故障

指标：

• 使用链上可观测值来判断馈送是否停滞：

阈值：

• 级别 1: ( ∆t > 5s ) — 中继器进程可能已停滞或阻塞
• 级别 2: ( ∆t > 15s ) — 链上价格可能严重脱钩并越来越受市场驱动

操作：

• 级别 1：执行中继器运行状况检查、切换到备份中继器，并发出带有运行状况诊断的警报
• 级别 2：调用 setOpenInterestCaps 以降低 OI 上限

b) 价格脱钩

指标：

• 信号 A (d1)：标记价格和预言机价格之间的偏差。

• 信号 B (d2)：订单簿中间价和预言机价格之间的偏差。

• 信号 C (d3)：标记价格和中间价之间的偏差。

• 信号 D (ext_diff)：预言机价格和外部参考价格之间的偏差。

阈值逻辑：

• 级别 1：A、B、D 中至少有 2 个超出阈值。
• 级别 2：A、B、C、D 中至少有 3 个超出阈值 X 秒。

操作：

• 级别 1：通过 setOpenInterestCaps 降低 OI 上限。
• 级别 2：逐步更新保证金表以按等级降低最大杠杆，并在中继器上启用钳制机制。
• 级别 3：级别 2 条件下的持续警报。然后，构建者评估是否调用 haltTrading。

2. 订单簿端监控

a) 流动性撤回

指标：

• depth_band(±x%)：在中间价 ±x% 范围内的可用订单簿流动性。
• spread = bestAsk - bestBid：用于衡量价差扩大的价差。
• aggressiveVolume_Δt：Δt 内的吃单方交易量（按交易方汇总）。
• impact_ratio：市场脆弱性的指标（更高的值表示更大的价格影响脆弱性）。

风险模式：

• depth_band 减少，而 spread 和 impact_ratio 增加。

操作：

• 级别 1：通过 setOpenInterestCaps 设置 OI cap = current OI，限制增量头寸。
• 级别 2：通过 setMarginTableIds 强制去杠杆化，同时清算 高杠杆、高风险头寸。

b) 欺骗性流动性

风险模式：

• depth_band 突然飙升，然后在短时间内崩溃。

操作：

• 级别 1：调用 setOpenInterestCaps 将 OI cap = current OI。
• 级别 2：如果 与严重脱钩相结合，请考虑停止市场。

3. 头寸端监控

头寸端监控不尝试 预测价格方向。相反，它识别从 平衡的交易活动 到 单边头寸积累 的过渡。当 OI 快速积累时，头寸变得高度集中，并且多数方的损益达到极端水平，即使是轻微的外生冲击也可能触发清算级联或 ADL 事件。

因此，与价格端和订单簿端干预相比，头寸端操作通常具有 较低的优先级。

a) 短期 OI 过高

指标：

• OI_notional：未平仓合约名义价值。
• Volume_24h_notional：24 小时名义交易量。

快速增加的比率表明从主动换手转向投机性头寸积累，并且通常先于剧烈的波动。

操作：

• 级别 1：超出阈值时触发警报。

b) 多数方损益

多数方 是指在观察窗口内拥有更多头寸持有者的一方（多头或空头）。

指标：

• avgEntry_major：多数方头寸的平均入场价格。
• size_major：多数方的总头寸规模。
• equity_major：多数方的总权益。

多数方的损益及其比率定义如下：

操作：

• 级别 1：警报超出阈值。
• 级别 2：如果持续存在，请考虑调用 setOpenInterestCaps 以降低 OI 上限。

0x4 结论

HIP-3 的核心叙述很简单。它将市场上市从少数人控制的可自由决定的过程转变为 任何符合条件的构建者在满足要求后都可以调用的协议级别能力。通过质押，构建者可以在 HyperCore 上启动自己的 perp DEX，免费上市初始市场集，并通过拍卖获得其他插槽。这使市场扩张从等待批准转变为 基于规则的、无需许可的扩展。 同样清楚的是，HIP-3 并没有消除风险。它重新定位和重塑了风险。以前由平台级风险控制吸收的责任现在主要由构建者通过他们的输入和运营质量来承担。这包括通过setOracle进行的 Oracle 定价和更新频率、markPx的选择和约束、通过保证金表的分层杠杆设计、非 24/7 资产的场外定价范围，以及诸如haltTrading之类的强大控制，这些控制既可以控制损失也可以放大损失。在流动性不足的情况下，配置错误或运营失败可能会被放大为清算级联、缺口损失，并最终导致 ADL 事件。问题不再是“可以列出某个市场吗？”，而是“它在上市后能保持稳定吗？”

在协议层面，Hyperliquid 通过将权限转换为可问责的权限来解决这种风险重新分配。质押，加上验证者管理的削减，为构建者的错误操作建立了明确的经济后果。对定价和杠杆的约束，包括钳制、更新间隔、波动率限制和隔离保证金要求，旨在将最危险的尾部风险控制在可管理的范围内。在此框架中，HIP-3 的价值主张变得清晰：通过开放进行扩展，通过约束实现安全，以及通过可验证性和问责制实现长期可持续性。

HIP-3 并未使列表更自由。它使它们更加标准化，可部署、可操作和可削减。这种标准化能否大规模运作最终取决于 Oracle 设计、杠杆和风险参数以及运行时监控的真实质量。如果你正在 HIP-3 之上设计市场准入规则、参数模板、警报系统或紧急工作流程，或者你需要审计和持续安全支持，请随时通过 contact@blocksec.com 联系 BlockSec。

参考

[1] https://hyperliquid.gitbook.io/hyperliquid-docs/hyperliquid-improvement-proposals-hips/hip-3-builder-deployed-perpetuals

[2] https://hyperliquid.gitbook.io/hyperliquid-docs

关于 BlockSec

BlockSec 是一家全栈区块链安全和加密合规提供商。我们构建产品和服务，以帮助客户执行代码审计（包括智能合约、区块链和钱包）、实时拦截攻击、分析事件、追踪非法资金以及满足 AML/CFT 义务，涵盖协议和平台的完整生命周期。

BlockSec 在著名会议上发表了多篇区块链安全论文，报告了 DeFi 应用程序的多个零日攻击，阻止了多次黑客攻击，挽救了超过 2000 万美元，并保护了数十亿美元的加密货币。

• 官方网站: https://blocksec.com/

• 官方 Twitter 账号: https://twitter.com/BlockSecTeam

• 🔗 BlockSec 审计服务 : 提交请求

• 🔗 Phalcon 安全 APP: 预约演示

• 🔗 Phalcon 合规

注册以获取最新更新

订阅

\ \ 2026 年 1 月 13 日\ \ 深入分析：Truebit 事件\ \ 2026 年 1 月 8 日，以太坊上的 Truebit 协议遭到利用，造成超过 2600 万美元的损失。此博客提供了对该事件的深入技术分析。 \ \ 2025 年 12 月 30 日\ \ 通讯 - 2025 年 12 月\ \ 2025 年 12 月，DeFi 领域遇到了三起重大安全事件，导致总损失约 1970 万美元。 Yearn Finance 因其 yETH 池和遗留合约中的漏洞而面临近 1000 万美元的损失。 Trust Wallet 的 Chrome 扩展程序遭受了恶意后门攻击，导致损失约 700 万美元。 Ribbon Finance 由于不正确的访问控制而损失了 270 万美元。 \ \ 2025 年 12 月 23 日\ \ 使用 Phalcon Explorer 追踪 Plasma 上的稳定币支付\ \ Phalcon Explorer 现在支持 Plasma，这是专为稳定币设计的 L1。你可以在世界上第一个稳定币原生区块链上分析支付流程、调试智能合约并追踪资金流动。立即在 Plasma 上访问全面的交易分析、实时监控和高级调试工具。

• 原文链接： blocksec.com/blog/deep-d...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～