安全审查

审查范围

Exchange 及其管理模块的源代码、它链接的各个库、订单、赔付和强平逻辑、充值与提现、会话密钥、批量执行器、充值代理、质押、代币及其奖励。审查所读的代码是提交 e456c4d（2026-11-06）时的状态。链下服务、各个应用和部署脚本不在范围内。

结论

审查在合约代码中没有发现严重或高危缺陷。每一条转移资金的路径都逐行读过，且都经受住了检验。最近新增的代码（质押、代币和钱包平仓）受到的审查最少；它已被完整阅读，其中的质押记账还按下文所述做了测试。

经受住检验的部分

• 访问控制。 每个会改变状态的函数都先检查调用者，然后才做任何改动。管理模块不能被单独使用。所有权无法放弃，只有所有者能升级合约。
• 签名。 类型化消息带有链和验证合约，拒绝可延展的签名，每个 nonce 只用一次，且只在签名验证通过后才消耗，并且会过期。会话密钥不能签署只属于钱包的消息，钱包也不能签署交易，一次撤销所有密钥也有效。
• 资金流向。 池中现金、记账资金池、赔付队列和专用桶之间的账目保持一致。没有未检查的算术，缩窄转换都有检查，每一处取整都朝设计规定的方向。费用有上限，提现会先扣减余额，再发出 Hyperliquid 操作。
• 重入。 每个转移资金的函数都防重入，并且先写状态再做外部调用。代币钩子使用固定的 gas 额度，因此调用者无法强行让它延后执行。
• 充值地址。 充值代理只能通过 Exchange 发送 HyperCore 操作，其所有者只能从中转出 EVM 代币和原生 HYPE。地址的推导方式没有改变。
• 代码模式。 没有 selfdestruct、tx.origin、.transfer、.send 或 callcode。仅有的 delegatecall 指向管理模块和已链接的库。
• 会销毁的代币。 BACK 在铸造的那一刻就被质押，并在 7 天 后、到下一个 UTC 零点销毁。在记账资金池首次达到 $500,000 之前，倒计时不会开始。每个批次的到期日、对账户批次的惰性遍历、全局计划、重放的铸造以及倒计时的开始，都与这一设计一致，详见收益与领取。

质押记账是如何测试的

我们只根据已公布的规则另写了一个模型，没有读合约的算术。随机序列包括铸造（含延迟重放）、倒计时开始、分配、领取和时间跳跃（跳到午夜前一秒、正好午夜、按天，以及最长 150 天的空闲），它们同时在合约和模型上运行，并在每一步之后比较。在 76,800 次调用以及另外 38,400 次含长时间空闲的调用中没有出现差异：有效余额和供应量完全一致，奖励在取整误差内一致，没有账户能领取超过预留的数额，每次领取付出的恰好是待领数额。另外，我们故意加入的两个缺陷都被发现了。

发现

未覆盖的部分

• 只读的查询合约、市场管理库和边界库只是浏览过，没有逐行审查。
• 完整的测试套件，以及存储布局、接口、合约大小和充值代理代码的检查，这次审查没有重新运行。我们依据的是上一次完整运行的结果。
• 针对 Hyperliquid 的分叉测试、除角色检查之外的部署脚本、链下服务和各个应用。
• 2026-11-08 改动后的代币铸造规则（盈利不抵消、无上限）、代币钩子的 gas 行为，以及 Hyperliquid 的预编译合约是否如测试所假设的那样工作。

如实对待本页

这只是某一时间点的一次审查。上面这个提交之后对合约所做的改动，本页一概不涉及。合约可以在时间锁之后升级，所以任何时候部署的是什么，都必须对照合约地址核实。