Risk Framework
Wie Avana Risikoänderungen über Hub und LP Collateral Spokes vorschlägt, prüft und ausführt.
Überblick
Das Avana Risk Framework definiert, wie Parameteränderungen über Hub und LP Collateral Spokes vorgeschlagen, geprüft und ausgeführt werden. Es deckt die Controls ab, wenn das Protokoll Supply- und Borrow-Caps, LT/LTV-Settings, Zinsinputs, Marktstatus und andere Parameter anpasst, die von Preisen, Utilization, Pool-Tiefe, Konzentration, Volatilität, Peg-Verhalten, Circuit Breakers, Positions-Health und verwandtem State abhängen.
LP-Collateral ist keine homogene Asset-Klasse. Stable LPs, korrelierte Asset-LPs, gewichtete Pools, Concentrated Liquidity und andere AMM-Designs können jeweils eigenen Spoke-spezifischen Bewertungs- und Liquidationspfad sowie Failure Mode haben. Das Framework existiert, damit diese Unterschiede im Update-Prozess sichtbar werden — statt hinter einem generischen Risikoeinstellung zu verschwinden.
Drei Rollen bleiben durchgehend getrennt: Avana Risk Initiator, Avana Risk Guardian und Avana Risk Defender. Die Partei, die eine Routineänderung empfiehlt, ist nicht dieselbe, die sie unabhängig prüft, und die Rolle, die im Notfall handeln kann, ist bewusst enger als der Routinepfad.
Operating rule: reducing risk should be easier than expanding it.
Kernprinzipien
Rollentrennung
Das Framework weist Vorschlagen, Review und Notfalleindämmung unterschiedlichen Akteuren zu, damit eine Partei nicht den vollen Pfad allein kontrolliert.
Eingeschränkte Ausführung
Routinemäßige Risikoänderungen werden nur ausgeführt, wenn sie innerhalb vordefinierter Policy-Bounds bleiben und Validierungschecks bestehen.
Öffentliche Konsistenz
Das öffentlich beschriebene Update sollte dasselbe Update sein, das tatsächlich zur Ausführung gequeued wird.
Spoke Awareness
Jeder LP-Collateral-Spoke trägt eigene Listing-Regeln, Oracle-Annahmen, Liquidationspfad und Risikoprofil.
Defensive Asymmetrie
Der Prozess ist bewusst so geneigt, dass Risikoreduktion schneller und einfacher ist als Risikoausweitung.
Rollen
Avana Risk Initiator
Die Rolle, die routinemäßige Risikoänderungen für Hub und LP Collateral Spokes vorbereitet und empfiehlt.
- Begründung veröffentlichen und das Update als defensiv oder wachstumsorientiert klassifizieren
- Routine-Updates in den timelocked Ausführungspfad einreichen
- Supply Caps, Borrow Caps, LT/LTV, Reserve Factor und Zinsänderungen innerhalb freigegebener Ranges empfehlen
- Spoke-Level-De-Risking und Pool-Onboarding innerhalb vorab freigegebener Spoke-Templates initiieren
Avana Risk Guardian
Der unabhängige Reviewer mit Veto-Authority über gequeueute Routineänderungen.
- Prüfen, dass das gequeueute Update der öffentlichen Offenlegung entspricht
- Prüfen, dass die Aktion innerhalb freigegebener Policy-Bounds bleibt
- Updates ablehnen, die auf ungültigen Oracle-, Liquiditäts- oder Liquidationsannahmen beruhen
- Ein gequeueutes Update im Timelock-Fenster canceln, wenn es offensichtliche Spoke- oder Hub-Level-Instabilität erzeugt
Avana Risk Defender
Die ausschließlich für Notfälle genutzte Rolle zur Eindämmung von Incidents, wenn der normale Timelock-Pfad zu langsam ist.
- Borrow Caps oder Supply Caps auf defensive Levels senken
- Neue Ausleihen auf einem Spoke einfrieren oder Collateral-Nutzung für einen Pool, ein Template oder einen Spoke einfrieren
- Einen spezifischen Adapter oder Ausleihpfad deaktivieren, wenn vordefinierte Failure-Bedingungen erfüllt sind
- Neue Schuldorigination unter Notfallbedingungen blockieren — ohne für routinemäßige Optimierung oder Wachstum genutzt zu werden
Update-Flow
Routineänderungen folgen einem festen Pfad, damit das Protokoll normale Parameterpflege von Notfalleindämmung unterscheiden kann. Die Standardsequenz ist Public Notice, Submission, Bound Checks, Timelock, Guardian Review und Ausführung, wenn der Vorschlag nicht vetoed wird.
Public Notice
Der Risk Initiator veröffentlicht die geplante Änderung, warum sie nötig ist und welchen Scope sie voraussichtlich betrifft.
Submission
Der Risk Initiator legt die vorgeschlagene Änderung in den vom Framework genutzten Ausführungspfad.
Validation
Framework-Checks bestätigen, dass das Update innerhalb vordefinierter Constraints und freigegebener Policy-Bounds bleibt.
Timelock
Besteht die Validierung, geht die Änderung in ein Timelock-Fenster statt sofort auszuführen.
Guardian Review
Während des Timelocks prüft der Risk Guardian die exakte gequeueute Payload und kann sie bei Bedarf canceln.
Execution
Überlebt die Änderung den Review, wird sie nach Ablauf des Timelocks automatisch ausgeführt.
Notfallpfad
Sind Notfallbedingungen erfüllt, kann der Risk Defender einen separaten defensiven Pfad mit engerer Authority nutzen.
Parameterklassen
Parameteränderungen tragen nicht alle dasselbe Risiko — das Framework gruppiert sie danach, wie viel Authority sie brauchen und wie schnell sie sich bewegen dürfen.
Defensive Changes
Das sind die schnellsten Routineänderungen, weil sie Protokoll-Exposure reduzieren.
- Borrow Caps senken
- Supply Caps senken
- LTV oder Liquidationsschwellenwert senken
- Ausleihe oder Collateral-Nutzung einfrieren
- Spoke-Settings straffen
Routine Bounded Changes
Diese folgen der Standardroute Initiator -> Guardian -> Timelock innerhalb freigegebener Bounds.
- Moderate Cap-Erhöhungen
- Moderate Parametertuning innerhalb freigegebener Ranges
- Neue Pools innerhalb eines bestehenden Spoke-Templates hinzufügen
Governance-Level Changes
Diese liegen außerhalb des Routine-Frameworks und brauchen einen höherstufigen Entscheidungspfad.
- Eine neue Spoke-Familie erstellen
- Ein neues LP-Primitive aktivieren
- Ein neues Oracle-Modell hinzufügen
- Einen neuen Liquidation Adapter aktivieren
- Die Risikofläche materiell über vorab freigegebene Annahmen hinaus erweitern
Öffentliche Offenlegung
Jedes Routine-Update sollte vor Einreichung in einem Format veröffentlicht werden, das Entwicklern, Nutzern und Reviewern erlaubt, die Notice mit der später gequeueten exakten Aktion zu vergleichen.
Mindeststandard für Offenlegung
- Betroffener Spoke
- Betroffene Pools oder Templates
- Aktuelle Parameter
- Vorgeschlagene Parameter
- Grund für das Update
- Ob das Update defensiv oder wachstumsorientiert ist
- Erwarteter Einreichungszeitpunkt
- Erwartetes Timelock-Fenster
- Relevante Abhängigkeiten oder Annahmen
Konsistente Offenlegung macht es leichter, einen Vorschlag auf Scope Creep, mismatched Annahmen oder einfache Ausführungsfehler zu prüfen.
Notfallaktionen
Notfallaktionen dienen der Eindämmung, nicht dem Routine-Tuning. Sie sollten selten genutzt, so eng wie möglich gehalten und so strukturiert sein, dass das Protokoll zum Standardpfad zurückkehren kann, sobald das unmittelbare Risiko verstanden ist. Der Risk Defender sollte nur handeln, wenn eine definierte oder hochwahrscheinliche Failure-Bedingung den normalen Timelock-Pfad unsicher macht.
Notfall-Trigger
- Oracle-Inkonsistenz
- Verschlechterung des Liquidationspfads
- Abnormales Pool-Verhalten
- Wrapper-Dependency-Failure
- Adapter-Level-Kompromittierung
- Plötzliche Spoke-Level-Instabilität
Erforderliche Post-Action-Offenlegung
- The trigger
- Die ergriffene Aktion
- Die vorgesehene Dauer
- Der Pfad zurück zum Normalbetrieb
Notfall-Authority existiert nur für definierte oder hochwahrscheinliche Failure-Fälle, in denen Warten auf den normalen Timelock-Pfad unsicher ist. Sie ist kein Pfad für routinemäßiges Wachstum oder Optimierung.
Empfehlung, Review und Notfalleindämmung bleiben getrennt, weil LP-Collateral eine Sammlung von Märkten mit unterschiedlichen Strukturen und Failure Modes ist — keine austauschbare Asset-Liste.