Aave 鏈上紀錄詳列 V3 Ethereum ACLManager 上三筆 RISK_ADMIN_ROLE 授權
重點速覽
- •三筆授權全部源自 Aave 的治理 Executor 地址,並記錄於 V3 Ethereum 的 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 Ethereum ACLManager 合約上執行的三筆 RISK_ADMIN_ROLE 授權。根據該紀錄,三筆授權全部源自協議的治理 Executor 地址,其中一筆更與啟用 Aave V4 Risk Stewards 的提案直接相關。
解碼紀錄顯示了什麼
這份鏈上解碼治理貼文([ACLManager RISK_ADMIN_ROLE grants, Sep 2026 — decoded]( 合約——即 Aave 為 V3 架構設立的中央存取控制登記處——共記錄了三筆獨立的授權事件。ACLManager 是 Aave V3 用於在整個協議中分配和管理管理權限角色的合約,因此記錄於此的條目決定了誰持有對風險參數的委託權限。在 Aave 的治理架構中,Executor 合約負責將已通過的提案在鏈上執行。根據解碼貼文,三筆交易均源自治理 Executor 地址 0x5300A1a15135EA4dc7aD5a167152C01EFc9b192A。
兩筆授權於 2026 年 9 月 2 日在第 25,891,729 區塊落地,目標地址為 0xbe28...7744 與 0x529e...F6c5。主要來源將這兩個接收方的確切合約身分標記為未經確認;根據鏈上解碼資料,其角色與用途在發布時尚未完全核實。
第三筆授權於 2026 年 9 月 30 日在第 26,089,561 區塊執行,給予一個經驗證、部署代碼約 20,061 位元組的 RiskSteward 合約。該筆授權與 AIP-523「Activate Aave Risk Stewards on Aave V4」([治理提案](
為何 RISK_ADMIN_ROLE 對協議監督至關重要
RISK_ADMIN_ROLE 在 Aave 的存取控制層級中位於完整治理層級之下。持有者可以更新儲備因子設定、供應與借款上限、貸款價值比、清算門檻、清算獎勵以及 E-Mode 類別配置,而無需為每項調動觸發單獨的治理投票。這些控制共同決定了多少資產可以進入市場、清算時抵押品如何處理,以及價格走勢相關的資產如何被歸類以提高借款效率。RISK_ADMIN_ROLE 持有者無法做到的是暫停或恢復儲備,或完全啟用與停用儲備;這些操作仍保留給權限更高的角色。
其實際意義在於速度。在 RISK_ADMIN_ROLE 下運作的協議風險管理者可以在數小時內應對市場狀況、流動性變化或預言機異常,而無需等待為期多日的治理週期。該角色在實務中被頻繁行使:截至 2026 年 4 月 rsETH 事件的事後分析報告,Aave V3 Risk Stewards 已在 V3 儲備上執行約 295 次單獨的參數變更。
AIP-523 將此架構延伸至 Aave V4
AIP-523 將此模式延伸至 Ethereum、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 架構總覽詳細介紹了協議在新框架下如何處理跨鏈風險委託。