鏈上 IPO 的終極形態？ Hyperliquid HIP-6 提案全解析

BTCC / BTCC Square / TechFlowPost /

Author:

TechFlowPost

Published:

2026-03-02 03:01:05

作者：James Evans （@jimbo_evans）

編譯：深潮 TechFlow

這是一份完整的 Hyperliquid 改進提案，提議在協議層引入連續清算競拍機制，讓新代幣項目方可以在鏈上完成資本和流動性啟動的全流程，第三方或流動性地完成交易所

作者藉鑒了 Uniswap 的連續清算競標模型並針對 HyPErliquid 的訂單簿環境做了重新設計，提案技術細節極為完整，覆蓋從配置到結算到安全考慮的每一個環節。

全文如下：

特別感謝 @fiegemax 提供想法、指導和回饋，也感謝 @ARnx813、@0xBroze、@0xOmnia、@xenoflux、@happenwah、@const_hom 和 @DougieDeLuca 的審與閱意見。

揭露：本人在個人帳戶中持有 $HYPE。本人任職於 @recvcx，但本文僅代表個人觀點，不代表 RecIProcal Ventures 的立場。

摘要

HIP-6 為 HIP-1 資產引入了無需許可的代幣發行競標機制，專為在 @HyperliquidX 上原生發行代幣的團隊設計。此機制將 @Uniswap 的連續清算競拍（CCA）適配到 Hyperliquid 的訂單簿（CLOB）原生環境中。專案方在競標註冊時從協議認可的對齊報價資產中選擇一種報價資產（如 USDH），為這些資產創造新的需求和實用性來源。競拍收益歸專案方所有，其中可配置的一部分將在競拍結束窗口透過成交量加權均價自動為 HIP-2 注入流動性。所有競拍邏輯在 HyperCore 的區塊轉換內運行，無需外部營運者。

動機

HIP-1 和 HIP-2 支援無需許可的代幣部署和自動化流動性，但對新代幣的資本形成和價格發現支持不足。在 @HyperliquidX 上原生發行代幣的團隊仍然在很大程度上被迫在鏈下募集資金、用自有資金手動為 HIP-2 注入流動性，以及/或在單薄的訂單簿上完成上線。由於這些摩擦，Hyperliquid 在 ICO 能力上尚未與其他高性能生態和交易所達到產品對等。 @solana 有 @metadao，@base 有 @Uniswap 的 Liquidity launchpad 和 @dopplerprotocol，@coinbase 有 @echodotxyz。 HIP-6 是可選的，但透過實現更有效率的資本形成和價格發現，HIP-6 支持希望在 Hyperliquid 上建立完整專案生命週期的創始人，並推進 Hyperliquid 成為承載所有金融的區塊鏈這一目標。

HIP-6 透過以下方式改善 Hyperliquid：

鏈上資本形成：團隊可以在單一流程中在 Hyperliquid 上原生募集資金，收益在專案方和自動注入 HIP-2 流動性之間分配。

公平的價格發現：連續清算競拍在多個區塊內發現市場價格，最大程度減少傳統競拍中常見的時間博弈影響。

對齊報價資產成長：為對齊報價資產創造實用性，進而增加其 TVL 並為援助基金產生收益。

吸引建造者：團隊可以在 Hyperliquid 上完成代幣的完整生命週期。在 Hyperliquid 上發行更多代幣意味著援助基金獲得更多交易費用。

參與者保護：已承諾的資金在競標期間由 HyperCore 的狀態託管，不在專案方的託管中，也不由受信任的第三方託管。

關於命名：本提案編號為 HIP-6，因為 HIP-5 先前已被分配給另一份獨立提案。

我們在什麼基礎上建構

HIP-6 將 @Uniswap 的連續清算競標適配到 Hyperliquid 的 CLOB 原生環境中。 CCA 將一個大型競拍分解為 N 個相互遞進的小型競拍。每個區塊，協議釋放一批代幣併計算統一清算價格。價格發現是逐漸發生的，而非在某個單一時刻完成，競標者受到激勵更早參與，而非等待。

各種替代方案都有明顯缺陷：

固定價格銷售：價格發現效果差，因為需要有人猜中開盤時的正確價格。價格設低了，專案就損失了差價；價格設高了，銷售就會失敗。

有上限的比例分配銷售：修復了價值洩漏，但會製造超額認購螺旋。在實踐中，如果銷售被 2 倍超額認購，理性參與者會存入 2 倍的目標配額，使其更加超額認購，如此往復。這是糟糕的使用者體驗。

無上限銷售：避免了螺旋，但會導致過度募資。一個用 500 萬就能建造的項目募集了 5000 萬，因為沒有任何東西阻止它。 2017 年 ico 浪潮展示了這種方式的後果。

傳統競拍：讓市場發現價格，但會製造時間賽局。最優策略是盡可能等到最後。這對非機構參與者造成了更糟糕的使用者體驗。

動態聯合曲線：將荷蘭式拍賣與需求響應式聯合曲線結合。這在 AMM 原生環境中效果良好，但不適合 Hyperliquid 的 CLOB 原生環境。

HIP-6 之上可以建構什麼

HIP-6 解決了資本形成和價格發現問題：新專案如何在 Hyperliquid 上募集資金和注入流動性。它不涉及特定代幣的價值累積機制、代幣持有者的保護措施，或特定項目的治理方式。這些是獨立的問題，我們期待團隊在 HIP-6 之上建構來解決。

未來專案可以在 HIP-6 之上建構的範例：

價值累積機制：規定協議收入如何回流給代幣持有者（如費用分配、回購、質押獎勵）。

治理架構：賦予代幣持有者對金庫分配、參數變更和/或協議升級的投票權。

代幣持有者保護：提供金庫鎖定、鏈上報告要求和/或歸屬機制等工具，對買家和團隊配額均施加鎖定。

HIP-6 的目標是使初始競拍盡可能公平和有效率。競標結束後發生什麼，是 Hyperliquid 社群的設計空間。 HIP-6 不阻止團隊與做市商合作以加強其專案的訂單簿流動性。

公開文件草稿

以下是 HIP-6 如何在 Hyperliquid 公開文件中呈現的草稿。此處包含它是為了讓審閱者預覽面向使用者的描述。

HIP-6：代幣發行競標

HIP-6 為 HIP-1 資產引入無需許可的代幣發行競標。專案方透過連續清算競拍提供其代幣供應量的一部分出售。競拍者以對齊報價資產（目前為 USDH）承諾資金。競標者指定其總預算和每個代幣願意支付的最高價格。競拍隨後將該出價分散在競拍剩餘區塊中。競拍的每個區塊，協議以固定速率釋放代幣。協議隨後將已釋放代幣的供應與競標者的需求相匹配，為每個區塊找到統一清算價格。結算時，向援助基金發送協議費用，一部分收益按照競拍最終窗口發現的價格自動為 HIP-2 Hyperliquidity 注入流動性，其餘部分歸項目方。所有競拍邏輯在 HyperCore 的區塊轉換內運作。

部署競拍

專案方在完成標準 HIP-1 部署步驟（registertoken2、userGenesis（如有）、genesis 和 registerSpot）後呼叫 registerAuction。項目方指定以下參數：

auctionSupply：出售的代幣總量。註冊時從專案方的現貨帳戶轉入協議託管。

duration：以區塊為單位的競拍時長，最長 3,024,000（在 0.2 秒/區塊下約 1 週）。

floorPx：最低清算價格，預設為 0。

startDelay：註冊到第一個清算區塊之間的區塊數，最小為 1，預設為 1。

minRaise：競標成功所需的最低報價資產募集量，預設為 0。

quoteAsset：必須是協議認可的對齊報價資產（如 USDH）。

hip2Seed：淨收益（扣除協議費用後）自動注入 HIP-2 的基點數。範圍 2,000 至 10,000，預設為 2,000。

hip2OrderSz 和 hip2NOrders：HIP-2 訂單大小和訂單數量，必填。

所有參數一旦註冊即不可更改。每個代幣的轉帳凍結在註冊時激活，阻止對該代幣的所有現貨訂單、轉帳和 Hyperevm 操作，直到結算。專案方可以在競標 startBlock 之前（即在 startDelay 期間內）透過 cancelAuction 取消競標。

出價

競標者調用 submitBid，指定預算（最低為報價資產的 100 單位）和 maxPx（每個代幣的最高價格，向下取整到競標刻度網格）。預算在提交時被託管。每次出價收取 1 個報價資產的不可退還費用。預算自動均勻分散到剩餘競拍區塊。在區塊 h 中提交的出價從區塊 h+1 開始有效參與清算。在 startDelay 期間提交的出價在第一個清算區塊啟動。

競標者可以提交多個具有不同最高價格的出價來表達需求曲線，但每個競拍最多 100,000 筆出價。只有當出價的 maxPx 嚴格低於最近清算價格時，競標者方可撤回出價。

清算

競標期間的每個區塊，協議以固定速率（auctionSupply / duration 每區塊）釋放代幣，並透過從最高到最低遍歷已佔用價格刻度，直到累積需求滿足供應，來計算統一清算價格。高於清算價格的出價獲得完整配額。在清算價格處的出價以每區塊預算比例共享剩餘部分。低於清算價格的出價什麼都得不到。競標價格網格使用 1.003 的幾何刻度間距，與 HIP-2 一致。

結算、HIP-2 啟動和認領

在競標結束後的第一個區塊，如果設定了 minRaise 但未達到，競拍失敗。所有對齊報價資產被退還，所有代幣返還給項目方，凍結解除。如果 totalQuoteSpent 為零，無論 minRaise 如何，競標都失敗。

成功時，協議原子性地：

從總花費的報價中扣除 500 bp 協議費用，發送至援助基金。

分配 hip2Seed 用於 HIP-2 活化。

將剩餘部分轉移到專案方錢包。

將未售出的代幣回饋給專案方。

解除代幣凍結，現貨交易、轉帳和 EVM 作業恢復。

啟動 HIP-2，使用項目方指定的 hip2OrderSz 和 hip2NOrders。 hip2Seed 用於注入 nSeededLevels 個層級。起始價格為 seedPx，透過競標持續時間最後 5% 的成交量加權均價計算。

結算結束後，競標者透過 claimAuction 認領購入的代幣和未使用的報價資產。

費用

在 registerAuction 時收取 10 HYPE 註冊費。每次 submitBid 收取 1 個報價資產的費用。結算時對總收益收取 500 bp 協議費用。所有費用流入援助基金。專案方現有的 setDeployerTradingFeeShare 照常適用於競標後的現貨交易。

我們在什麼基礎上建構

HIP-6 Hy-CO 是嵌入在 HyperCore 區塊轉換邏輯中的連續清算競拍。競拍者以對齊報價資產（如 USDH）提交出價，每筆出價指定預算和最高價格。每個區塊，協議釋放一批代幣並為該區塊計算統一清算價格。最高價格嚴格高於清算價格的競標者獲得完整配額；恰好處於清算價格的競標者獲得剩餘部分，可能被部分成交。競標結束時，協議收取費用發送至援助基金，將可配置比例的剩餘收益按照競拍最終窗口計算的成交量加權均價注入 HIP-2 Hyperliquidity，其餘發送給專案方錢包。競拍結束時的結算是原子性的。

Hy-CO 生命週期

Hy-CO 有三個階段：

競標前：配置。項目方在完成標準 HIP-1 部署步驟後呼叫 registerAuction。協議驗證參數、託管代幣供應和賣方供應、啟動代幣凍結，並分配競標 ID。

競標中：出價。競標者可以在 startDelay 期間或競標過程中任何時點透過 submitBid 提交出價。預算在提交時託管，無論出價何時提交。清算。競標期間從 startBlock 開始的每個區塊，協議釋放代幣併計算統一清算價格。

競標後：結算。在 endBlock 之後的第一個區塊，協議評估競標是否成功並分配收益。 HIP-2 活化。成功結算後，HIP-2 使用 seedPx 和項目方指定的訂單參數自動啟動。認領。結算後，競標者透過 claimAuction 認領購入的代幣和未使用的報價資產。認領期間正常交易可進行。

取消：在 startBlock 之前任何時間均可執行 cancelAuction。它將 auctionSupply 和 hip2AskSupply 返還給專案方，解除凍結，並釋放競標槽位。如果在 startDelay 期間提交了出價，競標進入失敗路徑：競標者透過 claimAuction 取回託管的報價資產（與失敗競標相同的提取式退款路徑）。 auctionRegistrationFee 不可退還。清算開始後，競拍不可撤銷。

關鍵設計決策

為什麼是新 HIP 而非第三方產品：代幣發行是基礎設施，而非應用程式。如果每個團隊都建立自己的發行機制，生態系統將會碎片化。 HIP 意味著在 Hyperliquid 上發行的每個代幣（如選擇使用 HIP-6）都能獲得相同的公平價格發現和自動 HIP-2 注入，而無需外部依賴。這也意味著該機制由驗證者共識保障，而非第三人。

為什麼選擇 HyperCore 而非 HyperEVM：HIP-6 所需的一切都存在於 HyperCore 上。在 HyperEVM 上建置會引入不必要的複雜性，透過增加步驟和延遲來降低使用者體驗。

為什麼選擇連續清算競拍：傳統競拍製造獎勵速度而非估值的時間博弈；聯合曲線是路徑依賴的；固定價格銷售需要猜測正確價格。 CCA 將出價分散在時間上，每區塊以統一價格清算，並在數千個區塊內收斂，而不是在單一時刻解決。

為何只允許對齊報價資產：競標以對齊報價資產（目前為 USDH）計價。每次競拍在其持續時間內鎖定報價資產，成長 TVL 並為生態系統產生收益。支援 USDC 等非對齊資產會以邊際採用收益稀釋此效果。持有 USDC 的競標者可以透過標準介面進行轉換。

為什麼只預設線性釋放計畫：線性確保清算價格單調不遞減，這透過累積檢查點實現了高效的認領時記帳。非線性計劃（後置加權、前置加權）可能導致清算價格在每區塊供應量跳升時下降，使出價等級的記帳複雜化。這些可能在未來 HIP 中引入，前提是擴展記帳方案。

安全考量

專案方自我交易：專案方可以透過獨立錢包在自己的競標中出價，以誇大清算價格和 VWAP，然後在結算後取回未售出的代幣。緩解措施包括：協議費用使自我交易在所有自我交易量上成本高昂；seedPx 在覆蓋競拍最後 5% 的 VWAP 窗口內計算，需要持續支出才能操縱；minRaise 導致競拍在真實需求不足時失敗；所有出價在鏈上可見，使自我交易可檢測。量化來說，一個專案方運行 100 萬 USDH 競拍（protocolFee = 500，hip2Seed = 2000），透過獨立錢包出價 40 萬 USDH（佔總量的 40%）：損失約 2 萬 USDH 到援助基金（5% 協議費用，不可恢復），約 7.6 萬。總無謂損失約 9.6 萬 USDH，或自我交易資金的 24%。成本隨自我交易量線性成長。

種子價格操縱：HIP-2 的 seedPx 使用覆蓋競標持續時間約最後 5% 的窗口化 VWAP，而非最後一個區塊的清算價格。操縱 VWAP 需要在視窗內的多個區塊持續支出，而非單次後期注入，使成本與視窗的總成交量成正比。

資金安全：競標者的報價資產和競標代幣在整個過程中由協議託管。資金永遠不在專案方的託管中。失敗時，所有報價資產透過 claimAuction 退還，所有代幣返還給專案方。

代幣凍結執行：所有代幣轉帳（現貨訂單簿、點對點、HyperEVM）在活躍競標期間被凍結。這防止持有 userGenesis 配額或保留專案方供應的內部人員在價格發現期間透過非競標管道出售代幣。

出價啟動延遲：出價在提交後的下一個區塊才參與清算。這防止區塊提議者或低延遲參與者觀察待處理出價並在同一區塊內插入反應性出價來影響清算價格。

對各方的影響分析

代幣項目方：Hy-CO 為專案方提供了在單一流程中募集資金和注入流動性的原生方式。專案方將競標與 HIP-1 部署一起配置，將收益收到錢包（減去分配給 HIP-2 的 hip2Seed 部分），並在市場發現的價格處獲得自動流動性注入。權衡是對初始價格的控制減少。

Hyperliquid 用戶：用戶獲得直接參與在 Hyperliquid 上建立的新團隊代幣發行的能力。目前沒有原生方式在上線時買入項目；用戶要么錯過初始分發，要么在 HIP-2 已註入後在公開訂單簿上買入。 Hy-CO 為用戶提供了統一定價和出價分散的公平入場機會，透過他們已在使用的相同介面存取。結算後，競標者必須呼叫 claimAuction 將購買的代幣和未使用的報價資產移入現貨帳戶後才能交易。代幣不會自動分發。現貨訂單簿僅以 HIP-2 流動性開盤，在做市商和其他參與者下單前不存在有機限價訂單深度。如果許多競拍參與者在認領後立即賣出，HIP-2 的買方層級可能會迅速耗盡。這是任何新上市的預期行為，並非 HIP-6 獨有，但前端應清晰顯示認領狀態，並設定早期競拍後價差將比成熟市場更寬的預期。

HYPE 持有者：Hy-CO 以兩種方式使 HYPE 持有者受益。首先，原生發行機制激勵新團隊在 Hyperliquid 而非競爭鏈上建置和發行，成長生態系統並將活動引向 Hyperliquid 的訂單簿。其次，以對齊報價資產（如 USDH）計價的競拍增長其實用性和儲備，作為透過援助基金補充 Hyperliquid 交易費用的循環收入來源。

流動性提供者和做市商：競標後，訂單簿以競標收益（透過 hip2Seed）資助的真實買方深度啟動，而非薄薄注入的 HIP-2。這為 LP 和做市商提供了更可信的起始價格和從第一天起就有更深的流動性來交易。

驗證者和狀態成長：單一競拍每個區塊的清算成本為 O（T），其中 T 是已佔用價格刻度的數量。在 tickSpacingFactor = 1.003 時，T 限於數千個刻度，但實務上大多數競標會有幾百個已佔用刻度。在 maxActiveAuctions = 16 時，最壞情況下每區塊工作量為 16 × O（T）。每個操作是聚合刻度預算的比較和加法，與現有現貨訂單簿相符的成本相當。不需要新的密碼操作或外部讀取。