[ARFC] 赤字实现风险预言机:通过清理小额抵押品强制实现及时坏账确认
摘要
AI 生成本文档提出在 Aave 协议中引入一个自主风险预言机,以解决因抵押品极少(“粉尘状态”)而无法被第三方清算、导致坏账确认延迟的问题。该预言机监控账户状态,一旦检测到粉尘状态,即触发一个受预算约束的链上执行器(ClinicSteward),执行容忍损失的清理操作。其核心目标是缩短经济坏账产生与链上赤字确认之间的时间,减少风险处理窗口,提升储备金核算的一致性,而非提高清算利润。该机制通过持续监控和批量执行来优化效率。
注:摘要由 AI 自动生成,可能与正文存在差异,仅供参考。
提案内容
AI 翻译摘要
本文档通过引入一个自主风险预言机,为 Aave 上的及时赤字实现构建了一个正式框架。该预言机能够检测并确定性地解决一种特定的清算失败模式:即那些剩余抵押品极少("粉尘")但未偿债务巨大的账户。这些账户在经济上已资不抵债,但由于剩余抵押品过小而无法覆盖 Gas 成本和执行风险,第三方清算无法获得外部利润,因此它们可能在机制上长期保持非赤字状态。在 Aave v3.3 的赤字语义下(仅当抵押品恰好为零时才实现赤字),这种粉尘状态可能导致巨大且持久的赤字延迟。
我们提出了一种状态依存的机制:一个链下风险预言机监控储备金和账户层面的动态,一旦观察到粉尘状态,就会触发一个高度受限的链上执行器("ClinicSteward"),该执行器会执行一种特意容忍损失的清算/清理操作。其目标并非"提高清算盈利能力",而是最大限度地缩短经济坏账产生与其在链上实现为 储备金赤字之间的时间,从而减少 Umbrella 冷却动态的时间窗口,并提高储备金层面覆盖核算的一致性。
问题陈述
经济资不抵债 vs. 已实现赤字
Aave 的赤字并非定义为经济意义上"账户变得资不抵债的时刻"。相反,赤字是一个机制层面的事件:只有当清算过程结束时,抵押品完全为零而债务仍然存在时,协议才会记录坏账。这是一个有意为之的客观定义,并且在结构上与 Umbrella 的自动赤字处理机制兼容。
然而,这个定义引入了一个实际的边缘情况。账户可能变得资不抵债且仍可被清算,但同时仍保留严格为正的抵押品,通常小到在经济上毫无意义,从而阻止了"零抵押品"条件的满足。在这些状态下,坏账是真实存在的,但在机制上是潜在的,以经济术语存在于系统的资产负债表中,但尚未表现为链上的赤字事件。
粉尘状态:清算停滞的原因
赤字延迟的失败模式是由一个简单的经济不连续性驱动的。清算由追求私人利润最大化的第三方执行。当剩余抵押品极少时,清算奖励无法补偿 Gas 成本和执行风险。此时,完成清算就变成了一种公共物品,虽然能改善协议核算和赤字的及时性,但执行清算对私人而言并不理性。
这就是"粉尘状态":账户可被清算且债务重大,但由于剩余抵押品相对于固定的执行成本而言太小,清理这些账户无利可图。
关键在于,这主要不是赤字规模的问题。即使潜在赤字非常大,如果可供扣押的剩余抵押品接近于零,账户仍可能无人问津。从外部清算者的角度来看,如果预期的抵押品支付额被 Gas 费主导,那么无论是 100 美元还是 1000 万美元的预期赤字,都可能同样不紧急。
为何在 v3.3 的其他改进下此问题依然存在
除了既定的"赤字"系统外,Aave v3.3 实质性地改进了强制清理逻辑,并通过使清算更接近对整个头寸的操作,以及回滚那些会留下微小残余的情况,降低了"粉尘"最终状态的概率。具体来说:
- 默认的 50% 关闭因子应用于整个头寸,而非每个资产,使得清算小额头寸更容易,而不会级联产生粉尘。
- 当用户在正被清算的储备金上的债务/本金低于
MIN_BASE_MAX_CLOSE_FACTOR_THRESHOLD时,允许高达 100% 关闭因子的清算。 - 引入了
MIN_LEFTOVER_BASE,并回滚那些会使债务或抵押品低于该阈值的清算,除非其中一方恰好为零。(MIN_LEFTOVER_BASE = MIN_BASE_MAX_CLOSE_FACTOR_THRESHOLD / 2)
然而,由于 Aave 的清算在实践中仍然是按资产参数化的(每次调用需指定抵押资产和债务资产),并且由于头寸可以跨多个储备金进行交叉保证金,因此仍然存在合理的路径,使得清算解决了头寸中具有经济意义的部分,却留下少量残余抵押品,从而阻碍了赤字的实现。特别是,定制的清算选择和特定于储备金的约束仍然可能导致多资产账户中残留粉尘。结果是,头寸可能在压力事件期间累积坏账,但储备金的赤字仅在数周或数月后才实现,纯粹是由于粉尘尾部的清算无利可图。
在实践中,我们观察到了符合这一模式的实例:在压力事件发生时实际上已资不抵债的头寸,由于保留了极少的剩余抵押品余额,使得外部清算人完成清算无利可图,从而在很长一段时间内保持非赤字状态:
- 在 10.10 下跌事件期间,此账户通过使用 WETH 作为抵押品,最大限度地借入 ENS 和 CRV 资产并带着债务逃离,有效地套利了报告预言机价格与链上价格之间的偏差,导致了坏账累积。然而,这笔 6.16 万美元(5760 ENS)的赤字事件本身,直到 12 月 6 日才被内部化,距离坏账产生已近两个月。
- 类似地,以下账户拥有由 AAVE 和少量 USDT 抵押的 WETH 债务,导致该头寸的绝大部分在 10.10 事件中被清算,仅剩下 0.0003 USDT 的抵押品和约 1.38 WETH 的债务,即坏账。然而,这笔 4600 美元的赤字本身,直到 2026 年 1 月 3 日才被确认,距离坏账实际产生已近三个月。
这对 Umbrella 为何重要
Umbrella 的设计为可削减的最终后备资本引入了基于冷却期的退出机制。这意味着赤字确认的时机很重要,而不仅仅是最终的会计结果。
当赤字延迟确认时,协议链上对储备金偿付能力的看法会滞后于损失的经济现实。这扩大了窗口期,使得精明的参与者可以根据尚未在机制层反映的信息来调整其冷却期和提款行为。
如果治理层希望压缩冷却期,尤其是在 Umbrella 成熟和自动化程度提高之后,那么最小化赤字延迟就变得直接相关。赤字事件在经济上暗示发生时被强制发生的速度越快,可被利用的时机面就越小。
提议的机制
概述
我们引入一个双层系统,旨在消除由微量抵押品头寸引起的赤字延迟:
第一层是赤字实现风险预言机,它在链下运行,持续监控账户状态和储备金配置。其作用是检测一个狭窄且保守的微量条件:账户可被清算(健康系数 < 1),剩余抵押品严格非零但极少,并且仍持有实质性债务。当此类账户出现时,风险预言机会按可执行的清算路径(债务资产,抵押资产)对它们进行分组,并通过 batchLiquidate 向受限制的链上执行器提交交易来自动触发清理。
第二层是 Aave ClinicSteward,一个链上受限制的执行器,它为 Aave 收集器资助的清算/还款操作暴露了一个最小化的、有权限的操作空间。至关重要的是,它为每个部署的储备金实例强制执行一个以美元计价的硬预算上限(“最大限额”),同时还有资产白名单和严格的托管约束。在赤字实现的使用场景中,该执行器主要用作最后一英里的清算完成者,清理最后的微量抵押品,以便 v3.3 的清算后逻辑可以立即将任何剩余债务确认为协议赤字。
这些约束是保持机制诚实的关键。其目标不是在正常情况下与清算人竞争,也不是补贴广泛的清算活动。其目的是解决一种特定的故障模式:账户已经进入资不抵债状态,但由于最后的微量抵押品余额使得头寸在机制上“抵押品非零”,因此外部完成清算在经济上缺乏吸引力,从而导致赤字确认延迟。
ClinicSteward 规范:受限制的操作空间
该执行器的职责很窄:通过对已经资不抵债的账户完成最终的微量清理,强制将抵押品精确清零(在协议的会计意义上)。与传统的“坏账清理”用途的关键区别在于,此变体并非旨在以任何有意义的方式偿还债务存量。相反,所执行的清算是名义上的,其存在是为了移除最后的抵押品残余;一旦抵押品为零,剩余的债务预计将在 v3.3 下自动确认为协议赤字。
这使得Collector的使用量能够切实保持在最低水平。管理员可能需要提取少量债务资产来执行清算调用(并可能暂时超额估算),但其设计并非通过偿还本金来吸收损失。一旦抵押品被清除,损失将在协议层被确认为赤字,任何未使用的基础资产加上被扣押的抵押品(以aToken形式接收)都会确定性地路由回Collector。
最重要的是,这一机制在治理层通过ClinicSteward的"最大限额"/可用预算机制 受到约束。每个部署的管理员实例都有一个明确的以美元计价的预算上限,控制着可从Collector提取的总价值。任何超出剩余预算的执行操作都将被回滚,且预算只能通过管理员控制(即在治理授权下)进行更新或调整。对于赤字实现这一用例,该上限可以配置得比传统清理预算小几个数量级,正是因为管理员支付的是完成清算的费用,而非偿还债务。
风险预言机策略:持续监控与自动批量执行
风险预言机并非作为一次性"队列构建器"运行,而是持续监控账户集,并在账户进入(并持续处于)微量状态时立即触发清理。实际上,它维护着一个持续更新的符合条件的账户观察列表:可清算状态、非零但极少的剩余抵押品以及有意义的债务。当批量达到实际规模阈值或基于时间的触发器触发时,它会择机执行,避免了等待完美批处理的需要。
执行直接通过ClinicSteward的batchLiquidate入口点进行路由。由于管理员的清算原语是按资产参数化的,风险预言机按特定清算路径(债务资产、抵押资产)对符合条件的用户进行分组,然后为每个组提交batchLiquidate(debtAsset, collateralAsset, users, useAToken)。这保持了链上调用界面的简洁性,并与Aave中必须指定的清算方式保持一致:每次调用以一种抵押资产偿还一种债务资产。
这与管理员预期的操作模式完全契合。batchLiquidate从Collector提取超额估算的所需 债务资金,尝试清算批次中的每个用户,然后将任何未使用的基础资产以及任何被扣押的抵押品(以aToken形式接收)返还给Collector。整体支出范围仍严格受限于管理员的availableBudget机制,因此任何试图超过配置的最大限额的操作都将被回滚。在此设计中,风险预言机是持有CLEANUP_ROLE的许可操作者(或少数操作者之一),因此是唯一被授权调用batchLiquidate的实体。
结论
Aave v3.3将赤字确立为客观的链上原语,但仍存在一个实际边缘情况:只有当抵押品恰好为零时,赤字才会被实现。在微量尾部,具有极少剩余抵押品和有意义债务的可清算账户可能需要完成最后一步,这对外部清算者而言无利可图。因此,坏账可能在机制上持续数周或数月未被实现。
这种延迟对Umbrella至关重要,因为基于冷却期的退出机制使时机成为首要关注点:延迟的赤字确认扩大了协议链上偿付能力视图滞后于经济现实的窗口期。
风险预言机和ClinicSteward通过自动化最后一公里清理来弥合这一差距。风险预言机持续检测微量状态并触发batchLiquidate,而管理员则强制执行严格的权限和由治理设定的硬性预算上限。其结果是更快、预算受限的赤字实现,并减少了Umbrella的时机暴露面。
披露声明
Chaos Labs未因发布本研究报告及后续风险预言机而获得任何第三方报酬。
版权声明
版权及相关权利已通过CC0放弃。