Hyperliquid，也要支持幣股分紅了
- 核心觀點：Hyperliquid 為 HIP-1 標準新增 scaleWei 函數，賦予 HyperCore 餘額層直接進行按比例批量資產分配和重新計價的原生能力，為鏈上股票等資產補齊分紅、拆股等「公司行為」的基礎設施短板。
- 關鍵要素：
- scaleWei 函數允許根據用戶持有的 referenceToken 餘額，自動按比例將 token 從 systemAddress 分配給用戶，無需手動 Claim 或逐筆調用合約。
- 當 token 與 referenceToken 相同時，可執行拆股/合股等重新計價；系統會自動取消並按比例重建未成交訂單，以匹配新持倉體系，支持 totalWei 為負以反向操作。
- 在實際場景中，用戶持倉比例在拆分後保持不變（如 100:50:10 變為 1000:500:100），主要變化是計價單位與訂單規模。
- 該功能明確應用於股票代幣分紅：系統可直接按持倉比例分配分紅資產，替代傳統需用戶主動領取或項目方逐一轉帳的模式。
- 還可用於 Rebase 場景，在股本總數或單位調整（尤其盤前轉換）時保持相對持倉比例，也使空投可依據特定資產持倉比例直接由系統完成分配。
- EVM 環境不存在此原子化功能，若代幣同時存在於 EVM，智能合約需加入自定義邏輯才能同步操作，提示跨環境實施的技術權衡。
- 此次更新僅提供底層功能介面，未正式宣佈平台股票代幣分紅計劃，但為 Hyperliquid 承載真實金融資產的「公司行動」能力提供了技術路徑。
原創 | Odaily 星球日報（@OdailyChina）
作者 | Azuma（@azuma_eth）
北京時間 8 月 12 日，Hyperliquid 創辦人 Jeff Yan 在官方 Discord 頻道內公布了一則更新進展，由於原表述過於偏技術向，所以很多人都忽略或是低估了該則動態的意義。
字面直譯
以下為 Jeff Yan 原表述的直接翻譯。
- 根據 Builder 的回饋，HIP-1 將增加以下由代幣部署者控制的函數：scaleWei { token, totalWei, referenceToken, systemAddress }。
- 該操作會根據用戶所持有的 referenceToken 餘額，按比例自動將 token 的 totalWei 從 systemAddress 轉移給這些用戶。計算過程中會向下取整，並且不包括 systemAddress 自身。例如，當 token == referenceToken 時，這個功能可以用於重新計價（redenomination）。
- systemAddress 有兩種可能：Core → EVM 的系統地址；由部署者指定、並能夠提供簽名的 Treasury（資金庫）地址。需要注意的是，EVM 本身並不存在這種原子化（atomic）的功能。因此，如果相關 token 同時存在於 EVM 環境，那麼對應的智能合約可能需要加入自訂邏輯，才能將這一操作同步應用到 EVM 上的 token 餘額。
- 當 token 和 referenceToken 是同一個 token 時：所有未成交訂單（Open Orders）都會被取消，然後按照實際的 redenomination 比例重新創建，重新創建時會按照 szDecimals 的精度要求向下取整；totalWei 允許為負數。這樣就可以進行反方向的 redenomination。
- 歡迎大家回饋，以確保這一功能能夠盡可能廣泛地滿足實際使用需求。
顯然，如果不是對智能合約概念有一定了解基礎，便很難理解 Hyperliquid 的本次更新到底意味著什麼。
通俗解讀
簡單來說，Hyperliquid 正在給 HIP-1 增加一種此前並不常見的能力 —— 直接在 HyperCore 的「餘額層」對用戶資產進行批次、程式化的調整。
這裡最重要的並不是 scaleWei 這個函數名稱以及相關參數，而是它們到底可以做什麼。
假設 Hyperliquid 上存在一個代幣 A，現在 Alice 持有 100 枚，Bob 持有 50 枚，Charlie 持有 10 枚。如果某個地址裡有 1600 枚代幣 B，並以 A 作為 referenceToken，那麼系統就可以根據每個人持有 A 的比例，把這 1600 枚 B 自動分配出去。
分配狀況將為：
- Alice 持有 A 的比例為 62.5%，獲得 1000 枚 B；
- Bob 持有 31.25%，獲得 500 枚 B；
- Charlie 持有 6.25%，獲得 100 枚 B。
用戶不需要點擊 Claim，也不需要逐個呼叫智能合約，HyperCore 便可以直接按照既定規則修改帳戶餘額。
而如果 token == referenceToken，則將執行「重新計價」（redenomination），變化其實會更加直觀。
比如某隻股票代幣原本的持倉狀態是，Alice 持有 100 股，Bob 持有 50 股，Charlie 持有 10 股，現在進行一次 1:10 的拆股，那麼系統可以直接進行餘額調整。
調整之後的持倉狀況將為；
- Alice 持有 1000 股；
- Bob 持有 500 股；
- Charlie 持有 100 股。
每個人的持倉比例沒有發生變化，只是計價單位發生了改變。反過來也一樣。
Hyperliquid 在更新中還專門考慮到了交易中的訂單問題。如果一個資產發生 1:10 的拆股，用戶此前掛出的 100 股賣單顯然不能原封不動地保留，否則拆股後的訂單數量就與新的持倉體系不匹配。因此，系統會取消原有訂單，再按照新的比例重新創建，並根據 szDecimals 對數量進行精度處理。換句話說，這其實就是在讓餘額、訂單等交易狀態一起完成重新計價。
理解了更新邏輯，那麼這種「餘額層面的可程式化能力」究竟有什麼用呢？
應用場景
目前 Jeff Yan 公布的內容本身主要描述了 scaleWei 的底層能力，但圍繞這一能力，我們其實已經可以窺探出多個圍繞股票代幣的明確應用方向。
場景一：分紅
分紅是傳統股票最基本的權益之一。在傳統券商體系中，這是一項標準的公司行動；而在典型的 EVM 模式下，如果要做類似操作，通常需要透過智能合約記錄符合條件的地址，再讓用戶主動領取，或者由專案方逐一完成分配。
scaleWei 則提供了另一種可能 —— 直接根據 HyperCore 上的股票代幣餘額，將分紅資產按照持倉比例分配給用戶。假設未來 Hyperliquid 上出現某家上市公司的股票代幣，公司決定每股分紅 1 美元 —— Alice 持有 100 股，Bob 持有 50 股，Charlie 持有 10 股，系統即可直接按持倉比例將分紅資產分配至各自帳戶，不需要用戶手動 Claim，也不需要專案方逐個呼叫合約，HyperCore 本身就能完成這筆批次轉帳。
場景二：拆股與合股
這實際上是此次更新已經明確對應的場景。當 token 與 referenceToken 為同一資產時，scaleWei 可對所有持有者餘額進行統一比例調整。
因此，未來如果某個 HIP-1 資產需要 1:10 拆股、10:1 合股、甚至調整最小交易單位，都能直接執行，且系統會同步取消並重建未成交訂單。對於真正想承載股票、ETF 的交易系統而言，這類「公司行為」本就是標配。
場景三：Rebasing
類似的機制也可以用於 Rebase。簡單理解，就是資產本身的總量或者單位發生調整之時（尤其高發於盤前股票代幣轉換之時，股本數量會出現相應調整），但用戶之間的相對持倉比例保持不變。
此前，這類操作往往需要依賴代幣合約自身的邏輯，往後則可以成為 HyperCore 的原生能力。
場景四：空投
另一個比較直觀的場景，則是空投。referenceToken 不必等於被分配的 token，因此理論上可以直接按 A 的持倉比例去分配資產 B。
例如，一個專案決定向某個 HIP-1 資產的持有者分發另一種代幣，系統可以直接讀取用戶在 HyperCore 上的 A 餘額，然後按照比例將 B 從指定 Treasury 地址分配出去。
這意味著，至少在 HyperCore 內部，未來一些傳統意義上的「領取空投」動作，有可能被進一步簡化為系統直接完成餘額分配。
補齊幣股的「公司行為」短板
需要強調的是，Jeff Yan 此次公布的更新暫時僅聚焦於底層功能，並不意味著 Hyperliquid 已宣布將對平台上的股票代幣進行分紅，但從基礎設施層面看，上述應用場景所需要的「按照持倉比例向帳戶分配資產」能力已經有了對應的技術路徑。
綜合潛在的應用場景來看，Hyperliquid 本次更新真正的意義在於，有望補齊鏈上資產的「公司行為」能力短板。
過去幾年，行業討論代幣化股票時，關注點往往集中在 —— 「股票能不能被放到鏈上？」但如果真的想把股票搬到鏈上，問題其實遠不止這一件事。股票發行之後，還會不斷發生分紅、拆股、合股、配股、資產分配等一系列公司行動。
因此，真正完整的鏈上股票基礎設施，不僅需要能夠「交易股票」，還需要能夠處理這些交易之外的資產狀態變化，而這恰恰是 Hyperliquid 此次更新開始觸及的部分。
從這個角度來看，scaleWei 更像是在為下一階段的 Hyperliquid 補一塊基礎設施拼圖 —— 讓鏈上的金融資產，不只是「可以交易」，還可以像現實世界的金融資產一樣發生各種公司行為。
