撰文：Blocksec
HIP-3（Hyperliquid Improvement Proposal 3） 上线主网已经约 3 个月，自推出以来第三方自定义市场累计成交量已突破 130 亿美元，这意味着「上新」这件事正在从交易所内部流程，变成一种可被外部开发者直接调用的基础设施能力。
在中心化交易所里，「上新」天然是一项平台权力：哪些标的能交易、何时上线、参数怎么定，基本都由运营与风控流程决定。即便在链上，永续合约这种重基础设施的品类也常被少数团队的部署与治理节奏所约束。
HIP-3 的革新在于把这件事从「平台审批」改成「接口开放」：只要满足条件，第三方就能在同一套交易与清算底座上部署新的永续合约市场，让中心化的上新权力被系统化地外包给生态。这一改进不仅降低了创新门槛，还加强了市场的可扩展性。然而，开放接口带来的潜在安全风险不容忽视，如何确保这些市场的运营合规且无恶意行为，仍是 HIP-3 设计中需要严格审视的关键问题。
0x1 Hyperliquid：HIP-3 的基座
Hyperliquid 是运行在自有链上的永续交易基础设施。对 HIP-3 而言，最关键的一点是：撮合、清算与结算由协议底座统一提供，市场能力可以复用，而不是从零搭一套交易系统。
Hyperliquid 采用了双层架构:
HyperCore：为合约交易优化的定制化 L1 区块链，每秒可处理 20 万笔订单，并具备确定性最终性。
HyperEVM：应用层，可运行智能合约，兼容 EVM 。
Hyperliquid 的原生 perp 市场（validator-operated perps）在上架上仍更像传统 CEX 的流程：官方根据社区的意愿自行上架永续合约；而下架则由验证者节点投票决定。
The Hyperliquid protocol will support builder-deployed perps (HIP-3), a key milestone toward fully decentralizing the perp listing process.
Hyperliquid 协议将支持构建者部署的永续合约（HIP-3），这是实现永续合约上架流程完全去中心化的关键里程碑。
0x2 HIP-3：开发者部署的市场
HIP-3 的理念很简单：在不改动 Hyperliquid 交易与清算底座的前提下，把「新增永续市场」的能力开放给满足条件的 builder。Builder 负责定义市场的关键参数与喂价/运维责任，协议则用统一的保证金与清算引擎承接执行与风控边界；由此，「上新」从平台流程变成可调用的标准接口。
简单来说：builder 可以上架一个基于 HyperCore 引擎的永续合约市场，自行喂价与调整市场参数。
Builder 的职责边界
在 HIP-3 中，builder 对一个 perp 市场（market）承担两类工作：定义市场与运营市场。
市场定义（Market definition）：
官方把这部分概括为 oracle definition + contract specifications。在可操作层面，它至少包含：
oracle 定义：
包括初始 oraclePx和价格源的定义。builder在定义市场时应该明确定义一个有明确、难以操纵且具备经济实质的标的资产或数据源；在注册资产时就需要提供一个初始的oraclePx 。
合约规格：
在 API 接口中明确定义「资产符号/最小下单单位/最大杠杆」等市场参数（coin、szDecimals、maxLeverage 等）。
DEX选择：
Builder 首先部署的是一个 perp DEX（每个 DEX 独立保证金、订单簿、deployer 设置），同时可选择任意报价资产作为该 DEX 的抵押品（例如 USDC），每个 perp 市场都会对应一个 DEX。
市场运营（Market operation）：
官方列举的是 setting oracle prices / leverage limits / settling the market if needed，详细来说：
更新喂价：
通过 setOracle 接口进行对市场的 Oracle Price 进行持续喂价。
杠杆上限：
通过为资产配置对应的保证金表（margin table）来约束最大杠杆——杠杆上限随仓位规模分档设定，从而把可用杠杆限制在预设范围内。
必要时结算：
Builder 可以用 haltTrading 接口中止市场，触发结算——取消所有订单、把仓位按当前 mark price（标记价格） 结算；同一个动作也可用于恢复交易。
目前 HIP-3 市场只支持逐仓（isolated-only），未来可能会支持全仓（cross）。
Market 上线全流程
1.Stake
主网要求 builder 维持 500k HYPE 质押；并且即使把自己 DEX 上的市场都中止了，质押要求仍需维持 30 天。
2.Build
满足质押门槛后，builder 可以部署 一个 perp DEX。每个 perp DEX 是一套独立的交易域：独立保证金、订单簿、以及 deployer 设置。
3.Set collateral
该 DEX 的 collateral 可以选择 **任意 quote asset（报价资产），**但若该 quote asset 失去 permissionless quote asset 资格（验证者投票决定），使用它作 collateral（抵押品）的 perp DEX 会被禁用。
4.Add markets
前3个市场可直接部署；
继续新增市场时，需要通过荷兰拍卖（Dutch auction）获取「新增名额」。
5. Operate markets
市场上线后，builder 的工作变成「把市场跑稳」，即市场运营。
6. Unstake
当 DEX 上所有 market 都已结算后，质押的 500k HYPE 才能解锁，发起 unstake 后会进入7 天 unstaking queue，这段时间质押仍可能被罚没。
荷兰拍卖：当前周期为 31H 一轮，每次起拍价为上次 2 x 最终价格（成交价/最低价）。
SetOracle：三类价格输入
在 HyperCore 中，oracle price 主要用于锚定并计算资金费（funding），而 mark price 则作为保证金与清算等风控场景的标记价格（也用于触发 TP/SL 等）。
在原生市场里，mark price并不是某一个喂价的直接结果，而是取三个价格计算结果的中位数：
oraclePx + EMA(midPx - oraclePx)
median(best bid, best ask, last trade)（本地订单簿盘口价格）
多家 CEX 永续合约中间价 (perp mid prices) 的加权中位数
而到 HIP-3，oracle price 和 mark price 的作用没有发生改变 ，但计算机制发生了改变：
setOracle 输入
a. oraclePx（必须)
核心定义与 HyperCore 一致。
b. markPx (可选)
可以提交 0～2 组 外部 mark price 作为真正的 mark price 计算候选值。
c.externalPerpPx（必须）
作为一个 mark price 的参考值输入，用于防止 mark price 发生突然偏离。
Builder 往往会部署 relayer 节点进行喂价，oraclePx
由 relayer 结合外部价格源综合计算；markPx由 relayer 自定义算法计算；externalPerpPx 来自多家 CEX perp mid prices 的加权中位数。
2. 实际 mark price
HIP-3 的 mark price 并不是直接使用 setOracle 的喂价：
计算 local mark：median(best bid, best ask, last trade) 。
把 local mark 和 markPx（0–2 组） 放在一起，取中位数，得到新的 mark price。
3.setOracle 限制
更新频率：两次调用之间至少间隔 2.5 秒，10s 未更新 markPx 将会回退为 local mark price。
幅度限制：markPx 每次波动幅度不超过 ±1% ；所有价格都会被 clamp 到当日开盘（start-of-day）值的 10× 范围内。
7×24H & 非 7×24H：定价机制的差异
在 HIP-3 中，永续合约市场支持任何资产的上线，而这些资产可以分为 7×24H 资产（全天候交易）和 非 7×24H 资产（只有特定交易时段，非交易时间段现货市场无法交易）。这两类资产的交易时间特性决定了其价格获取方式的差异。
对于 7X24H 资产（例如BTC），可以从CEX/DEX或可信预言机综合获取稳定价格:
对于非 7X24H 资产（例如股票）, 只有在开盘时间段才能获得流动性充足、相对稳定的外部市场报价，要维持此类资产在HIP-3中全天候正常运行，需要在休市期间使用另一套定价机制。
以trade.xyz上的股票永续合约市场为例:
在股市开盘期间，使用Pyth等外部预言机服务提供的稳定喂价。
在股市休市期间，基于股票的上一次收盘价，结合内部买卖盘压力进行价格调整。mark prices限制为上一次收盘价上下浮动的1/max_leverage（e.g.， Tesla 10x -> 10%）。
清算
HIP-3 市场主要复用了 HyperCore 的清算逻辑，因此清算触发逻辑沿用平台：当仓位净值（isolated position value）不足以覆盖维持保证金要求时进入可清算状态。
清算相关判断以 mark price 为准，而不是某一笔成交价。
清算价公式：
side = 1（long），-1（short）
l ：即维持保证金率
而 MAINTENANCE_LEVERAGE 的取值来自该仓位对应的保证金档位（margin tier）：先在该档位读出维持保证金率 mmr：
如果有分档（tiers），清算价对应的仓位名义价值落在哪一档，就用那一档的mmr。
margin_available
isolated：isolated_margin - maintenance_margin_required
进入可清算状态后，系统会优先通过订单簿用市价单平仓；如果能把风险拉回安全区间，剩余保证金仍归交易者。
但在深度不足或跳空时，实际平仓成交均价可能显著差于 mark price，从而形成「清算缺口」。
Isolated position value：指某个 isolated 仓位在当前 mark price 下的净价值（仓位盈亏计入后减去该仓位所绑定的保证金）。
ADL：
此时 ADL (Auto-Deleveraging) 机制可以用来在极端情况下进行兜底：
当 isolated position value 变为负值，则触发 ADL，从对手盘仓位中按未实现盈亏和使用杠杆排序，依次在 previous mark price 上强制减仓/平仓，用对手盘的盈利填平缺口，保证系统不出现坏账。
排序标准按照以下标准计算：
previous mark price：指触发 ADL 前系统记录的上一笔 mark price。
例子：
触发 ADL 前，系统的 mark price = 3,000。
由于 setOracle 的约束，新的mark price最多只能更新到 2,970（-1%）。
但此时订单簿买盘很薄，清算市价单打进盘口后，实际平均成交价 = 2,910（相对 3,000 是 -3%）。
多头仓位的亏损按 2,910 结算，可能把该仓位的 isolated position value 打到0以下（出现缺口），于是触发 ADL。
ADL 随后从对手盘（盈利空头）里挑选仓位，按 previous mark price = 3,000 结算强制减仓/平仓，把缺口转移为「盈利方被动少赚」。
0x3 风险面概览：
可追责约束与关键风险
罚没机制（Slashing）：可追责的权限
HIP-3 把「上新与运营权」交给 builder 的同时，也把责任用一套可执行的罚没规则写进协议：builder 必须质押 HYPE，一旦被认定为不当运营，验证者可以投票罚没并销毁（burn）其质押。
质押要求
主网要求 builder 维持 500k HYPE 质押，即使 builder 将其全部市场中止，仍需继续维持 30 天（责任不会因为停盘立刻解除）。
触发与表决
当出现恶意市场操作时，验证者可以发起并执行 stake-weighted vote（按质押权重投票）来决定是否对 builder 的质押进行罚没。
判定原则
官方明确：罚没不区分「恶意 / 能力不足 / 私钥被盗」等原因，核心看 builder 的行为是否造成了无效状态、长时间宕机或性能退化等后果。
罚没幅度
罚没比例由验证者投票决定，参考上限：
导致无效状态或长时间宕机：最高 100%
短暂宕机：最高 50%
性能退化：最高 20%
被罚没的质押代币会被销毁，而不是补偿给受影响用户。
参数配置风险
setOracle
Oracle prices 一般来源于 builder 的 relayer 服务器，存在中心化的风险，一旦私钥泄漏或者遭受DDoS 攻击，Market中的 oracle price 可能会被恶意操控或长期脱锚。
haltTrading
Builder 可通过 haltTrading 取消 market 中的所有订单，并按当前 mark price 平仓。
该操作应当谨慎使用，例如存在如下场景:
当检测到市场被攻击者恶意操控，调用 haltTrading 直接以 mark price 平仓，则会直接兑现攻击者仓位的浮盈(原本攻击者可能难以找到足够对手方订单)，并且可能导致坏账。
setMarginTableIds / InsertMarginTable
InsertMarginTable：定义一个新的 margin table，其中定义了某一类资产的保证金要求和最大杠杆。
setMarginTableIds：把某个 market绑定到指定的 marginTableId。
对于一个低流动性/做市能力不足的市场，把 max leverage 设得过高，会增加 ADL 触发概率。
突然切换 marginTableId 等同于修改用户仓位的维持保证金比例，可能让大量账户在同一时刻从安全变成可清算，引发连环清算。
setMarginModes
当前 HIP-3 只允许 isolated margin（逐仓），未来可能支持cross margin（全仓），一个 DEX 内可能存在高流动性和低流动性的 market ，cross margin 模式可能会使低流动性风险传导至高流动性市场。因此在官方未给出成熟解决方案之前，不建议 builder 引入 cross margin。
预言机风险
对于 7x24H 的资产，风险点主要在于依赖的外部 oracle 服务的准确性和稳定性，以及前文提到的 relayer服务器的中心化风险。
而对于非 7x24H 的资产，更大的风险面在于在该资产非交易时间段内的 oracle price 的获取或计算。
以 trade.xyz 为例，非交易时间段内采用最后一次外部 oracle price 和 内部市场价格综合计算。在周末股票永续市场缺乏流动性（订单簿变薄且做市商减少报价），且没有外部 oracle price 进行锚定。即使其设置了价格波动的硬顶（1/max_leverage），但这个限制对于低波动资产来说仍然过高，价格在此幅度内波动仍可能造成大面积清算甚至 ADL。
2025年12月14日，trade.xyz 中的 XYZ100-USDC (对标NASDAQ100)遭到市场操控，攻击者创建了 398 XYZ100 的空头仓位(~10M USDC)，导致价格严重脱锚，大量多头遭到清算，清算同时导致价格继续下跌，最终导致 ~13M USDC 的多头被清算。
https://x.com/bartdothl/status/2000292798755684839
另一方面，非交易时段缺乏连续、可锚定的稳定 oracle price，市场往往只能依赖「最后一次外部价 + 内部订单簿」形成一个受限的内部定价区间（例如 trade.xyz 限制 1/max_leverage 的最大波动幅度）。
风险出现在重新开盘的切换点：外部市场会瞬间给出一个明确的外部价格，如果它与休市期间的内部定价存在显著跳空，系统要么继续被 clamp 限制而产生外部价与可交易价的严重偏离，要么在切换回外部锚定时发生快速再定价；两种路径都可能在短时间内集中触发清算压力，极端情况下导致ADL 事件增多。
0x4 风险控制策略
1) 稳定的 Oracle Price
对股票这类 非全天候交易 资产，难点主要集中在休市期间的定价：外部可锚定的稳定报价不足，市场更容易在薄深度下被操纵或自行漂移。
目前业界的常见解决方案主要分为两个方向：
直接停止更新oracle price ，暂停或限制该时段的交易 (例如Lighter协议在休市时段只允许减仓)。 Optium 等协议还会下调休市期间的最大杠杆率，对超出限制的仓位强制平仓。
采用类似trade.xyz的「内部定价」机制，在外部数据缺失时，依赖协议内部的市场流动性和算法维持运转。
这两类方案直观地反映了协议设计在安全与体验方面的取舍。第一种方案采用更严格的风控机制，但代价是大大牺牲了用户的交易体验。而第二种方案虽然维持了交易的连续性，但由于缺乏外部参考，容易导致内部定价与标的资产的实际价值发生偏离。
在休市阶段，应避免让协议定价完全退化为「纯内部价」，而是引入可参考的外部锚，降低脱锚与跳空风险。可选参考包括：
Blue Ocean ATS
作为盘后/夜盘相关的交易场所，可为休市阶段提供一定程度的连续价格参考（相对「最后收盘价」更及时），用于辅助生成休市 oracle price 或作为价格脱锚的监控基准。
IG weekend CFD quotes
周末 CFD 报价可提供「周末市场预期」的替代价格信号，适合用于休市阶段的外部锚或监控对照，帮助提前发现「开盘可能跳空」的方向与幅度。
这两类来源的共同点是「能提供休市阶段的价格信号」，但它们与正股现货并非完全同一市场结构，更适合作为锚/对照与风险预警信号，而不是无条件等价替代。
2) 价格验证
HIP-3 的 oracle prices 来源于 builder 设置的 relayer 服务器，可能存在中心化的争议。对此推荐 builder 构建一套价格验证机制，让任何用户或机构都能链下验证价格的真实性和公平性(类似RedStone ，把价格值连同其数据来源与签名证明一起打包上链)。
公开数据
算法规范：披露详细的算法与流程机制
数据源清单：每个数据源应当是公开且不受 builder 干预的，并且公开详细接口和参数
价格推送规范：setOracle 调用的权限、触发频率和波动限制
b. 价格证明
对每次 setOracle 调用生成一条对应的证明 (Proof)，包含：
Inputs：每个数据源在该时间点的原始响应（或规范化后的字段），以及采样时间戳。
Computation：可复算的中间量，每一步计算的中间结果
Outputs：该次上链的 oracle price
对 Proof 做序列化，得到 proofHash，oracleUpdater 对 proofHash 签名。
c. 证明上链
维护一个列表，把每个 ProofHash 按时间顺序写入 Merkle tree
每隔固定周期（比如每小时/每天）发布一次 MerkleRoot 并且上链
d. 验证
提供开源工具或网页，输入对应时间段或某次 setOracle 的 tx hash，获取以上所有数据
验证签名、时间戳、MerkleRoot 等
通过公开算法计算 oracle price 进行对比
3) 风险监控
价格验证把 setOracle 的过程变成「可复算、可审计」，解决的是喂价是否可信的问题；但它并不能阻止市场在运行中走向失控——喂价中断、价格偏离与深度退化，一旦叠加庞大的未平仓规模 (OI)，极易让局部异常演变为连环清算甚至 ADL的系统风险。所以应当把市场的异常尽早变成可观测信号，并在窗口期触发处置，把风险压回可控边界。
1. 价格侧
a. Oracle 喂价失效
监测指标：
直接用链上可观测量判断喂价是否阻塞：
阈值分级：
Action：
Level 1：对 relayer 做健康度检测，切换备用 relayer 节点；发出包含健康度报告与所有 relayer 节点信息的预警。
Level 2：调用 setOpenInterestCaps 下调 OI cap：
b. 价格脱锚
监测指标：
阈值：
Level 1：在 A、B、D 中，≥ 2 个超过阈值
Level 2：在 A、B、C、D 中，≥ 3 个超过阈值，且持续 X 秒
Action：
Level 1：调用 setOpenInterestCaps 下调 OI上限
Level 2：伴随长时间偏离，逐步更新 margin table，分档逐步降低 max leverage；Relayer 启用 clamp 机制
Level 3：在 Level 2 情况下持续发出预警，最终由 builder 决定是否调用 haltTrading 停止市场
2. 盘口侧
a. 深度抽离
监测：
depth_band(±x%)：在 mid 附近 ±x% 价格区间内的真实挂单承接量
spread = bestAsk - bestBid：价差，用于衡量盘口是否「断裂」
aggressiveVolume_Δt：Δt 内主动吃单成交量（taker volume，按 trade side 聚合）
impact_ratio = aggressiveVolume_Δt / depth_band：承接比
depth_band下降，伴随 spread 和 impact_ratio上升
Action：
Level 1：调用 setOpenInterestCaps 下调 OI上限 = 当前 OI，限制仓位增量
Level 2：调用 setMarginTableIds 强行下调杠杆，避免高杠杆仓位产生的同时，强制平仓一些高杠杆高风险的仓位
b. 虚假挂单
监测：
depth_band 在短时间内 上升并突然下降
Action：
Level 1：调用 setOpenInterestCaps 下调 OI上限 = 当前 OI
Level 2：若伴随价格严重脱锚，考虑停止市场
3. 仓位侧
仓位侧监控的目标不是「预测方向」，而是识别市场是否从交易驱动转向持仓博弈：当 OI 快速累积、仓位高度集中、且多数派盈亏逼近极值时，价格任何一次外生扰动都更容易被放大为清算瀑布 / ADL。因此仓位侧的动作优先级一般低于价格侧与盘口侧。
a. 短期 OI 过重
监测：
OI_notional：未平仓规模
Volume_24h_notional：24h 成交额
计算 OI_notional / Volume_24h_notional，比例极速上升意味着市场从短线持仓转为持仓博弈，通常预示市场即将出现剧烈波动。
Action：
Level 1：触发上限时触发预警
b. 多数派盈亏
监测：
多数派（Majority Side）：在统计窗口内，持仓人数更多的一方（Long 或 Short）
avgEntry_major：多数仓位平均开仓价
size_major：多数派仓位规模
多数派盈亏：
多数派盈亏比例：
Action：
Level 1：触发上限时触发预警
Level 2：持续触发上限，考虑调用 setOpenInterestCaps 下调 OI上限
0x5 结语
HIP-3 的核心叙事，其实就是：把「上新」从少数人拍板的流程，改成满足门槛就能调用的协议能力——builder 通过质押，就可以在 HyperCore 上启动自己的 perp DEX、先免费上线少量市场，再通过拍卖争取更多名额，从而让市场扩张从「等待审批」变成「按规则扩容」。
但同样清晰的是：HIP-3 并没有让风险消失，它只是把风险的位置与形态改写了。原来由平台风控兜底的部分，现在更多落在 builder 的输入与运维质量上：setOracle 的喂价与频率、markPx 的选择与约束、margin table 的分档杠杆、非 7×24H 资产休市定价的「内部区间」、以及 haltTrading 这种「能止损也能放大损失」的权力。任何一个环节处理失当，都可能在薄深度里被放大为集中清算，进一步触发缺口与 ADL——问题不再是「能不能上」，而是「上了之后能不能跑稳」。
协议层面应对这种「风险外包」的核心，是把权限转变为可追责的权限：质押 + 验证者投票罚没让 builder 的「运营失当」有明确的代价边界；同时，价格与杠杆的约束（clamp、更新间隔、波动上限、逐仓隔离）试图把最危险的尾部情形收敛在可控范围内。于是 HIP-3 的真实命题变成了：扩容靠开放，安全靠约束，长期靠可验证与可追责。
HIP-3 不是让上新更自由，而是让上新更标准化——能部署、能运营、能追责。而标准化要真正跑稳，最终还取决于 oracle/杠杆/风控参数与运行时监控的落地质量。
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
