Hyperliquid JELLY 事件始末 — 以及它对 DEX 治理意味着什么

• -1350 万美元 - JELLY 事件期间 HLP 的最高未实现亏 损
• ~20% - 事件期间 HYPE 的价格跌幅
• 560% - Binance 同日上线该代币后 JELLY 的价格飙升幅度
• 0.0095 美元 - 验证者强制结算价格，而当时现货价格约为 0.50 美元

目录

1. 简 短摘要
2. 攻 击是如何发生的
3. HLP 如何承担损失
4. 治 理层面的应对
5. “代码即法律 ”的争论
6. 协议层面的变更
7. 对活跃交易者的启示
8. 常见问题解答

2026 年 3 月下旬，Hyperliquid 上发生了一起协同操纵尝试，将一个低流动性的 Mem e 代币变成了一场链上治理的实时压力测试。JELLY 事件并未击垮 Hyperliquid，但它暴露出的断层是每一位严肃的 永续合约交易者都需要了解的——关于 DEX 治理的实际运作方式、当问题发生时谁掌握权力，以及当协议遭受攻击时，“去中心化” 在实践中究竟意味着什么。

这并非一篇针对 Hyperliquid 的抨击文章，而是对事件经过、揭示的问题以及它 对你在任何永续合约 DEX 上评估风险的启示的真实记录。

简短 摘要

一名交易者（或协同交易者群体）在 Hyperliquid 上建立了大量的 JELLY 永续合约空头头寸 ，随后蓄意操纵清算，迫使协议的流动性提供者金库 (HLP) 承担损失。HLP 的未实现亏损最高达到 1350 万美元，HY PE 价格下跌了约 20%。Binance 在同一天上线了 JELLY，引发了 560% 的价格飙升，使情况变得更加糟糕。

Hyperliquid 的验证者通过链下投票决定下架 JELLY，并将所有剩余头寸强制结算在 0.0095 美元——而当时该代币在现货 DEX 上的交易价格约为 0.50 美元。该结算价格并非市场价格，而是为了保护 HLP 的偿付 能力而设定的。

这一决定奏效了，但也引发了关于 Hyperliquid 上去中心化治理究竟意味着什么的严重质疑 。

攻击是如何发生的

三个账户，一场协同操作

Arkham Research 确定了事件核心的三个钱包：地址以 0xde9、0x 20e 和 0x67f 开头。其操作手法已被 Arkham 记录，并被 CoinDesk 和 Decrypt 详细报道，遵 循了清晰的模式。

主账户 (0xde9) 开立了名义价值约 410 万美元的 JELLY 永续合约空头头寸。两 个辅助账户 (0x20e 和 0x67f) 同时在同一代币上分别开立了 215 万美元和 190 万美元的多头头寸。

这并非标准交易，而是一场旨在利用 Hyperliquid 处理低流动性代币清算机制的协同布局。

将头 寸倾倒给 HLP

空头头寸被蓄意清算。当 Hyperliquid 上的头寸过大，无法通过正常的市场流动性平仓 时（尤其是在低流动性代币中），清算引擎会将剩余头寸传递给 HLP（协议的后备流动性金库）。

HLP 由 HYP E 质押者和协议参与者资助，充当做市商和最后防线保险人。通过制造足以压垮现有流动性的清算，攻击者实际上将有毒的空头头寸直接 转移到了 HLP 的资产负债表上。

辅助账户持有的多头头寸并未被清算，它们旨在从随后的任何价格飙升中获利——这 正是 Binance 几小时后上线 JELLY 时发生的情况。

Halborn 的事后安全分析将此次攻击描述为 对低流动性永续合约与 Hyperliquid 的清算至 HLP 回退机制之间交互的蓄意利用。这在传统意义上不是一个漏洞，而 是系统处理资不抵债头寸设计逻辑的必然结果。

HLP 如何承担损失

由于 HLP 在 JELLY 价格飙升时持有了继承的空头头寸，其未实现亏损最高达到 1350 万美元。在事件期间，由于交易者计入了更广泛的 HLP 资不抵债风险，HYPE 价格下跌了约 20%。

Binance 上线 JELLY 并非与攻击协同（没有证据表明这一点），但对于 HLP 而言，时机是灾难性的。在 HLP 持有大量空头头寸的代币上出现 560% 的价格飙升，压缩了任何有序解决问题的窗口。

OAK Research 指出，此次攻击暴露了一个结构性脆弱点：HLP 虽然在正常条件下资本充足，但并未构建为能够吸收这种规模的低流动性代币协同操 纵。保险基金虽然存在，但价格变动的速度和幅度几乎没有给自动化风险控制留出响应空间。

治理层面的应对

Hyperliquid 的验证者投票下架了 JELLY 永 续合约，并将所有未平仓头寸强制结算在 0.0095 美元。该决定是通过验证者协调在链下做出的，而非通过任何链上治理机制或社 区投票。

0.0095 美元的结算价格远低于当时的现货价格。持有 JELLY 永续合约多头头寸的交易者（包括那 些与攻击毫无关联的交易者）被迫以一个与现货市场价格完全脱节的价格平仓。

验证者投票揭示了什么

Hyperliquid 将自己定位为去中心化协议。JELLY 事件的应对表明，一小部分验证者在实践中可以就结算价格和市场下 架做出单方面决定——无需链上投票，也无需提前通知交易者。

这并非 Hyperliquid 所独有。大多数自称去 中心化的协议都有某种形式的特权参与者——多签、基金会或验证者集——可以在紧急情况下进行干预。JELLY 事件只是让这一现实 变得可见且具体。

CoinDesk 对该事件的报道强调了 Hyperliquid 的去中心化叙事与实际决策过程 之间的差距。验证者行动迅速，从偿付能力的角度来看可以说也是正确的。但他们使用的机制是不透明的、链下的，且不受任何交易者可以 提前审查的正式治理流程约束。

批评后的变更

在受到 DeFi 社区的强烈批评后，Hyperli quid 对其验证者集构成和治理流程进行了调整。团队承认了中心化担忧，并承诺扩大验证者集并提高紧急治理程序的透明度。这些变 革仍在进行中。它们是否足够是另一个问题——活跃交易者应该持续跟踪，而不是假设问题已解决。

“代码即法律”的争论

JELLY 事件将 DeFi 社区卷入了一场从未 完全解决的争论：当协议可以干预以防止灾难性损失时，它应该这样做吗？

支持干预的论点

HLP 资 不抵债将是一个真正的系统性问题。如果 HLP 崩溃，Hyperliquid 上所有持有未平仓头寸的交易者都将面临结算的不确 定性。保险基金可能无法填补缺口。以选定价格强制结算，虽然损害了部分头寸持有者，但防止了协议更广泛的恶化。

论点 很简单：协议不是中立的基础设施，它们有利益相关者。允许协同攻击耗尽保险基金并破坏平台稳定，不是对去中心化的原则性捍卫，而是 治理失败。

反对干预的论点

反方论点同样具体。Hyperliquid 的验证者选择了一个保护 HLP 的结算价格，而直接牺牲了持有合法多头头寸的交易者。这些交易者没有攻击协议，却被困在远低于市场的强制结算价格中。

这是选择性执法。协议决定了谁承担损失。在此过程中，它证明了系统规则并非固定不变——当利益足够大时，它们可以由一小 群验证者重写。这是在事件发生前任何交易界面中都未披露的重大风险。

此外还有道德风险论点。如果验证者可以干预以防 止损失，那么未来干预的门槛现在变得模糊了。先例已经确立，下一个案例可能就不那么明确了。

DAO 黑客事件的类 比

最接近的历史类比是 2016 年的以太坊 DAO 黑客事件。DAO 智能合约中的一个漏洞允许攻击者窃取了 约 6000 万美元的 ETH。以太坊社区面临同样的选择：让代码按原样执行，还是进行干预。

社区选择了干预。硬 分叉逆转了黑客攻击。少数派原则上拒绝了这一点，并作为 Ethereum Classic 继续运行原始链。该决定是否正确从未 得到完全解决。

JELLY 事件并不完全相同——Hyperliquid 的干预是治理层面的，而非链分叉——但潜 在的张力是一样的。当一个去中心化系统面临在遵循自身规则和防止灾难性结果之间做出选择时，它的选择揭示了它的本质。

Hyperliquid 选择干预。这一选择对你未来如何在平台上建模治理风险产生了影响。

协议层面的变更

JELLY 事件后，Hyper liquid 进行了几项具体的变更：

• 收紧上线标准。 新的永续 合约市场在批准前现在面临关于流动性深度和市值更严格的要求。
• 低流动性代币的持仓上限。< /strong> Hyperliquid 引入或收紧了低于特定流动性阈值的代币的持仓上限，限制了头寸相对于可用市场深度增长 的规模。
• 审查保险基金机制。 团队审查了 HLP 如何吸收来自非流动 性市场的被清算头寸，并调整了回退逻辑，以减少对小市值代币协同操纵的敞口。
• 扩大验证者集 。 采取了扩大验证者集的步骤，减少了链下投票所暴露的治理权力集中度。

这些是有意 义的变革。它们减少了 JELLY 所利用的特定攻击向量，但并没有消除治理风险。针对不同代币、具有不同流动性动态的另一次攻击 仍可能产生类似情况——而治理响应可能看起来类似。

对活跃交易者的启示

JELLY 事件澄清了许多交易者视为抽象的东西：非托管并不意味着治理免 疫。

你可以持有自己的私钥，亲自签署每一笔订单，从不将资金存入中心化交易所——但仍然可能受到验证者委员会选定价 格的强制结算。托管风险和治理风险是不同的类别。两者都是真实的，都属于你的风险模型。

这并非反对在 Hyperl iquid 上交易。Hyperliquid 拥有任何永续合约 DEX 中最深的流动性、最快的执行速度和最大的未平仓合约量。 这些都没有因为 JELLY 而改变。但该事件是一个明确的提醒，协议层携带的风险独立于你是否控制自己的钱包而存在。

< p>你可以控制的是你自己的风险姿态：

• 在低流动性代币中设置严格 的头寸规模限制，因为这些代币的清算机制最可能产生不利结果。
• 使用可配置的杠杆上限，确保单笔头寸不会超过 你定义的风险承受能力，无论协议允许什么。
• 设置名义头寸限制，在提交交易前限制你的总敞口。
• 使用滑点控制，在签署任何内容前查看最差成交价格。

这正是 Stacked Markets 在其终端中构建的工具类型。可配置的杠杆上 限、名义头寸限制、停止开关和用于快速订单爆发的熔断机制，是位于你和协议之间的前端控制。它们不会改变 Hyperliquid 验证者在治理紧急情况下的行为，但意味着你无需依赖协议默认值来管理自己的敞口。

Stacked Markets 上的每一笔订单都通过带有滑点边界的 IOC 限价单进行路由。在钱包签名提示出现前，会显示最差成交价格。Stacked M arkets 不持有资金和私钥——撮合、保证金、资金费率和结算都在 Hyperliquid 的链上订单簿上进行。

< p>JELLY 事件是思考这一问题的有用框架。Hyperliquid 的协议级风险控制未能阻止攻击。治理响应奏效了，但为持 有未平仓头寸的交易者创造了新的风险。教训不是要避开 Hyperliquid，而是要在协议提供的基础上增加你自己的风险控制— —因为协议级控制可能会被更改、覆盖，或者仅仅是对你所处的特定情况不够充分。

---

在 Hyp erliquid 流动性之上的可配置风险控制。 杠杆上限、名义限制、熔断机制和 IOC 滑点边界——位于 你和协议之间。

从 Stacked Markets 开始 ->

常见问题解答