作者: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 的區塊轉換內運行,無需外部運營方。
motivation
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 流動性之間分配。
Fair price discovery: Continuous liquidation auctions discover market prices across multiple blocks, minimizing the impact of time-based gaming commonly seen in traditional auctions.
Align quote asset growth: Create utility for the quote asset to increase its TVL and generate returns for the assistance fund.
吸引建設者:團隊可以在 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 激活。
Transfer the remaining amount to the project team's wallet.
Return unsold tokens to the project team.
解除代幣凍結,現貨交易、轉賬和 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 萬 USDH 被鎖定至 HIP-2 注入(不返還給項目方)。總無謂損失約為 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)。每個操作都是對聚合刻度預算的比較與加法,其成本與現有现货訂單簿的匹配成本相當。無需新的密碼運算或外部讀取。
未來工作項目
以下超出本 HIP 的範圍,但隨著 HIP-6 成熟應評估的自然擴展:治理對協議常數的審查;批量清算(每 K 個區塊清算一次);非線性釋放計劃;分批 HIP-2 注入;HIP-2 儲備機制;認領到期和狀態清理;UI 集成。


