作者：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 萬CUSDH 被注入對項目鎖定到未向本總無謂損失約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 集成。
