Builder必讀：HIP-3市場如何識別與化解風險

HIP-3（Hyperliquid改進提案3）上線主網三個月以來，第三方構建者部署的自定義市場累計成交量已突破130億美元。這個數字的背後是什麼？是平台權力的下沉：曾經由中心化交易所壟斷的"上新"權力，被改造成了一套開放的標準接口。Builder只需質押50萬HYPE代幣，就能在Hyperliquid統一的交易與清算底座上部署永續合約市場。

但權力下沉的同時，風險也隨之外移。如何識別這些風險、又如何在運營中及時察覺問題信號，成為每個Builder都必須掌握的核心能力。

架構基礎：理解HIP-3的風險來源

要識別HIP-3中的風險，首先要理解它的架構設計。

HIP-3構建於Hyperliquid的雙層架構之上。HyperCore是為合約交易優化的定制化L1區塊鏈，每秒可處理20萬筆訂單並具備確定性終結性；HyperEVM則是應用層，可運行智能合約。這套架構的巧妙之處在於：撮合、清算與結算由協議統一提供，Builder無需從零搭建交易系統。

但正因如此，Builder的職責邊界變得清晰卻又脆弱——清晰是指職責明確（定義市場+運營市場），脆弱是指職責完全外包（風控權完全掌握在Builder手中）。

Builder需要質押500k HYPE並承擔兩大職責：

• 市場定義：確定預言機價格源、合約規格（槓桿、最小下單單位等）、抵押資產選擇
• 市場運營：持續喂價、調整保證金表（槓桿上限）、在必要時中止市場

一旦市場上線，質押鎖定30天才能申請解鎖。這意味著任何運營失當都會面臨驗證者的罰沒投票——但投票之前，Builder需要先識別出問題的存在。

三層定價機制：怎樣判斷Oracle價格健康度

HIP-3中最關鍵、也最易出現風險的，就是喂價機制。Builder需要理解setOracle接口的三個價格輸入：

oraclePx（必須）：由Builder的relayer伺服器綜合計算，作為資金費的錨。 markPx（可選）：Builder提交的0～2組外部標記價格，作為mark price的候選值。 externalPerpPx（必須）：來自CEX perp的加權中位數，用於防止mark price突然偏離。

最終的mark price並不是直接使用喂價，而是取本地訂單簿盘口（median of best bid/ask/last trade）與markPx的中位數。這意味著什麼？

這意味著價格計算存在多個失效點：

• 如果relayer離線或遭受DDoS，oraclePx會中斷喂價
• 如果Builder的markPx算法存在缺陷，可能導致系統被套利
• 如果本地訂單簿過薄，median計算會扭曲價格

setOracle的約束條件看起來很嚴格：

• 更新頻率：兩次調用間隔≥2.5秒，10秒未更新會自動回退到local mark price
• 幅度限制：markPx每次波動≤±1%，所有價格被clamp到當日開盤值的10倍範圍內

但這些約束對於非7×24小時交易的資產（如股票），保護力度就大幅下降。

非7×24H資產的隱患：休市期間的定價陷阱

對於BTC這類7×24小時交易資產，Builder可以依賴CEX/DEX的連續價格源。但對於股票等非全天候資產，休市期間怎樣判斷價格？

目前的做法是：依賴上一次收盤價+內部訂單簿壓力的特殊定價機制。具體來說，mark price被限制在上一次收盤價上下浮動的1/max_leverage範圍內（例如10倍槓桿則±10%）。

這個機制的問題在哪？當外部市場缺乏流動性錨定時，內部訂單簿的深度本身就很薄。一旦有大額委託單進場，可能會在休市期間造成價格虛假波動，特別是當多頭倉位集中時。

2025年12月14日，trade.xyz的XYZ100-USDC市場（對標NASDAQ100）遭到操縱：攻擊者創建了398個空頭倉位（規模約10M USDC），通過人為壓低價格，導致大量多頭在短時間內被集中清算，最終約13M USDC的多頭頭寸被強制平倉。

問題的根源就在於：

• 休市期間外部價格錨定缺失
• 內部深度不足以支撐波動率限制之外的價格發現
• 清算一旦啟動，價格反饋會進一步放大下跌

預言機風險：如何識別中心化威脅與脫錨隱患

Builder部署的relayer伺服器存在天然的中心化風險。私鑰洩漏、DDoS攻擊、算法錯誤，任何一個都能導致喂價中斷或被操縱。

識別預言機風險的四個關鍵信號：

1. 喂價延遲或中斷

   • 監測：鏈上可觀測的最後一次setOracle調用時間戳
   • 告警閾值：超過10秒未更新，系統自動回退到local mark，此時脫錨風險急劇上升
   • 應對：切換備用relayer、發出健康度警報

2. 價格脫錨

   • 監測指標：
     • oracle price與CEX perp mid的偏離度
     • mark price與oracle price的差值
     • 本地訂單簿與外部市場的乖離
   • 識別方法：當≥2個指標同時超過閾值時，判定為價格脫錨
   • 應對：逐步下調max leverage、啟用更嚴格的clamp機制

3. 非7×24H資產的開盤跳空

   • 監測：休市期間內部定價與開盤價的預期差
   • 參考源：Blue Ocean ATS（盤後交易）或周末CFD報價
   • 判定：如果開盤前檢測到跳空風險>5%，提前發出預警

4. 虛假流動性

   • 監測：訂單簿深度與承接比（主動吃單量/掛單量）
   • 識別：depth在短時間內快速上升後突然消失
   • 應對：立即下調OI上限，限制新倉位增加

參數配置陷阱：Builder最易忽視的風險點

很多Builder認為定好參數就萬事大吉，實際上參數的動態調整才是最考驗運營水平的地方。

關鍵的配置風險：

1. 槓桿設置過高 對於低流動性的市場，設置過高的max leverage會大幅提升ADL（自動去槓桿）的觸發概率。當倉位規模快速累積、多數派盈虧接近極值時，任何一次價格波動都可能引發連環清算。

2. 突然調整margin table 這相當於一夜之間改變所有用戶的維持保證金比例。大量帳戶會瞬間從"安全"變成"可清算"，導致批量強制平倉。這類操作必須提前公告，且要分階段實施。

3. haltTrading的濫用 Builder可以調用haltTrading中止市場、取消所有訂單、按當前mark price結算。但這把"雙刃劍"如果使用不當，反而會兌現攻擊者的浮盈——原本攻擊者很難找到足夠的對手方訂單，haltTrading卻直接按mark price結算，反而幫攻擊者鎖定收益。

4. 跨保證金模式（未來風險） 目前HIP-3僅支持逐倉。一旦未來支持全倉，低流動性市場的風險會直接傳導到高流動性市場。在官方給出成熟解決方案前，Builder不應嘗試。

全維度風險監控體系：從價格到倉位的完整預警框架

既然風險無處不在，Builder就需要建立一套多維度、多層級的實時監控體系。

價格側監控

Level 1 告警（喂價異常）：

• 指標：setOracle調用間隔>5秒
• 行動：檢測relayer健康度，切換備用節點
• 輸出：包含所有relayer資訊的預警

Level 2 命令（價格脫錨）：

• 指標：oracle與CEX perp偏離>2%，且持續>5秒
• 行動：調用setOpenInterestCaps下調OI上限
• 進一步：逐步降低margin table中的max leverage

Level 3 告警（長期偏離）：

• 指標：脫錨持續>30秒
• 行動：啟用clamp機制強制限制波動
• 最後：由Builder決定是否調用haltTrading停止市場

盘口側監控

深度抽離信號：

• 監測：±2%價格區間內的真實掛單深度（depth_band）
• 告警：depth_band下降，同時bid-ask spread擴大，主動吃單量/深度比（impact_ratio）上升
• 判定：三者同時發生意味著市場流動性快速惡化
• 應對：下調OI上限，禁止新倉位增加

虛假掛單識別：

• 信號：depth_band在短時間內快速上升後突然消失
• 應對：下調OI至當前水平（禁增），若伴隨價格嚴重脫錨則考慮停止市場

仓位側監控

倉位側的目標不是"預測價格"，而是識別市場是否已從交易驅動轉向持倉博弈。

OI過重信號：

• 計算：OI_notional / 24h_Volume_notional
• 判定：這個比例急速上升意味著市場即將出現劇烈波動
• 應對：發出預警，準備降低槓桿

多數派盈虧信號：

• 指標：多數持倉方（Long或Short）的平均開倉價、倉位規模、當前盈虧比例
• 預警：多數派盈虧接近極值（如多頭都浮盈20%以上）時
• 含義：任何外生沖擊都會被放大為清算瀑布
• 應對：提前下調槓桿，降低極端情況的損失規模

風險驗證：讓預言機可審計、可復算

僅有監控還不夠，Builder還需要讓喂價過程本身變成"可驗證"的。

建立價格證明體系：

1. 公開算法與數據源

   • 披露setOracle的完整邏輯與參數設置
   • 列出所有數據源及其權重
   • 公開更新頻率與波動限制

2. 生成可鏈下驗證的證明

   • 對每次setOracle調用生成Proof，包含：
     • Inputs：原始數據源響應與時間戳
     • 計算：中間計算結果
     • Outputs：最終上鏈的oracle price
   • 對Proof序列化後生成proofHash，Builder簽名

3. 周期性上鏈MerkleRoot

   • 將所有proofHash寫入Merkle tree
   • 每小時/每天發布一次MerkleRoot上鏈
   • 任何用戶都能驗證某次喂價是否真實

4. 提供開源驗證工具

   • 用戶輸入時間或tx hash，自動獲取完整數據
   • 驗證簽名、時間戳、MerkleRoot
   • 重新計算oracle price與鏈上數據對比

這套體系的意義在於：即使Builder的relayer被攻破，用戶也能通過鏈下驗證發現異常，從而為協議層的追責提供證據。

風險隔離：對不同資產的定制化策略

不同類型資產的風險特徵完全不同，監控閾值也應該因資產而異。

7×24H資產（BTC、ETH等）：

• 優勢：連續的外部價格錨定
• 主要監控：relayer穩定性、oracle與CEX perp偏離
• 閾值：相對寬鬆（脫錨>3%才警告）

非7×24H資產（股票等）：

• 劣勢：休市期間缺乏外部錨
• 主要監控：開盤前的跳空預測、休市期間的虛假波動
• 閾值：相對嚴格（脫錨>1%就警告）
• 參考源：Blue Ocean ATS盤後報價或周末CFD報價
• 特殊處理：在高風險時段（收盤前1小時、開盤後30分鐘）強制降低max leverage

清算與ADL：理解極端情形下的風險鏈條

清算本身不是風險，風險在於清算引發的連鎖反應。

HIP-3沿用HyperCore的清算邏輯：當倉位淨值不足以覆蓋維持保證金時觸發清算。系統優先通過訂單簿用市價單平倉，但如果訂單簿深度不足，實際平倉成交價會顯著偏離mark price，形成"清算缺口"。

當缺口出現時，ADL（自動去槓桿）機制啟動：

• 從對手盤中選擇盈利倉位
• 按上一筆mark price強制減倉
• 用對手盤的盈利填補缺口，保證系統不出現壞帳

**但ADL的觸發意味著市場已經進入極端狀態。**一旦ADL啟動，盈利方被迫少賺，這會動搖市場信心，可能引發進一步的風險事件。

Builder如何識別ADL即將觸發？

• 監測：倉位集中度、OI規模、訂單簿深度
• 信號：OI_notional / depth_band的比值快速上升
• 預防：提前降低max leverage，限制新倉位，防止極端情形

可追責的未來：標準化、驗證與監督的三位一體

HIP-3的核心創新在於：把權力下沉，但把責任寫進協議。

驗證者可以對運營失當的Builder投票罰沒，罰沒比例由嚴重程度決定：

• 導致無效狀態或長時間宕機：最高100%罰沒
• 短暫宕機：最高50%罰沒
• 性能退化：最高20%罰沒

被罰沒的質押代幣會被銷毀，而不是補償給受影響用戶。這意味著什麼？Builder的名譽和代幣資產都會受損，這是制約運營失當的最強激勵。

但罰沒機制要有效，前提是：

1. 風險必須可觀測：完整的監控體系能及時發現異常
2. 責任必須可追蹤：可驗證的喂價證明能追溯問題源頭
3. 判定必須可執行：驗證者投票機制必須高效透明

總結：從"能部署"到"能跑穩"

HIP-3用開放接口取代了平台審批，第三方市場的成交量突破130億美元證明了這個方向的可行性。但開放的代價是：原由平台風控兜底的部分，現在更多落在Builder的輸入與運維質量上。

從Builder的角度，需要掌握的不僅是"怎樣部署市場"，更關鍵的是"怎樣識別市場風險"與"怎樣及時應對"。這需要：

1. 理解風險來源：從架構、定價、參數、流動性的多維度認識風險
2. 建立監控體系：從價格、盘口、倉位的全維度實時預警
3. 實施驗證機制：讓喂價過程透明可復算，建立可追責的證據鏈
4. 準備應急預案：何時降槓桿、何時限制OI、何時停止市場

長期安全的關鍵在於：Builder能否落實可靠的預言機方案、合理的參數配置、以及持續有效的市場狀態監控。

HIP-3不是讓上新更自由，而是讓上新更標準化——能部署、能運營、能追責。而這個標準化體系要真正跑穩，最終還取決於Builder對風險的深度理解與執行力。

如果你在基於HIP-3設計市場准入規範、制定參數模板、構建預警系統，或需要風險審計與持續安全支持，BlockSec等專業安全團隊可以提供深度的技術諮詢與審計服務。