Aave 链上记录披露 V3 以太坊 ACLManager 上的三次 RISK_ADMIN_ROLE 授权
要点速览
- •三次授权均源自 Aave 的治理 Executor 地址,并记录在 V3 以太坊 ACLManager 上。
- •9 月 2 日的两个接收方 0xbe28...7744 和 0x529e...F6c5 在记录发布时尚未被完全识别。
- •9 月 30 日的授权授予了一个已验证的 RiskSteward 合约,并与 AIP-523 在 Aave V4 上激活 Risk Stewards 相关联。
- •RISK_ADMIN_ROLE 持有者可以更改多项风险设置,包括上限、清算参数和储备因子,但不能暂停或激活储备。
- •AIP-523 通过可撤销性、硬性参数边界以及针对各受支持 V4 部署的冷却期来限制委托权限。

一份发布在 Aave 治理论坛的经解码链上记录显示,2026 年 9 月 2 日至 9 月 30 日期间,Aave V3 以太坊 ACLManager 合约上共执行了三次 RISK_ADMIN_ROLE 授权。据该记录,三次授权均源自协议的治理 Executor 地址,其中一次与激活 Aave V4 Risk Stewards 的提案直接相关。
经解码记录显示了什么
这份链上经解码的治理帖子([ACLManager RISK_ADMIN_ROLE grants, Sep 2026 — decoded]( ACLManager 合约中的三个独立授权事件。ACLManager 是 Aave V3 在整个协议中分配和管理管理权限的中心访问控制注册合约,因此记录在其中的条目决定了谁拥有对风险参数的委托权限。在 Aave 的治理架构中,Executor 合约负责将已批准的提案在链上执行。据该解码帖子,三笔交易均源自治理 Executor 地址 0x5300A1a15135EA4dc7aD5a167152C01EFc9b192A。
其中两次授权发生在 2026 年 9 月 2 日的区块 25,891,729,目标地址为 0xbe28...7744 和 0x529e...F6c5。原始来源将这两个接收方的具体合约身份标记为未确认;据链上解码,截至发布时,其角色和用途尚未得到完全核实。
第三次授权发生在 2026 年 9 月 30 日的区块 26,089,561,授予了一个已验证的 RiskSteward 合约,该合约部署了约 20,061 字节的代码。此次授权与 AIP-523「Activate Aave Risk Stewards on Aave V4」([治理提案](
RISK_ADMIN_ROLE 为何对协议监管至关重要
RISK_ADMIN_ROLE 在 Aave 访问控制层级中位于完整治理层级之下。持有者可以更新储备因子设置、供应与借款上限、贷款价值比(LTV)、清算阈值、清算奖励以及 E-Mode 类别配置,而无需为每次调整触发单独的治理投票。这些控制共同决定了多少资产可以进入市场、清算期间抵押品如何处理,以及价格行为相关的资产如何分组以提高借款效率。RISK_ADMIN_ROLE 持有者不能做的是暂停或恢复储备,或将其完全激活或停用;这些操作仍由更高权限的角色掌握。
其实际意义在于速度。在 RISK_ADMIN_ROLE 下运作的协议风险管理者可以在数小时内响应市场状况、流动性变化或预言机异常,而无需等待多日的治理周期。该角色在实践中被频繁行使:截至 2026 年 4 月关于 rsETH 事件的复盘报告,Aave V3 Risk Stewards 已在 V3 储备上执行了约 295 次单独的参数更改。
AIP-523 将该架构扩展至 Aave V4
AIP-523 将这一模型扩展至以太坊、Avalanche 和 Base 上的 Aave V4。该提案授予受限且可撤销的 RISK_ADMIN_ROLE 权限,其受硬性参数限制约束,而非仅仅依赖被授权方的信誉,Aave V4 Risk Stewards 框架旨在将这些约束在链上正式化。
据 AIP-523 治理帖,在 V4 框架下,单次 Risk Steward 更新中供应和借款上限的提升幅度不得超过 50%。
冷却期构成第二层约束。Hub 利率与上限变更设有 36 小时冷却期;spoke 和抵押品参数需 72 小时;预言机价格上限更新则处于 48 至 72 小时区间。这些间隔旨在防止可能被利用或在社区不知情的情况下累积成重大结构性变更的连续快速调整。
治理考量与待解问题
9 月授权引发的设计问题不在于该角色是否有用——它显然有用——而在于治理社区在该角色到位后是否仍保有实质性的审查能力。论坛贡献者 MconnectDAO 直接问道:「Aave 将如何确保社区讨论保持实质性,而不仅仅是形式上的批准流程?」这一担忧是结构性的:一项向合约授予开放式角色的治理投票,实际上预先授权了该合约编码边界内的所有未来参数变更。
贡献者 Roch33 提出了一项透明度基准以部分回应这一担忧,呼吁每次参数变更都记录旧值和新值、所应用的治理批准边界、使用的数据来源以及更新的理由。这种程度的链上与论坛披露将使社区能够审计 Risk Steward 的操作是对市场数据的防御性响应,还是在逐步试探边界。
9 月 2 日的两个接收方 0xbe28...7744 和 0x529e...F6c5 仍是未解之谜。链上解码帖子将其身份标记为未完全确认,现有报道均未查明这些地址代表哪些合约或服务提供商。在这一点得到确认之前,社区无法充分评估与区块 25,891,729 的 9 月 2 日授权事件相关的委托权限范围。因此,最具体的后续跟进点是确认这些接收方、披露针对其批准边界的后续参数变更,以及涉及这些授权的任何后续治理行动。
对于与 AIP-523 相关的 9 月 30 日 RiskSteward 授权,可撤销性是该设计的核心特征。授予该角色的治理 Executor 可以通过后续提案将其撤销,且合约本身编码的有界参数上限即使在该角色未被撤销的情况下,也能作为防止参数漂移的断路器。可撤销性与编码限制的结合旨在使委托的风险权限始终从属于治理。Aave 2026 年的 V4 架构概览详细介绍了协议在新框架下如何处理跨链风险委托。