Aave schlägt einen Risikorahmen vor, der die Verwaltung von Assets regeln soll, die über Aave V3, V4 und Aave Horizon gelistet sind, nachdem der KelpDAO-Exploit im April bekannt wurde. Der Exploit ermöglichte es Angreifern, ungefähr 292 Millionen US-Dollar in nicht hinterlegtem rsETH über die LayerZero-Bridge von KelpDAO zu prägen und den Vermögenswert als Sicherheit bei Aave einzusetzen. Der Rahmen führt strengere Standards für das Onboarding von Assets, die Bridge-Konfiguration, Überwachungssysteme und Chain-Deployments ein, um Schwächen in der Bridge-Infrastruktur und in Offchain-Systemen zu adressieren, die ein protokollweites Risiko erzeugen können.
Aave Framework Establishes Four-Layer Risk Structure
Der Rahmen ist auf vier Ebenen aufgebaut: Asset-Risiko, Bridging-Risiko, Monitoring- und automatisierte Risk-Oracle-Systeme sowie Chain-Risiko. Unter der Asset-Risiko-Ebene muss jedes gelistete Asset Anforderungen erfüllen, die an Audits, Bug-Bounty-Abdeckung, Liquidität, Timelocks, Zeichnungsbefugnis, rechtliche Offenlegungen, Sichtbarkeit der Hinterlegung und die Abläufe des Issuers gebunden sind. Fehlende oder materiell schwache Bug-Bounty-Abdeckung, ungelöste Audit-Findings, keine Timelocks auf kritischen Upgrade-Pfaden, nicht offengelegte Signer-Strukturen oder undurchsichtige Hinterlegungsvereinbarungen würden als harte Blockbedingungen behandelt. Der Rahmen macht Asset-Reviews zu einem kontinuierlichen Prozess statt zu einer einmaligen Freigabe: Jedes Asset muss einem quartalsweisen Due-Diligence-Refresh unterzogen werden. Reviews außerhalb des Zyklus würden bei wesentlichen Änderungen ausgelöst, etwa bei neuen Chain-Deployments, Contract-Upgrades, Änderungen der Bridge-Route, Oracle-Updates oder Verschiebungen in der Reserve-Hinterlegung.
Bridge Security Requirements Include Independent Verifiers and Rate Limits
Aaves Bridge-Risikoebene führt Regeln für Cross-Chain-Assets ein. Bridge-Routen müssten dokumentierte Topologie, mindestens drei unabhängige Verifizierer, timelockierte Änderungen der Autorität, separate Pause-Pfade, pro Route Rate Limits, eine 24/7-Incident-Response-Abdeckung sowie dedizierte Monitoring-Teams vorweisen. Der Vorschlag beinhaltet neue Standards rund um Bridge-Offenlegungen, Verifizierer-Unabhängigkeit, Rate Limits, automatisiertes Monitoring und defensive Freeze-Mechanismen. Routen, die hinter den verpflichtenden Bridge-Anforderungen zurückbleiben, könnten mit niedrigeren Caps, niedrigeren Loan-to-Value-Verhältnissen oder Einschränkungen bei der Cross-Chain-Expansion konfrontiert werden. Der Rahmen setzt außerdem Standards für die Chains, auf denen Aave deployt: Chains mit schwächerer Infrastruktur, Liquidität, Governance oder Monitoring-Unterstützung erhalten engere Limits über jedes dort gelistete Asset hinweg.
Automated Monitoring Enables Asset Freezes Before Governance Response
Der Rahmen ergänzt Schutzmaßnahmen für Risiken, die sich ausbreiten können, bevor Governance Zeit hat zu reagieren. Aave könnte Assets automatisch einfrieren oder die Exponierung reduzieren, sobald Warnzeichen auftreten, während jede Maßnahme zur Wiederherstellung von Limits weiterhin eine menschliche Prüfung erfordern würde. Aaves Risk Stewards würden die Wiederherstellung und Parameteränderungen nach einem Alert übernehmen, während Umbrella als finale Sicherheitsschicht fungiert, falls die Verluste dennoch das Protokoll erreichen.
FAQ
Was hat Aaves Vorschlag für einen strengeren Risikorahmen ausgelöst?
Aave schlug den Rahmen nach dem KelpDAO-Exploit im April vor, bei dem Angreifer ungefähr 292 Millionen US-Dollar an nicht hinterlegtem rsETH über die LayerZero-Bridge von KelpDAO prägten und den Vermögenswert als Sicherheit auf Aave nutzten. Der Exploit zeigte Schwächen in der Bridge-Konfiguration und in der Offchain-Infrastruktur.
Was sind die vier Ebenen des vorgeschlagenen Risikorahmens von Aave?
Der Rahmen ist auf vier Ebenen aufgebaut: Asset-Risiko, Bridging-Risiko, Monitoring- und automatisierte Risk-Oracle-Systeme sowie Chain-Risiko. Diese Ebenen definieren, wie Assets vor dem Listing bewertet werden, wie sie nach dem Onboarding überprüft werden und wann die Exponierung reduziert oder eingestellt werden sollte.