合约算法镰刀(十三)再讲清算:HLP 要误杀几多,散户先会明ADL系穿仓嘅保命符

91次阅读
没有评论

 

是什么将标榜“公平”的协议和交易所逼得掀桌子?当我们在谈ADL的时候,我们就不能只谈ADL。ADL是整个清算机制的最后流程。我们要看的是整个清算机制,包括强平价格,破产价格,盘口清算,保险基金等机制 – ADL只是最终的“社会化”结果,核心其实是清算机制,是清算机制耗尽后的满目疮痍让我们走到了这一刻。(你和我都该负责~)
至于为什么ADL是贪婪序列(Greedy queue)?你站在流动性充沛、风平浪静的现在你是没办法理解的,你要把你自己放到ADL发生当下的context,你就能理解为什么CEX会这么设计,因为这是风险最小、成本最低、心理负担最小的方案。
阅读导览:
  1. 本文文长7000+字,内容非常硬核,建议不了解什么是合约清算规则的小伙伴,先去补充一点背景知识再来:

  2. 清楚交易所的清算流程,可以直接从第三章开始
  3. 只对HLP机制感兴趣的,建议直接跳到第五章
一、ADL是交易所的保命道具,不是公平的砝码
ADL(Auto-Deleveraging,自动减仓) 是永续合约市场中的一种系统级风险兜底机制。当市场出现剧烈波动、部分账户发生穿仓,且交易所的保险基金不足以覆盖这些亏损时,系统会启动 ADL,通过强制平掉一部分盈利账户的仓位来填补缺口,从而防止整体清算体系失效。需要注意的是,ADL不是正常操作,只有在极端情况下才会被启用的“最后手段”。
在 ADL 触发后,系统按照一套明确但不完全公开的优先级规则进行减仓。通常来说,杠杆越高、浮动盈利比例越大的仓位,越容易排在 ADL 队列的前面被进行“仓位优化”。
关于ADL的核心,直接发一段Binance关于ADL的论述:
几个要点:
  1. 目前的合约机制已经做好了“穿仓”的准备
  2. ADL是强平流程的最后一步
  3. 在合约风险保障基金无法吸收时才会发生
  4. 风险保障基金的体量越大,ADL被触发的频率就越少
  5. 启动ADL对市场的影响不好,相当于用盈利者的钱去补贴亏损者的错误(尤其盈利者一般是大户,减少人家的盈利就是在得罪大户)
  6. 我们不能避免ADL,但我们会想尽办法减少。
对于交易所/协议来说,如果清算机制的目的是为了保证公平,那么ADL就是为了保命。
二、清算瀑布:从市场成交到 ADL 触发
既然ADL是清算机制的组成部分,要探究ADL的触发细节就应该先从源头开始。
一般来说,交易所对于清算都有一套“瀑布流”顺序:
第一阶段:盘口清算 (Order Book Liquidation) 当用户维持保证金不足时,清算引擎首先尝试将该头寸作为市价单,或者分拆成若干个小额挂单/订单扔进订单簿。
理想情况下,市场深度足够,多头平仓单被空头挂单吃掉,仓位关闭,剩余保证金退还用户。但是在在类似 10.11 的崩盘中,买盘枯竭,巨大的清算单会直接击穿盘口,导致价格滑点失控,直接造成穿仓 ,所以会进入到第二步。
第二阶段:风险保障基金接管 ,当盘口无法承接,或者用户的仓位已经接近穿仓线(Bankruptcy Price)时,为了防止价格进一步崩塌,交易所的保险基金会介入。
风险保障基金充当“最后买家”,以接近(有些交易所是优于)破产价的价格接管该仓位。风险保障基金随后会尝试缓慢地在市场上平掉这个仓位。此时基金持有了一个巨大的亏损头寸(库存风险)。如果价格继续下跌,基金本身就会亏损 。
第三阶段:ADL 触发 这是最关键的一步。当风险保障基金尽或着达到阈值,或者基金经过风控计算认为接管该仓位会导致自身破产时,系统将拒绝接管,直接触发 ADL。
系统在对手方(即做对了方向、正在盈利的交易员)中寻找“牺牲者”,强制以当时的标记价格平掉他们的仓位,以此来抵消那个即将穿仓的亏损头寸
这里划重点:ADL其实在这里有一个很重要,但是基本没有人提及的“功能” —— 就是在市场流动性不足的时候,用赢家的钱去止跌
各位想一下,假设没有ADL,那么保险基金为了生存就会一直在盘口成交单子,那么价格就会一直往上/下走,就会引起更多的踩踏。
三、 两种清算模式对 ADL 的传导效应
很多人都知道ADL,但是估计没多少人去了解ADL之前的清算模式。一般来说,主要有两种模式,目前一些比较创新的清算模式也是基于两种模式之上的改良。
清算是 ADL 的前奏。不同的清算处理方式,直接决定了 ADL 触发的频率、深度和对市场的影响。谈ADL,不谈清算模式,就是耍流氓。
3.1 模式 A:盘口倾销模式 (Order Book Liquidation)
机制:当用户触发清算线,清算引擎直接将该头寸作为市价单(Market Order) 扔进订单薄进行成交。
保险基金的作用:仅用于填补“穿仓损失”。即,如果市价单把价格砸到了破产价(Bankruptcy Price)以下,中间的差额由保险基金赔付。
ADL 触发逻辑:只有当风险保障基金归零,或者订单薄完全枯竭(没有买单了)时,才会触发 ADL。但是目前大部分的交易所都更改了算法,当风险保障基金低于一定阈值时(一般是一段时间内基金余额从基金高点的x%),就会触发ADL。(并非基金归零后触发,所以触发频率越来越多)
对市场的影响:
优点:尽可能尊重市场定价,不干扰盈利用户。
缺点:在类似 10.11 的极端行情下,巨大的清算单会瞬间击穿流动性,造成连环爆仓。价格会因为清算单本身而暴跌,导致更多人爆仓,进而导致风险保障基金迅速耗尽。
3.2 模式 B:接管/吸纳模式 (Backstop/Absorption)
机制:当用户触发清算线,系统不会直接向盘口抛售,而是由流动性提供者/保险基金直接接管该头寸。
风险保障基金的作用:它以破产价的价格“买入”了用户的爆仓单。吸收之后,择机将该订单在市场上抛售,假设成交价格优于仓位价格,那么盈利将计入保险基金,反之亏损则由保险基金承担。
ADL 触发逻辑:这是模式之间最关键的区别。
在模式 A 中,ADL 是盘口的流动性耗尽,且保险金耗尽后“没钱赔了”才触发的。
在模式 B 中,ADL 是以风险保障基金的风控为触发开关。
四 、 两种清算模式的深度验证与演算
为了回答“不同清算机制如何影响 ADL”,我们首先建立一个数学模型来模拟 模式A与 模式B 在极端行情下的表现。
4.1 场景假设
市场环境:ETH 价格瞬时崩盘。当前市场深度极差,买单稀缺。
违约账(Alice):
持仓:多头 10,000 ETH
强平触发价(Liquidation Price):$2,000
破产价(Bankruptcy Price, 归零价):$1,980
当前市场盘口:
买一价:$1,990(只有 100 ETH)
买二价:$1,900(只有 5,000 ETH)— 断崖式深度
买三价:$1,800(有 10,000 ETH)
4.2 模式 A:盘口倾销模式
机制:清算引擎不经过任何缓冲,直接将 Alice 的 10,000 ETH 以市价卖单扔进订单簿。
演算过程:(简化计算,大家看个大概就行)
成交
100 ETH @ $1,990 ; 5,000 ETH @ $1,900 ; 4,900 ETH @ $1,800
加权平均成交价 (VWAP): [(100*1990) + (5000*1900) + (4900 *1800)] / 10000 = $1852
穿仓亏损: Alice 的破产价是 $1,980。 每 ETH 亏损:$1,980 – $1,852 = $128 总穿仓损失:$128 * 10,000 = $1,280,000
ADL 触发: 如果保险基金余额 < $1.28M,系统必须立即触发 ADL。 系统会找到持有空单的盈利大户 Bob,强制以 $1,980 的价格帮他止盈(尽管现在市价已经跌到了 $1,800,Bob 本可以赚更多)。
模式 A 导致价格瞬间砸穿至 $1,800,制造了巨大的滑点亏损,直接击穿保险基金,导致 ADL 立即且大规模触发。
4.3 模式 B:接管/吸纳模式
机制:清算引擎不向盘口抛售。保险基金(或 HLP 池)直接以强平价($2,000) 或 略优于破产价($1,990) 接管 Alice 的仓位。
演算过程
接管:风险保障基金池瞬间持有了 10,000 ETH 的多头仓位,入场成本记为 $1,990。
  1. 市场反应:盘口价格依然停留在 $1,990(因为没有抛压砸盘)。市场看起来“风平浪静”。
  2. 库存风险:1分钟后,外部市场(如 Coinbase)跌至 $1,850。风险保障基金池持有的这 10,000 ETH 产生了 浮动亏损: ($1,990 – $1,850) * 10,000 = $1,400,000
  3. ADL 触发判断: 此时系统不会因为“没钱赔”而触发 ADL(因为还没卖)。但系统会进行风险检查:
  • 如果 HLP 的总资金是 $100M,亏 $1.4M 可以忍受 -> 不触发 ADL。
  • 如果 HLP 资金只有 $5M,亏 $1.4M 占比过大 -> 为了保护 LP,系统决定把这个烫手山芋扔出去 -> 触发 ADL。
  • 模式 B 在崩盘的第一秒保护了盘口价格,避免了连环爆仓。但它把风险囤积在了保险基金肚子里。如果后续行情不能反弹,保险基金的亏损会不断放大,最终可能导致更猛烈的 ADL(或者像 Hyperliquid 10.11 那样,为了防止 HLP 亏光,激进地 ADL)。
多说一句,Hyperliquid 之所以在10.11时大规模触发 ADL,并非因为系统没钱了,而是因为 HLP Vault 为了自我保护,主动将风险转移给了盈利用户。这是为了防止重演之前“Whale Slap”事件(巨鲸利用流动性不足坑害 HLP)。
模式 B 虽然保护了盘口价格不被瞬间砸穿,但它将“库存风险”集中到了 HLP 身上。一旦 HLP 感到恐惧(达到风控阈值),它就会通过 ADL 极其激进地“杀”掉盈利用户的仓位来平账来保证自己的存活。各位想象一下,假设HLP一天的回撤达到了30%,那么大部分的人会怎么做?他们会直接撤资、提现,最终形成挤兑。
补充一句,熟悉我的老粉都知道,我之前多次说过目前的Perp dex照抄CEX的清算机制,迟早会出大问题,大家现在估计能稍微理解了吧?hahaha
五、 Hyperliquid 的特殊架构:HLP 与 ADL 的敏感性
Hyperliquid 的特殊性在于,它没有像 Binance 或 OKX 那样由交易所常年累积的利润当作护垫、不透明的巨额保险基金。它的保险基金是 HLP Vault来承担。
5.1 HLP:既是做市商,也是保险基金
HLP 是一个由社区用户存入 USDC 组成的资金池。它具有双重人格:
做市商 (Market Maker):它在订单簿上提供流动性,赚取价差。
清算兜底 (Liquidator):当上述“第二阶段”发生时,HLP 负责接管用户的爆仓头寸 。
这种结构导致了 Hyperliquid 的 ADL 触发机制与中心化交易所截然不同:
Binance 模式:保险基金是交易所的“私房钱”,通常积累了数十亿美元(?)(这个是我猜的,没有依据),所以Binance 可以容忍极大的回撤,尽量不触发 ADL,以维护大户体验。
Hyperliquid 模式:HLP 是用户的钱。如果 HLP 为了接管一个巨大的有毒头寸而亏损过多,会导致 LPs(流动性提供者)恐慌撤资,引发“挤兑”,导致交易所死亡。(Jelly事件已经让HLP见识过回撤的威力了)
因此,Hyperliquid 的风控引擎被设计得极度敏感。一旦系统检测到 HLP 接管某个头寸的风险过高,它会立即跳过第二阶段,直接启动 ADL。这就是为什么在 10 月 11 日,Hyperliquid 触发了大规模 ADL(10分钟内超过40次),而某些 CEX 即使在内部可能已经穿仓,也选择用自有资金硬抗 。
5.2 深入解析:清算金库 (Liquidator Vault) 机制
Liquidator Vault 是 HLP 内部的一个子策略。它不是一个独立的资金池,而是另一套“清算”逻辑。
当一个交易者被清算且市场无法吸收该订单(第 1 层失败)时,清算金库“买入”该违约头寸。
例子: 交易者在 $100 做多 1000 SOL。价格跌至 $90(强平价)。订单簿买单稀薄。清算金库以 $90 接管这 1000 SOL 的多单。
即时 PnL 确认: 用户的剩余保证金被没收。如果保证金覆盖了入场价和当前标记价格之间的差额,HLP 立即记入一笔“清算费”利润。
库存解除:HLP 现在在一个崩盘的市场中持有 1000 SOL 的多头。它必须卖出这些 SOL 来中和风险。但是假设这些头寸无法被及时清除且达到,将会触发ADL。
六、10.11 事件复盘:算法的博弈
现在让我们回到争议的核心:2025 年 10 月 11 日,Hyperliquid 处理了其中超过 100 亿美元的清算量;10分钟之内ADL超40次,有人说这完全就是小题大做?真的是如此吗?
6.1 争议的核心:Greedy Queue vs. Pro-Rata
Gauntlet 的 CEO Tarun Chitra 指出,Hyperliquid 使用的 ADL 算法导致了约 6.53 亿美元的“不必要损失”(机会成本)。
争议的焦点在于 ADL 的排序算法。
Hyperliquid 的算法:贪婪队列 (The Greedy Queue)这是 BitMEX 时代传承下来的经典算法。系统根据盈利能力和杠杆率对所有盈利用户进行排序:
排序分数 = 盈利 / 本金 * 杠杆倍数
执行方式:
系统从排名第一的用户开始,将其仓位完全平仓,直到填补完亏损缺口。结果:排名靠前的“表现最好的交易员”被“杀”了。他们的仓位没了,虽然保住了当时的利润,但失去了后续市场继续下跌带来的巨额潜在收益 。
Tarun Chitra提出的算法:风险感知按比例 (Risk-Aware Pro-Rata):
执行方式:不是把第一名完全杀掉,而是对前 20% 的盈利用户,每人削减(原文用haircut,or reduce)一部分仓位(例如每人平掉 10%)。
优势:保留了用户的部分仓位,让他们能继续享受后续的行情。Tarun Chitra 的回测显示,这种方法能保留更多的持仓量(OI),减少对用户的伤害 。
6.2 为什么 Hyperliquid 坚持使用“贪婪队列”?
尽管 Gauntlet 的算法在理论上更公平,但 Hyperliquid 创始人 Jeff Yan 的反驳道出了现实约束:
速度与确定性 :在 L1 链上,计算资源是昂贵的。对几千个用户进行按比例扣减需要大量的计算和状态更新,可能导致区块延迟。而“贪婪队列”只需要排序和切除头部,计算复杂度低,执行速度极快(毫秒级)。在市场崩盘时,速度就是生命 。
HLP 的脆弱性:如前所述,HLP 资金有限。按比例 ADL 意味着 HLP 需要在更长的时间内持有部分有毒头寸(等待系统慢慢计算和执行所有人的削减)。对于 Hyperliquid 来说,迅速切断风险(通过完全平掉大户)比所谓的“公平”更重要 。
七、 贪婪队列的真相如何?
如果大家都能通篇看下来就会知道,10分钟40+次的ADL就是HLP的机制精髓所在,在交易大户面前,HLP的贡献者才是Hyperliquid的根基。
贪婪队列不是Hyperliquid新创的算法,实际上早在n年前就有这个算法,并且目前仍为广大CEX所沿用,难道它们使用贪婪队列时没想过资金池的安全性?也瘦计算量和速度的局限?而历史上发生了这么多次的ADL,这些受影响的大户难道都没有维权?上门闹吗?显然不是的。
真正的原因是:对于中心化交易所CEX来说,贪婪队列是现有机制上兼具合理、相对公平和成本可控的方案。
回到前面说的清算模式A和模式B,ADL触发的条件是
  1. 市场剧烈波动
  2. 市场上的流动性基本处于“真空”状态
  3. 风险保障基金受到严重损失了
对于被ADL大户来说,他们也清楚在那个时间节点内,市场上是没有足够的流动性承接他们的盈利仓位,甚至早年因为一些技术原因,在市场剧烈波动之际,连交易所的账号都没办法登录,所以ADL的操作就变相地成为了一种交易所协助“止盈”的功能,因为很多盈利的利润在那个节骨眼很可能是是没办法成交的。
此外,比起亏损,赚少了从心理上更容易让人接受一些,尤其是在得知交易所自己也狠狠亏了一波之后,这种幸福感一经比较之后会让人稍微舒坦。
至于为什么一定是贪婪序列,除了是因为赚得越多 = 责任越大,这种有点奇怪的朴素逻辑之外,其实更主要的原因是:受影响人数更少。
CEX最担心的是什么?不是穿仓?不是损失?而是舆情! 与其一群人受到损失,他们更希望看到只是少部分人受到损失,这样的话,可以一对一,多对一的私下沟通解决。大家要知道,市场上的博弈不是只到清算/ADL之后结束的,还有后续的扯皮、投诉、威胁等等,很多纠纷都是在盘面下解决的。
八、 有没有更好的算法?
有,但是不是更好的ADL算法,现阶段应该把重点放在如何预防ADL的发生。
因为不是本文的重点,以下就简单用一个表来带过,对于交易所的从业者来说,图表里的提示应该也足够了。
当然如果各位交易所有“勇气”来做一个熔断系统的话,那真的是阻挡好多不必要的话:
知其然,且知其所以然。
愿我们始终怀揣着一颗敬畏市场之心。
正文完
 0
bdspAdmin
版权声明:本站原创文章,由 bdspAdmin 于2025-12-24发表,共计6778字。
转载说明:除特殊说明外本站文章皆由CC-4.0协议发布,转载请注明出处。
评论(没有评论)

摆渡资源站

文章搜索
一言一句话
-「
热门文章
1Panel服务器迁移和WordPress配置

1Panel服务器迁移和WordPress配置

  1Panel服务器迁移 1Panel的整体迁移相对简单,使用快照功能即可实现。但是要求新旧服务器...
Ubuntu 通过页面设置固定 ip

Ubuntu 通过页面设置固定 ip

要在 Ubuntu 图形界面(桌面)设置固定 IP,通过右上角网络图标进入设置,找到有线/无线连接,点击齿轮图...
安装了 openjdk@17 和 zulu@8,通过 jenv 来管理 JDK 版本

安装了 openjdk@17 和 zulu@8,通过 jenv 来管理 JDK 版本

你已经成功安装了 openjdk@17 和 zulu@8,现在可以配置 jenv 来管理 JDK 版本。按照下...
为什么不要在知乎写东西

为什么不要在知乎写东西

知乎的平台注定不能做大做强走向世界,限制太多了 不能发表外链 无缘无故删除文章,警告。
okx websocket 接口问题

okx websocket 接口问题

今天想对接一下 websocket,但是死活不行,主网站 api 接口没问题。 然后发现是电信,联通网络问题,...
最新评论
最新文章
某个货币持仓增长了一倍,但是 jing流入没有增加多少,为啥

某个货币持仓增长了一倍,但是 jing流入没有增加多少,为啥

  这通常是因为该货币的市值(价格)上涨抵消了持仓量的增加,或者存在某些“非交易性”的变动。 简单来...
mac brew 有没有 markdown 格式化工具

mac brew 有没有 markdown 格式化工具

  在 macOS 上通过 Homebrew (brew) 安装 Markdown 格式化工具非常方...
手滑点错更新也不怕!超详细 Mac 系统更新屏蔽指南(附安全恢复方案)

手滑点错更新也不怕!超详细 Mac 系统更新屏蔽指南(附安全恢复方案)

  Mac 屏蔽系统更新并消除小红点全攻略 在 macOS 系统中,系统更新提示的小红点常常让人不胜...
我是如何扫描GitHub上所有“Oops提交”以查找泄露的秘密的

我是如何扫描GitHub上所有“Oops提交”以查找泄露的秘密的

  tl;dr GitHub Archive 会记录每一次公开提交,即使是开发者试图删除的提交也不例...
Mermaid 对比 PlantUML

Mermaid 对比 PlantUML

🔍 核心语法差异说明 为了让转换更顺利,了解两者主要的语法区别会很有帮助: 元素 Mermaid 语法 Pla...