北京时间 8 月 12 日，Hyperliquid 创始人 Jeff Yan 在官方 Discord 频道发布了一项技术更新公告。由于该动态表述较为硬核且偏向底层技术细节，许多用户可能未能充分意识到其背后的深远意义。
原文直译
以下是 Jeff Yan 发布的原始内容翻译：
- 基于开发者社区的反馈，HIP-1 协议将新增一个由代币部署者控制的函数：scaleWei { token, totalWei, referenceToken, systemAddress }。
- 该函数的作用是根据用户持有的 referenceToken 余额占比，自动将 systemAddress 中的 token 总供应量（totalWei）按比例分配给相关用户。计算时将采用向下取整策略，且排除 systemAddress 自身参与分配。例如，当 token 与 referenceToken 相同时，此功能可用于实现代币的重新计价（redenomination）。
- systemAddress 可指向两种地址：一是 Core 至 EVM 桥接的系统地址；二是由部署者指定并提供签名的 Treasury（国库）地址。值得注意的是，EVM 环境原生并不支持此类原子化操作。若目标代币同时存在于 EVM，相应的智能合约需集成自定义逻辑，以确保该操作能同步反映在 EVM 端的代币余额上。
- 当 token 和 referenceToken 为同一代币时：所有未成交订单（Open Orders）将被自动撤销，随后按照实际的 redenomination 比例重新生成。重挂单时会依据 szDecimals 设定的精度进行向下取整处理；此外，totalWei 允许传入负值，从而支持反向的 redenomination 操作。
- 诚邀各位开发者提供反馈意见，以确保该功能能够最大程度地契合实际业务需求。
对于不熟悉智能合约机制的用户而言，这次更新的具体含义可能显得晦涩难懂。
通俗解读
简而言之，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 交易的系统而言，此类处理“公司行为”的能力本就是必备基础。
场景三：Rebase（弹性供应）
类似的机制同样适用于 Rebase 场景。简单来说，即资产总量或单位发生变更时（常见于盘前股票代币转换期间，股本数量随之调整），但用户间的相对持仓比例维持不变。
过去，此类操作往往依赖代币合约内部逻辑，而今后将成为 HyperCore 的原生功能。
场景四：空投分发
另一个直观的应用则是空投。referenceToken 无需等于被分配的 token，这意味着理论上可以直接依据 A 的持仓比例来分发资产 B。
例如，某项目决定向特定 HIP-1 资产持有者分发另一种代币，系统可直接读取用户在 HyperCore 上的 A 余额，并按比例从指定的 Treasury 地址分配 B 代币。
这表明，至少在 HyperCore 内部，传统意义上的“领取空投”动作有望进一步简化为系统自动完成的余额分配。
补齐链上股票的“公司行为”短板
需要强调的是，Jeff Yan 此次更新的初衷仍侧重于底层功能的完善，并不代表 Hyperliquid 已正式宣布将对平台上的股票代币实施分红，但从基础设施构建的角度来看，上述应用场景所需的“按持仓比例向账户分配资产”能力已具备成熟的技术路径。
综合潜在应用来看，Hyperliquid 此次更新的核心意义在于，有望填补链上资产在处理“公司行为”方面的能力空白。
在过去几年关于代币化股票的讨论中，行业焦点多集中于“股票能否上链？”这一基础问题。然而，若真要真正将股票迁移至链上，挑战远不止于此。股票发行后，还将频繁涉及分红、拆股、合股、配股、资产分配等一系列公司行动。
因此，完整的链上股票基础设施，不仅要支持“股票交易”，还需能够妥善处理这些交易之外的资产状态变更，而这正是 Hyperliquid 此次更新所着手解决的关键部分。
从这个维度审视，scaleWei 更像是在为 Hyperliquid 的下一阶段补全一块关键的基础设施拼图 —— 让链上的金融资产不仅具备“可交易性”，还能像现实世界的金融资产一样，灵活应对各类公司行为。