深入剖析 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 原生永續合約市場（也稱為驗證者營運的永續合約）的上架流程，仍然類似於傳統中心化交易所（CEX）的方法。新合約的上架主要由核心團隊推動，而下架則通過驗證者投票決定。

HIP-3 的引入旨在通過賦能開發者部署的永續合約市場來將上架流程去中心化。它通過允許開發者定義和運作市場，同時由協議強制執行硬性的執行與風險邊界，實現了市場定義與協議執行之間的隔離。因此，HIP-3 代表了邁向全面去中心化永續合約上架流程的一個關鍵里程碑。

0x1 開發者責任：定義與運作

在 HIP-3 下，開發者對市場生命週期管理承擔端到端的責任。在本節中，我們首先說明市場發布的工作流程，然後重點關注直接決定生產環境中市場穩定性的營運槓桿。

0x1.1 市場發布流程：定義與運作

在 HIP-3 下，發布市場並非單一操作。如下方完整的市場發布工作流程圖所示，它是一個跨越兩個不同階段的過程：市場定義（步驟 1 至 4）與市場運作（步驟 5）。

在市場定義階段，開發者首先必須在主網質押 500,000 HYPE。滿足質押要求後，開發者可以部署一個永續合約去中心化交易所（DEX），該交易所形成一個獨立的交易域，具有自己的保證金系統、訂單簿以及由部署者控制的設置。在 DEX 層面，開發者選擇一個報價資產作為該 DEX 所有市場的抵押品。所選的報價資產必須保持無需許可（permissionless）的狀態，因為失去此狀態將導致相應的 DEX 無法運作。隨後，開發者定義市場核心參數，包括預言機規格、合約參數（如交易代碼、槓桿限制）以及保證金表。前三個市場可以直接部署，而額外的市場則需要通過荷蘭拍（Dutch auction）獲取插槽。

荷蘭拍：每一輪持續 31 小時，每次的起拍價是上一次最終價格的 2 倍（上次成交價/最低價）。

一旦市場上線，開發者就進入市場運作階段。此階段涉及通過 setOracle 接口持續更新預言機價格、維護槓桿與保證金配置、監控流動性與未平倉合約，並在必要時執行緊急操作（如暫停交易和結算倉位）。

實際上，HIP-3 下大多數嚴重的故障並非發生在市場定義期間，而是在極端市場條件下的長期運行中。重要的是，開發者的責任並不會在市場暫停後立即終止。只有在所有市場結算完畢後才能贖回質押，且在強制贖回期內，質押資產仍面臨被削減（slashable）的風險。

0x1.2 關鍵重點領域：定價與償付能力

開發者在市場定義和市場運作中面臨兩個密切相關的重點領域：預言機配置與價格形成，以及壓力下的市場償付能力。這兩個領域緊密相連，因為定價失敗會通過協議層面的風險控制，迅速演變為償付能力危機。

1. 預言機配置與價格形成

Hyperliquid 定義了兩種價格：

預言機價格 (Oracle Price)：主要外部交易所現貨中間價的加權中位數，旨在獨立於 Hyperliquid 內部市場數據，主要用於錨定資金費率。
標記價格 (Mark Price)：一種內部風險價格，衍生自多種輸入（包括預言機價格和本地市場數據），用於計算未實現盈虧 (PnL) 及觸發風險控制。

簡而言之，預言機價格錨定資金費率，而標記價格驅動保證金檢查、強制平倉，以及止盈 (TP) 和 止損 (SL) 觸發。

在 HIP-3 下，預言機價格和標記價格的角色沒有改變，但計算機制有所更動：

a) setOracle 的輸入

oraclePx（必需）：與 HyperCore 中的定義相同。
markPx（可選）：0–2 個外部計算的標記價格候選值。
externalPerpPx（必需）：用於防止標記價格突然偏離的參考值。

開發者通常部署中繼節點（relayer nodes）來餵價：oraclePx 由多個外部來源計算得出，markPx 由中繼器以自定義算法計算，externalPerpPx 則來自多個 CEX 永續合約中間價的加權中位數。

b) 實際標記價格

計算 本地標記價 (local mark)：median(最佳買價, 最佳賣價, 最新成交價)。
將 本地標記價 與 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 上的股票永續合約市場為例：

市場交易時間內，由 Pyth 等外部預言機服務提供穩定的預言機價格。
非市場交易時間內，價格根據資產的最後收盤價進行調整，結合訂單簿內部的買賣壓力。標記價格被限制在最後收盤價的 ±1 / 最大槓桿 波動範圍內（例如：Tesla：10 倍槓桿 → ±10%）。

2. 壓力下的市場償付能力

Hyperliquid 採用強制平倉（Liquidation）和自動減倉（ADL, Auto-Deleveraging）兩種機制來維持市場償付能力。在 HIP-3 下，清算和 ADL 大致遵循 HyperCore 的設計。主要區別在於一個協議層面的限制：作為協議金庫的 HLP (Hyperliquidity Provider) 不能接管 HIP-3 市場中的高風險倉位。因此，HyperCore 中在市場清算與 ADL 之間緩衝風險的中間金庫機制在 HIP-3 中是不存在的。

鑑於在極端市場條件下，從清算到 ADL 路徑的重要性，我們在下文中詳細審視清算與 ADL 機制。此處討論的所有償付能力機制皆假設為「隔離保證金」模式，這是目前 HIP-3 市場唯一支持的保證金模式。

a) 強制平倉 (Liquidation)

當 倉位淨值（隔離倉位價值） 不足以滿足 維持保證金要求 時，將觸發強制平倉。所有與清算相關的檢查均基於標記價格，而非特定的執行價格。

清算價格公式定義如下：

其中：

side：多頭倉位為 1，空頭倉位為 -1
l 為維持保證金率

MAINTENANCE_LEVERAGE 的值由對應倉位的保證金層級決定。根據該層級，獲取維持保證金率 mmr：

配置保證金層級時，應用與清算價格下倉位名義價值對應的層級之 mmr。

可用保證金（隔離）：隔離保證金 - 維持保證金要求

一旦倉位進入可清算狀態，系統首先會嘗試通過 訂單簿上的市價單 將其平倉。如果執行成功使風險回到安全範圍內，剩餘保證金將返還給交易者。

然而，在訂單簿深度不足或出現價格跳空的情況下，實際平均執行價格可能會顯著劣於標記價格，從而導致 「清算缺口 (liquidation shortfall)」。

隔離倉位價值指隔離倉位在當前標記價格下的淨值，代表扣除未實現盈虧後分配給該倉位的保證金。

b) 自動減倉 (ADL, Auto-Deleveraging)

在極端情況下，ADL 機制作為最終後盾。

當 隔離倉位價值變為負數 時，將觸發 ADL。系統根據盈虧和槓桿對盈利的交易對手進行排名，然後以 之前的標記價格（ADL 觸發前最後記錄的標記價格）強制減少或平掉這些倉位。通過利用贏方的利潤來 抵消赤字，協議保持償付能力，不會產生壞帳。

排序索引計算公式為：

此處，notional_position 指當前標記價格下倉位的絕對市場價值，計算公式為 |倉位大小| × 標記價格。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 不會區分惡意行為、操作失誤、私鑰洩漏或第三方依賴失敗。

質押要求：在主網上，開發者必須持續質押 500k HYPE。即使開發者暫停了所有市場，也必須維持質押達 30 天（因為市場雖暫停，但責任並不會立即消失）。

如果開發者的行為導致無效狀態、長時間停機或嚴重的性能下降，可能會觸發削減。根據嚴重程度不同，削減金額可從部分質押扣除到全額質押銷毀。這種設計使得開發者必須對其市場的全運行時行為承擔經濟責任。

削減比例由驗證者投票決定，參考上限為：

無效狀態 / 長時間停機：最高 100%

短時間停機：最高 50%

性能下降：最高 20%

被削減的代幣將被銷毀，而非重新分配。

在 HIP-3 下，開發者的風險主要源於兩個方面：內部參數配置錯誤 和 外部預言機依賴。以下章節將詳細審視這兩個來源，並解釋它們如何轉化為削減後果。

0x2.2 內部參數配置誤操作導致的風險

誤操作風險包括在低流動性市場中設置過高槓桿、不合理的保證金表設計、突發性的參數調整導致大量倉位觸發強平，以及不恰當地使用緊急控制（如暫停交易）。

這些風險大多是決定性的且可預防的。只要足夠謹慎、審核嚴格並保持營運紀律，大多數內部配置錯誤是可以避免的。雖然很重要，但這並非 HIP-3 下結構性挑戰最大的風險。

1. setOracle

預言機價格通常來自開發者運行的中繼服務器（relayer servers），這引入了中心化風險。如果私鑰洩露或中繼服務器遭受 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 / 最大槓桿），但此限制對低波動資產來說仍可能過於寬鬆。在此範圍內的價格波動仍可能觸發 大規模強平甚至 ADL 事件。

2025 年 12 月 14 日，trade.xyz 上的 XYZ100-USDC 市場（追蹤 NASDAQ-100 的永續合約）遭到操縱。攻擊者做空了 398 XYZ100（約 1,000 萬美元 USDC 的名義敞口），導致嚴重的價格脫鉤。大量多頭倉位被強平，而強平行為進一步拉低價格，最終導致約 1,300 萬美元 USDC 的多頭平倉。

這是週末「成長模式」機制下可能發生的第一次此類行動。有人重擊市場，在一分鐘內將 XYZ100 的價格拉低了超過 3%，並強平了價值約 300 萬美元的倉位 pic.twitter.com/XttBHfTB0D
— bart.hl (equity perps era) (@bartdothl) December 14, 2025

另一面，在非交易時間，缺乏持續且外部錨定的 預言機價格，迫使市場依賴由「最後外部價格 + 內部訂單簿」形成的 約束性內部定價帶（例如，trade.xyz 將最大波動限制在 1/最大槓桿）。

最關鍵的風險出現在 市場恢復交易的轉折點。外部市場會突然提供一個 清晰且具備權威性的參考價格。如果該價格與內部非交易時段的定價存在顯著差距，系統將面臨兩條不利路徑：結果要麼是價格保持 錨定（clamped），導致外部公允價值與可交易價格之間嚴重脫離；要麼是系統迅速恢復外部錨定，觸發 突發性的重新定價。這兩種情況都可能導致平倉壓力在短時間內集中爆發，極端情況下更會導致 ADL 事件激增。

0x3 開發者風險控制

僅靠配置紀律無法消除風險。最有效的緩解策略是對准 降低對預言機依賴失敗的暴露。

0x3.1 選擇穩定的預言機

對於 非 24/7 交易的資產（如股票），主要挑戰在於 非市場交易時段的定價。在此期間，穩定且獲得外部錨定的參考價格極其稀缺，使得市場在薄弱的流動性下更易遭受操縱或內生漂移。

目前，業界的處理方式大致分為兩個方向：

在非交易時段暫停預言機更新並限制交易。例如，Lighter 協議僅接受「僅減少倉位 (reduce-only)」訂單，並在底層市場關閉時停止交易。Ostium 等協議則在非市場時間進一步降低最大槓桿，並強制平掉超出限制的倉位。
採用「內部定價」機制，如 trade.xyz，協議在外部數據不可用時，依靠內部流動性和定價算法在非交易時段繼續運作。

這兩種方式反映了 安全性 與 用戶體驗 之間的基本權衡。第一種優先考慮嚴格的風險控制，但顯著降低了交易的連續性和用戶體驗。第二種維持了連續交易，但由於缺乏外部參考，增加了內部價格偏離資產基本價值的風險。

在非交易時段，協議定價應避免完全退化為 純粹的內部價格。相反，引入 外部參考錨點 可以降低脫鉤和價格震盪風險。可能的參考資源包括：

Blue Ocean ATS。作為一個盤後/隔夜交易場所，它可以在休市期間提供一定程度的 連續價格參考（比「最後收盤價」更具時效性），協助生成休市期間的預言機價格，或作為脫鉤監測的基準。
IG 週末 CFD 報價。週末 CFD 報價可以提供一個 反映「週末市場預期」的替代價格信號，適合在休市期間作為外部錨點或監測指標，幫助預先檢測「開盤跳空」可能的方向和幅度。

這些來源共同的特點是能夠在非交易時段提供價格信號。然而，它們並不與底層現貨市場具有相同的市場結構，因此更適合作為錨點、參考或早期預警信號，而非無條件的替代品。

0x3.2 價格驗證

在 HIP-3 下，預言機價格源自 開發者運行中繼器服務器，這引發了對 中心化 的擔憂。為減輕此風險，鼓勵開發者建立一個 價格驗證框架，允許任何用戶或機構在鏈下驗證定價的正確性與公平性——類似於 RedStone，將價格與數據來源和加密證明打包在一起。

1. 數據透明度

算法規範：公開定價算法與計算邏輯。
數據來源清單：所有來源應是公開的、不受開發者操縱，並記錄有詳細的接口與參數。
價格提交規則：setOracle 的權限、觸發條件、更新頻率及波動約束。

2. 價格證明 (Price Proofs)

為每一筆 setOracle 調用生成相應的證明，包含：

輸入：採樣時刻每個數據源的原始（或歸一化）響應。
計算：每一個計算步驟中可重現的可導中間值。
輸出：鏈上提交的預言機價格。

每個證明被序列化為 proofHash，並由 oracleUpdater 簽名。

3. 鏈上承諾 (On-Chain Commitments)

在 Merkle 樹中維護 proofHash 條目的順序列表。
定期（例如每小時或每天）在鏈上發布 MerkleRoot。

4. 驗證

提供開源工具或網頁，讓用戶輸入時間範圍或 setOracle 交易雜湊（transaction hash）。
驗證簽名、時間戳和 MerkleRoot 等。
使用公共算法重新計算預言機價格進行對比。

0x3.3 風險監控

價格驗證使得 setOracle 可以 重計算 與審計，確定數據餵價是否可信。然而，它不能保護市場免受運行時惡化的影響。餵價中斷、價格偏離和流動性惡化——如果結合大量的未平倉合約 (OI)——很容易將局部異常升級為 系統性風險，如連鎖平倉甚至 ADL 事件。

因此，必須儘早將市場異常檢測出來並轉化為 可觀察的信號，並在規定的時間窗口內處理，以將風險控制在可管理的邊界內。

為了使監控機制具有實操性而非支離破碎，我們將信號分為三層，每一層對應不同的故障模式與響應優先級。

價格端監控：檢測預言機餵價失敗與脫鉤狀況，這些狀況會從源頭導致風險控制失效，因此優先級最高，通常通過中繼器切換、未平倉合約上限和降低槓桿來處理。
訂單簿端監控：捕捉流動性撤離和虛假深度（spoofed depth），這些行為會放大清算滑點與缺口風險，因此介入重點在於限制增量敞口，並在市場脆弱性增加時強制減倉。
倉位端監控：追蹤未平倉合約的快速積累及單邊集中風險，這些風險使得市場容易受到連鎖反應影響，整體優先級低於價格與流動性信號，主要作為早期預警層，為限制上限和提高警示提供參考。

以下章節按順序詳細說明每一層，以及相應的監控點與建議行動。

1. 價格端監控

a) 預言機餵價失敗

指標：

使用鏈上可觀察數據判斷餵價是否停滯：

閾值：

第一級：( ∆t > 5s ) — 中繼進程可能已停滯或被阻塞
第二級：( ∆t > 15s ) — 鏈上價格可能已嚴重脫鉤且越來越多地由市場驅動

行動：

第一級：執行中繼器健康檢查，切換至備用中繼器，並發布帶有健康診斷的警告
第二級：調用 setOpenInterestCaps 以降低 OI 上限

b) 價格脫鉤

指標：

信號 A (d1)：標記價格與預言機價格之間的偏離。

信號 B (d2)：訂單簿中間價與預言機價格之間的偏離。

信號 C (d3)：標記價格與中間價之間的偏離。

信號 D (ext_diff)：預言機價格與外部參考價格之間的偏離。

閾值邏輯：

第一級：A、B、D 中至少有 2 個超過閾值。
第二級：A、B、C、D 中至少有 3 個持續超過閾值 X 秒。

行動：

第一級：通過 setOpenInterestCaps 降低 OI 上限。
第二級：逐步更新保證金表以降低分級最大槓桿，並在中繼器上啟用錨定機制。
第三級：持續維持第二級警告狀態。開發者評估是否調用 haltTrading。

2. 訂單簿端監控

a) 流動性撤離

指標：

depth_band(±x%)：在中間價 ±x% 範圍內的訂單簿流動性。
spread = bestAsk - bestBid：價格點差，用於衡量點差加寬。
aggressiveVolume_Δt：Δt 期間的吃單成交量（按交易方向聚合）。
impact_ratio：市場脆弱性指標（值越高，價格受到衝擊的機率越大）。

風險模式：

depth_band 下降，同時 spread 與 impact_ratio 增加。

行動：

第一級：通過 setOpenInterestCaps 設置 OI cap = 當前 OI，限制新增倉位。
第二級：通過 setMarginTableIds 強制減倉，同時清算 高槓桿、高風險倉位。

b) 虛假流動性

風險模式：

depth_band 在短時間內突然飆升隨後崩潰。

行動：

第一級：調用 setOpenInterestCaps 使 OI cap = 當前 OI。
第二級：如果 結合嚴重脫鉤，考慮暫停市場。

3. 倉位端監控

倉位端監控不試圖 預測價格方向。相反，它識別交易活動從 平衡交易 到 單邊倉位累積 的轉變。當 OI 快速積累、倉位高度集中且多數方盈虧達到極端時，只需微小的外部衝擊就可能引發清算級聯或 ADL 事件。

因此，倉位端措施的 優先級通常低於 價格端和訂單簿端的干預。

a) 過度的短期 OI

指標：

OI_notional：未平倉合約名義金額。
Volume_24h_notional：24 小時名義交易量。

此比率快速成長，表明交易性質從活躍換手轉向投機倉位積累，通常預示著劇烈波動的到來。

行動：

第一級：超過閾值時觸發警告。

b) 多數方盈虧 (Majority-Side PnL)

多數方 指的是在觀測窗口內，持倉人數較多的一方（多頭或空頭）。

指標：

avgEntry_major：多數方倉位的平均入場價。
size_major：多數方的倉位大小總和。
equity_major：多數方的總權益。

多數方盈虧及其比率定義如下：

行動：

第一級：超過閾值時警告。
第二級：如果異常持續，考慮調用 setOpenInterestCaps 降低 OI 上限。

0x4 結論

HIP-3 的核心敘事十分簡明。它將市場上架流程從少數人控制的自主行為，轉變為 任何合資格開發者在滿足要求後即可調用的協議層級功能。通過質押，開發者可以在 HyperCore 上啟動自己的永續合約 DEX、免費上架初始合約，並通過拍賣獲取額外插槽。這將市場擴張從被動等待審批轉變為 基於規則、無需許可的擴展。

同樣清楚的是，HIP-3 並未消除風險。它 重定位並重塑了 風險。過去由平台層面風險控制所吸收的責任，現在大部分由開發者通過其輸入和營運品質來承擔。這包括通過 setOracle 進行預言機定價與更新、markPx 的選擇與約束、通過保證金表設計的分級槓桿、非 24/7 資產的非交易時段定價範圍，以及如 haltTrading 這種既可以遏制損失亦可放大損失的強力控制。在流動性薄弱情況下，配置錯誤或操作失敗會被放大為清算級聯、脫鉤虧損，並最終演變成 ADL 事件。問題不再是 「市場能被上架嗎？」，而是 「市場在上架後能保持穩定嗎？」。

在協議層面，Hyperliquid 通過將許可權轉化為可問責的許可權來應對這種風險再分配。質押與驗證者治理下的削減機制相結合，為開發者的不正當操作建立了明確的經濟後果。對定價與槓桿的限制——包括錨定、更新間隔、波動限制及隔離保證金要求——旨在將最危險的尾部風險控制在有限的範圍內。在這個框架下，HIP-3 的價值主張清晰可見：通過開放實現擴展，通過限制確保安全，通過可驗證性與問責制實現長期永續。

HIP-3 並未讓上架變得更無序，而是使其 更標準化、更具備可部署性、可操作性與可削減性。這種標準化能否大規模運行，最終取決於預言機設計、槓桿與風險參數配置、以及運行時監控在真實世界中的執行品質。如果您正在 HIP-3 之上設計市場准入規則、參數模板、警報系統或應急工作流程，或者需要代碼審計及持續的安全支持，歡迎聯繫 BlockSec：[email protected]。