Risikorahmen
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 Märkte unterscheiden sich in ihrer Vermögenszusammensetzung, Bewertungsmethoden, Liquidationswegen und Ausfallmodi. Stabile, korrelierte, gewichtete und konzentrierte Liquidität pools kann daher unterschiedliche Risikoparameter erfordern. Der Rahmen berücksichtigt diese Unterschiede bei der Überprüfung von Updates für einen Spoke oder pool.
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.
Betriebsregel: exposure-reducing actions follow a more direct path than changes that expand protocol risk.
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
Die öffentliche Bekanntgabe identifiziert die zur Ausführung eingereichte Parameteränderung, damit Prüfer die Benachrichtigung mit der in der Warteschlange befindlichen Nutzlast vergleichen können.
Spoke-Bewusstsein
Jeder LP-Collateral-Spoke trägt eigene Listing-Regeln, Oracle-Annahmen, Liquidationspfad und Risikoprofil.
Defensive Asymmetrie
Der Rahmen gibt Maßnahmen zur Verringerung der Exposition einen direkteren Weg als Änderungen, die das Protokollrisiko erhöhen.
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.
Öffentliche Bekanntmachung
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-Prüfung
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 werden nach ihrer Auswirkung auf das Risiko gruppiert. Jede Klasse definiert die benötigte Autorität und den Ausführungsweg, von begrenzten Routine-Updates bis hin zu Änderungen, die eine umfassendere Genehmigung durch die Governance erfordern.
Defensive Änderungen
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
Rutinäre begrenzte Änderungen
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
Änderungen auf Governance-Ebene
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
Die öffentliche Bekanntmachung erfolgt vor der Einreichung im routinemäßigen Aktualisierungsprozess. Sie erfasst die betroffenen Märkte und vorgeschlagenen Parameter, sodass Entwickler und Prüfer die angegebenen Änderungen mit der für die Ausführung vorgesehenen Nutzlast vergleichen können.
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
Der Vergleich dieser Felder mit der wartenden Nutzlast zeigt Unterschiede in den betroffenen Märkten, Parameterwerten, dem Zeitpunkt oder den Annahmen vor der Ausführung.
Notfallaktionen
Der Notfallpfad des Risiko-Verteidigers ist darauf beschränkt, definierte oder sehr wahrscheinliche Ausfälle einzudämmen, wenn das Warten auf die normale Zeitverriegelung unsicher wäre. Seine engere Befugnis erlaubt defensive Maßnahmen wie die Einschränkung von Ausleihungen oder das Deaktivieren eines betroffenen Adapters. Routinemäßige Parameteränderungen erfolgen weiterhin über den Initiator- und Guardian-Prozess.
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.
Die Trennung der Rollen für Vorschläge, Überprüfung und Notfälle gilt für LP Märkte, während jeder Markt seine eigenen Bewertungsannahmen, Risikogrenzen und Liquidationsverhalten beibehält.