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 上線全流程
Stake
主網要求builder 維持500k HYPE 質押；並且即使把自己DEX 上的市場都中止了，質押要求仍需維持30 天。
Build
滿足質押門檻後，builder 可以部署一個perp DEX。每個perp DEX 是一套獨立的交易域：獨立保證金、訂單簿、以及deployer 設定。
Set collateral
該DEX 的collateral 可以選擇**任意quote asset（報價資產），**但若該quote asset 失去permissionless quote asset 資格（驗證者投票決定），使用它作collateral（抵押品）的perp DEX 會被禁用。
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（eg， Tesla 10x -> 10%）。
清算
HIP-3 市場主要重複使用了HyperCore 的清算邏輯，因此清算觸發邏輯沿用平台：當部位淨值（isolated position value）不足以涵蓋維持保證金要求時進入可清算狀態。
清算相關判斷以mark price 為準，而非某一筆成交價。
清算價公式：
side = 1（長），-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)，導致價格嚴重脫錨，大量多頭遭到清算，同時導致價格繼續下跌，最終導致價格被清算的多錨，大量多。
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/槓桿/風控參數與運轉時監控的落地品質。如果你在基於HIP-3 設計市場准入、參數模板、預警與緊急流程，或需要審計與持續安全支持，歡迎聯絡BlockSec 。
