HIP-3 构建者指南：为什么预言机定义影响你的永续市场的命运

当Hyperliquid推出HIP-3时，它从根本上改变了永续合约市场的诞生方式。协议不再将市场上市门槛设在中心化的审批流程之后，而是向合格的构建者开放访问权限——但这种自由也带来了一个陷阱：构建者现在承担运营风险。这一责任的基石始于一个常被低估的决策：你的预言机定义。

自主网上线三个月以来，基于HIP-3部署的市场已累计交易量超过$13 十亿。这一规模的成就绝非偶然。它既反映了协议的创新，也体现了成功驾驭其复杂性的构建者的能力。然而，每一个成功的市场背后，都有一个警示故事——比如2025年12月trade.xyz上的事件，一名攻击者利用非24/7资产的薄弱预言机定义，通过价格操纵，抽走了$13 百万的多头仓位。

本指南将带你了解架构、风险以及经过验证的控制策略，帮助你区分繁荣的市场与陷入清算级联和ADL触发的市场。

理解Hyperliquid的基础架构：预言机定义的基础

Hyperliquid不要求构建者重新发明轮子。它提供了一个两层的基础设施：

HyperCore：一个为永续交易优化的定制Layer 1区块链，能以确定性终结处理20万笔订单每秒。匹配、清算和结算全部在协议层完成——意味着构建者无需从零搭建交易引擎。

HyperEVM：运行智能合约的应用层，兼容现有的以太坊工具链。

通过复用这些基础设施层，构建者可以专注于真正重要的事情：市场定义和运营纪律。原生的Hyperliquid永续市场仍遵循传统的CEX上市流程——验证者投票决定哪些合约被纳入。但HIP-3颠覆了这一模式：任何满足门槛的构建者都可以发起。

要在HIP-3下启动，必须质押50万HYPE代币。前三个市场部署免费；额外的市场需要通过荷兰式拍卖竞价(31小时周期，从前一轮的最终价格的2倍开始)。即使暂停所有市场，质押要求仍持续30天——这不是可选的保险，而是你的责任机制。

作为构建者的角色：两项不同的责任

HIP-3将构建者的工作划分为两个阶段：市场定义和市场运营。

市场定义：从一开始就要做对。你必须明确：

1. 预言机定义：哪个数据源将作为价格锚？你的初始预言机价格(oraclePx)是多少？对于股票永续，是用Pyth吗？对于流动性较低的山寨币，是用CEX的价格喂价吗？一旦交易者入仓，这个决定就是不可逆的。

2. 合约规格：符号、最小订单量、最大杠杆、抵押资产(USDC)，以及将杠杆限制与仓位规模绑定的保证金表。

市场运营：意味着持续的警觉：

• 价格喂价：你需要反复调用setOracle，提交预言机价格。调用间隔必须至少2.5秒；如果你的标记价格(optional)未在10秒内更新，系统会回退到本地订单簿价格。
• 杠杆调整：你绑定保证金表，为不同规模的仓位设置分层杠杆限制。
• 应急控制：你可以调用haltTrading冻结市场、取消所有订单、以当前标记价格结算仓位。

协议设有护栏——标记价格每次变动不能超过±1%，所有价格限制在日初值的10倍以内。但这些护栏不是枷锁。在这些限制范围内，你的选择决定了市场是繁荣还是崩溃。

预言机定义：市场稳定的关键决策点

预言机定义是市场命运的分水岭。它是你首先设定的，也是最难修正的。原因如下。

预言机定义到底意味着什么

HIP-3中的预言机定义涵盖三个层面：

1. OraclePx (必需)：主要价格锚。通常来自你的中继服务器，汇总外部喂价(Pyth、DEX AMM、CEX价格)。这是你的单点故障，一旦中继崩溃或遭遇DDoS攻击，风险骤增。

2. MarkPx (可选)：你提交的自定义标记价格——最多两组——用以计算实际的清算基准。这是拥有专有定价模型的构建者的优势所在，但也是判断失误导致市场崩溃的源头。

3. ExternalPerpPx (必需)：来自多个CEX的永续中间价的加权中位数。作为理性检验，防止你的孤立市场偏离更广泛市场共识太远。

系统最终将这三者合成为一个最终的标记价格：本地订单簿中值、你提交的markPx和externalPerpPx的中位数。如果任何一层失败，系统会级联到下一层；如果全部失败，你的交易将变得盲目。

( 24/7资产与非24/7资产：两种不同的预言机定义

对于24/7资产)BTC、ETH、大部分山寨币###：预言机定义相对简单。Pyth、Chainlink或直接的CEX喂价提供连续、流动性强的价格信号。你的中继会进行汇总。操纵成本高昂，因为识别对数十个外部市场的错价几乎是瞬间完成的。

对于非24/7资产(股票、指数、商品)：预言机定义变得关乎生死。以NASDAQ股票为例，交易时间内，Pyth提供干净的价格。收盘后，没有外部价格。你的预言机定义必须在“真空”中存活。

陷阱在于：非交易时段，你的setOracle机制无法获取真实的市场价格。你只能依赖“收盘价+内部订单簿压力”。但没有外部锚点，内部压力就变成了镜子——价格只反映市场内部的情况，而非资产的真实价值。

协议对价格变动施加±1%/maxLeverage的限制(例如，10倍杠杆→最大波动10%)。在正常交易时间高波动资产上，这合理；但在周末低流动性股票，没有外部价格支撑，10%的波动就足以清空仓位，引发ADL级联。

清算与ADL：预言机定义如何影响级联风险

仓位一旦开立，预言机定义决定何时会被强制平仓。

( 清算触发点

当你的孤立仓位价值低于维持保证金要求时，就会触发清算。检查依据是由你的预言机定义计算的标记价格)，而非任何交易价格。数学表达式为：

清算价格 = ###名义价值 × marginRequirement( / 仓位规模

维持保证金要求是分层的——杠杆越高，保证金越紧，清算越早。你的保证金表将这些层级绑定到你的市场上，因此如果在流动性低的市场上设置了不合理的高杠杆，清算会集中发生。

) 何时清算变成ADL

真正的恐怖在于：当清算订单无法找到买家时。假设你的标记价格显示为$3,000 (由你的预言机定义)，但订单簿深度很薄。清算订单以$2,910成交——差价3%。如果这个差价足够大，使得清算损失超过了交易者的保证金，就形成了“坏账”。

系统不容忍坏账。它会触发ADL ###自动减仓(：在另一方的盈利仓位会被强制平仓，价格以之前的标记价)$3,000(为准，而非当前市场价。盈利被收回以弥补亏损，将损失转嫁给赢家。

从构建者角度看，ADL是一个传染预警。每一次ADL事件都表明你的市场处于压力之下——要么你的预言机定义出了问题，要么你的杠杆设置引入了过多风险到浅薄的订单簿中。

关键参数：为你的市场配置预言机定义和杠杆

你的setOracle实现是一个调优旋钮，具有巨大杠杆。错误会逐级放大。

) 预言机频率与更新规则

你必须每10秒至少调用一次setOracle，否则系统会回退到本地订单簿价格(如果你的喂价更可靠)。大多数构建者在波动剧烈时会每2-5秒更新一次。

但问题在于：每次调用setOracle，标记价格最多只能变动±1%。如果市场条件在一秒内发生5%的变化###比如低市值山寨币或黑天鹅事件(，你的预言机定义就必然变得陈旧。清算者会看到陈旧的价格，进而打击市场。

) 非24/7资产的预言机定义：周末问题

股票和传统资产周末不交易。计划在HIP-3上做股票永续的构建者必须决定：周六早上没有交易所开盘时，如何定义预言机价格？

当前方案：

方案1：保守——在非交易时间暂停交易或清算。Lighter协议和Optium都采用此方案。交易者失去24/7的访问，但市场保持稳定。

方案2：内部定价——用“上次外部价格+内部订单簿”维持运作。这也是trade.xyz在12月事件前的尝试。

方案2暴露了预言机定义的一个关键弱点：±1%/maxLeverage的价格底线变成了风险的天花板。在低流动性股票的周日，即使只有少量大订单，也可能引发10%的价格变动。你的预言机定义必须防止这种情况，但护栏还不够紧。

更优的非24/7资产预言机定义应包括补充锚点：

• Blue Ocean ATS：提供盘后股价。流动性不及正常交易时段，但是真实市场价格，而非内部订单簿估算。
• IG周末CFD报价：提供“预期开盘变动”信号。结合上次收盘价+内部价格，为你的预言机定义争取一线生机。

这些补充不是取代严谨预言机设计，而是增强它。你的预言机定义应为：“交易时段用Pyth，非交易时段用上次Pyth收盘价调整后的Blue Ocean ATS中值+内部订单簿压力，限制在±X%以内。”

预言机风险控制：实时监控价格喂价稳定性的策略

这里是理论与操作的结合。你的预言机定义的好坏，取决于监控系统。

( 价格喂价故障检测

你的中继是单点故障源。如果中继崩溃或网络中断，setOracle会停止触发。10秒内，系统会回退到纯订单簿价格。对于流动性强、价差紧的市场，这还可以接受；否则就是陷阱。

行动方案：

• 一级预警：喂价中断超过2.5秒。立即检查中继节点状态，切换备用基础设施，发布状态报告。
• 二级预警：喂价中断超过10秒。调用setOpenInterestCaps冻结新仓位。现有仓位仍可平仓。这可以防止级联清算，同时你重建预言机通道。

) 预言机脱锚：预言机定义偏离

即使中继在线，预言机价格也可能远离实际。这发生在：

• Pyth喂价略微滞后###高峰期拥堵时###。
• 内部订单簿中值偏离补充锚点。
• 外部CEX价格###在externalPerpPx中使用(，变动快于你的更新。

定量定义脱锚：

• 阈值A：|oraclePx - externalPerpPx| > 2%
• 阈值B：|markPx - 本地订单簿中值| > 1%
• 阈值C&D：持续>5秒的偏离

行动方案：

• 一级：触发2个以上阈值，调用setOpenInterestCaps，限制新仓增长。
• 二级：逐步调整保证金表，降低最大杠杆层级。启用setOracle的±1%限制作为安全措施。
• 三级：持续执行二级措施并发出警报。偏离持续超过30秒时，最后手段调用haltTrading。

) 订单簿退化：检测市场深度不足

流动性可能在预言机未失效的情况下消失。监控指标：

• 深度区间(±x%)：在距离中值x%的范围内的订单总量。典型值：±0.5%深度。
• 价差：bestAsk - bestBid。健康：<0.1%。危险：>1%。
• 激进成交量：在Δt秒内的吃单成交量。如果超过深度区间，说明市场可能出现问题。

当深度骤降而激进成交量激增时，清算订单会出现滑点。这是你提前降低持仓上限，避免ADL级联的信号。

非24/7资产：市场关闭期间的预言机定义

让我们深入具体的“噩梦场景”：周五晚上做股票永续。市场在东部时间下午4点收盘。你的构建者配置的预言机定义必须撑过周末。

( 2025年12月Trade.xyz崩盘事件

2025年12月14日，攻击者利用了这个场景。他们在市场流动性极低时，建立了XYZ100)纳斯达克-100指数永续合约###的空头仓位。攻击过程：

1. 非交易时间仓位：收盘后，外部价格锚点少，订单簿稀薄，造成大量卖压。
2. 预言机定义失效：内部标记价格(基于有限的内部交易+最后外部价格)偏离向上，超出买方存在的范围。
3. 清算级联：多头仓位在虚高价格被强制平仓，清算订单进一步打压市场。
4. ADL级联：系统强制平仓盈利的空头仓位###包括攻击者(，在陈旧的标记价下，差距巨大，导致ADL事件不断。

根本原因：非24/7资产的预言机定义过于宽松。10%的杠杆价格上限听起来很死板，直到你意识到这意味着股票只有2-3%的实际变动空间。

) 改进的非24/7资产预言机定义

应包括：

1. 交易时间内的主要锚点：Pyth或交易所喂价。
2. 非交易时间的补充锚点：Blue Ocean ATS或IG CFD报价，预示开盘缺口。
3. 内部理性检验：如果内部订单簿中值偏离补充锚点超过X%，触发警报并降低杠杆。
4. 非对称风险管理：交易时间允许10倍杠杆，非交易时间降低到2-5倍最大杠杆，减少在预言机受限时的清算级联风险。

构建你的风险监控面板：价格、深度和仓位监控

专业构建者同时操作三个监控渠道：

( 渠道1：价格端指标

每1-2秒追踪预言机健康：

• 喂价延迟)距离上次setOracle调用的时间(
• 价格偏离外部基准
• 限制突破)价格在±1%范围内持续$13M

渠道2：订单簿指标

每5-10秒监控深度和价差：

• ±0.5%、±1%、±2%的深度
• 买卖价差趋势
• 激进买卖成交量的相关性

激进成交量高+深度骤降=潜在清算信号。

渠道3：仓位指标

每小时追踪持仓总量和集中度：

• 总名义持仓与24小时成交量比率(比率上升=投机模式)
• 最大仓位占用保证金的比例
• 多头与空头的未实现盈亏占保证金的比例

当极端价格下，主导仓位的盈亏超过保证金的80-90%，任何市场震荡都可能触发ADL。

大多数构建者以被动响应为主——触发警报后采取行动。高级构建者会自动化响应：

• 喂价中断超过10秒→自动将持仓上限降低50%
• 深度崩溃+激进成交量激增→自动降低杠杆层级
• 主导仓位盈亏超过保证金80%→触发警报，考虑暂停市场

从预言机定义到市场稳定：构建者的责任框架

HIP-3赋予构建者自主权，也赋予他们责任。

如果市场出现故障——无论是预言机定义不当、杠杆过高，还是监控不足——验证者可以投票撤销你的50万HYPE质押。协议不会区分恶意与无能，只会看结果：仓位是否正确平仓？预言机价格是否正确锚定？市场是否稳定？

构建者的未来之路是通过标准化实现责任：

1. 公布你的预言机定义：详细披露数据源、更新频率和备用逻辑。透明度建立信任，也能在崩盘前暴露缺陷。

2. 实现证明系统：每次调用setOracle时，生成证明(数据源输入、计算步骤、输出)。签名并将其提交到链上Merkle树，每小时公开一次。这允许公众审计你的定价决策。

3. 持续监控：建立实时仪表盘，追踪价格、深度和仓位健康。设置自动断路器，在压力尚未爆发前降低持仓上限和杠杆。

4. 谨慎设计非24/7资产：如果你要推出股票永续，使用补充预言机锚点###Blue Ocean ATS、CFD报价###和低杠杆策略(，学习trade.xyz在12月崩盘中的教训。

5. 建立升级流程：明确何时何地调用haltTrading。切勿将其视为随意的操控杆——它是市场的紧急刹车。

HIP-3的创新不在于让部署变得无阻，而在于使部署标准化——实现准入、运营和责任的统一。市场能否存活，取决于你多么严谨地落实预言机定义、监控价格喂价、以及对早期预警信号的响应。

) 数十亿的构建者部署交易量证明了机会，trade.xyz的事件揭示了风险。你的成功取决于：将预言机定义视为技术核查项，还是作为决定市场运营与清算农场的根本承诺。

如需持续的安全支持、审计准备和风险监控基础设施建设，建议聘请BlockSec等专业公司，帮助将这些原则转化为生产系统。咨询成本远低于一次精心策划的攻击可能带来的损失。