Aave 的 rsETH 事故，
真正壞掉的是信任路徑

Kelp 的 rsETH 橋接受了一則偽造跨鏈訊息，放出 116,500 枚沒有對應銷毀的 rsETH。Aave 合約沒有被駭，市場卻被迫進入緊急狀態。

SCROLL
PART 1 ｜ 不是 Aave 合約被駭

攻擊發生在橋上，
壓力落在借貸市場裡

2026 年 4 月 18 日 17:35 UTC，Kelp 的 rsETH LayerZero V2 橋從 Unichain 到 Ethereum 的路徑，接受了一則偽造跨鏈訊息。訊息看起來有效，內容卻描述了一筆 Unichain 上從未發生的來源端銷毀。

結果是 Ethereum 端的 adapter 放出 116,500 枚 rsETH。這些 rsETH 看起來像正常資產，背後卻沒有對應的來源端銷毀。Aave 的事後報告把問題切得很清楚：漏洞不在 Aave 合約，而在第三方橋與驗證路徑。

但 DeFi 的麻煩就在這裡。借貸市場不只看自己的合約，也吃進抵押品背後的一整串外部依賴。Aave 把 rsETH 列為抵押品，就等於把 rsETH 橋、驗證者、跨鏈訊息和市場流動性一起接進自己的風險模型。

PART 2 ｜ 攻擊鏈

一則偽造訊息，
一路變成真實 WETH 借款

這次事件的攻擊鏈很短。Kelp 的 rsETH 橋使用一個 one-of-one 的 Decentralized Verifier Network，也就是單一驗證者負責簽署所有進入 Ethereum 的跨鏈訊息。這個由 LayerZero 操作的驗證者遭遇 RPC poisoning，看到被操縱的來源鏈狀態後，替一筆不存在的交易背書。

rsETH 事件的風險傳導路徑
01
橋接受偽造訊息
Ethereum 端收到看似有效的跨鏈訊息。
02
116,500 rsETH 放出
來源端沒有對應銷毀，背後出現缺口。
03
攻擊者拿去抵押
89,567 rsETH 進入八個 Aave V3 部位。
04
借出真實資產
82,650 WETH 和 821 wstETH 被借出。
Aave 的合約、預言機和清算邏輯可以照規則運作，但只要抵押品的背後信任路徑失守，借貸市場仍會接到壓力。

攻擊者把竊得的 rsETH 分散到七個地址，再用其中 89,567 枚進入 Aave V3 的 Ethereum Core 與 Arbitrum 部位。這些部位的 health factor 維持在 1.01 到 1.03 之間，安全墊非常薄。

PART 3 ｜ 緊急踩煞車

Aave 的第一個任務，
是阻止壓力繼續傳染

事件發生後，Aave Protocol Guardian 和 Risk Steward 對 rsETH、wrsETH 與 WETH 儲備分層加上保護。這些動作不是為了修橋，而是為了限制攻擊者繼續用有問題的抵押品換走其他資產。

事後報告裡的主要緊急動作
4 月 18 日
凍結 Aave V3 上的 rsETH 與 wrsETH，並把 LTV 設為零；Aave V4 的 Kelp Spoke 也完整凍結。
4 月 20 日
凍結 Ethereum Core、Prime、Arbitrum、Base、Mantle、Linea 上的 WETH，防止新的借款權力繼續外溢。
4 月 23 日
暫停多個部署上的 rsETH 儲備，避免攻擊者提領資產，同時保留清算部位的可能性。

這些操作也把一件事攤開：DeFi 的風控不是單一開關，而是一組會互相牽動的參數。凍結、LTV 歸零、利率曲線、供給上限、借款上限，每一個都是在爭取時間。

PART 4 ｜ 復原不是單一協議能做完

真正讓市場恢復的，
是一次產業級協調

如果問題只是 Aave 自己的合約，那修復路徑會比較直。這次不同。rsETH 的背後缺口需要被補回來，否則持有 rsETH 或接受 rsETH 抵押的協議，都會面對同一個資產 backing 不足的問題。

Aave Labs 於是推動 DeFi United，協調 Lido、EtherFi Foundation、Ethena、Mantle、KelpDAO、LayerZero、Compound、Consensys 等參與者。事後報告說，這個復原承諾後來達到約 3 億美元，但具體仍取決於相關協議與執行。

116,131.72
rsETH 補回 adapter
5 月 26 日完成第五批補充，Ethereum 端 backing 恢復。
30,766
ETH 被 Arbitrum 凍結
Arbitrum Security Council 凍結與攻擊者相關的 ETH。
8
Aave 攻擊者部位清算
AIP 478 清掉 Ethereum Core 與 Arbitrum 上的部位。

復原分成兩段。第一段清掉 Aave 與 Compound 上攻擊者相關部位，把回收的 rsETH 轉給 Aave Recovery Guardian，並在 Arbitrum 燒掉攻擊者的 rsETH。第二段分批補回 LayerZero OFT adapter，重新開放 rsETH 操作，再把 WETH LTV 逐步恢復。

PART 5 ｜ 風控開始往外看

抵押品審查不能只看代幣，
還要看代幣背後的依賴

Aave 事後啟動對 V3 全部資產的審查。這次審查不是只問代幣價格和交易量，而是把外部依賴拆成三類：第三方基礎設施、中心化依賴、次級市場結構。

🌉
第三方依賴
橋、預言機、第三方智能合約。抵押品的風險可能藏在 Aave 之外。
🏢
中心化依賴
維護團隊、託管基礎設施、操作安全。誰能改系統，比代幣名稱更重要。
💧
市場結構
中心化與去中心化交易所的流動性。抵押品出事時，市場能不能承接清算。

報告裡也提到，事件後 Risk Stewards 已執行約 295 次參數調整，其中 234 次是 4 月 23 日同一輪 risk-off 的 cap 調整。活躍儲備的 cap 降到大約目前存款的 1.2 到 1.3 倍，沒什麼使用的儲備則把 cap 設為 1，等於軟凍結。

這代表 Aave 的上市邏輯正在收窄。低 TVL 部署會被下架，資源集中到最大、使用者最依賴的市場。每個資產和每個部署，都要說清楚它對協議有沒有商業意義，以及它把哪些外部風險帶進來。

PART 6 ｜ V4 的方向

下一步不是把風險消滅，
而是把風險關在小房間裡

Aave V4 的方向，是把風險隔離得更細。V4 有兩層隔離：Liquidity Hub 和 Spoke。每個 Hub 有自己的抵押品組合與風險設定；每個 Spoke 則是在 Hub 裡的一個獨立市場，只能在額度內共享流動性。

問題
共享市場
V4 隔離思路
壓力傳導
一個抵押品出事，可能把壓力帶到同一池子的其他資產。
先把壓力關在 Spoke，再限制它碰到 Hub 的範圍。
參數調整
同一套參數要兼顧成長、競爭與尾端風險。
用 Dynamic Risk Configuration 區分新舊使用者，控制更細。
自動化
很多緊急動作仍靠人工治理或服務提供者判斷。
自動維護 supply cap、borrow cap，必要時自動把 LTV 降為零。

這不是承諾未來不會出事。它比較像承認 DeFi 的風險已經不只在合約裡，而是在一層層外部依賴裡。協議要做的，是讓任何一層出事時，損害不要一路穿過整個系統。

這不是 Aave 合約被駭，而是 Aave 把外部橋的信任路徑，接進自己的抵押品清單。

DeFi 的新風險，不只在程式碼，也在每一個被列為「可抵押資產」的外部依賴裡。

這次 rsETH 事故後，
Aave 最該優先改哪一層？

選完之後，分享你的觀點

你的觀點

想看更深入的分析？

Aave 的治理論壇保留了 4 月 18 日事件處理串，包含最早的凍結動作、風險討論與後續相關提案。

閱讀完整文章 →