Risk Framework
Come Avana propone, revisiona ed esegue le modifiche di rischio sull'Hub e sugli LP Collateral Spoke.
Panoramica
L'Avana Risk Framework definisce come le modifiche ai parametri vengono proposte, controllate ed eseguite sull'Hub e sugli LP Collateral Spoke. Copre i controlli usati quando il protocollo regola supply e borrow cap, impostazioni LT/LTV, input dei tassi di interesse, stato di mercato e altri parametri che dipendono da prezzi, utilizzo, profondità del pool, concentrazione, volatilità, comportamento del peg, circuit breaker, salute della posizione e stato correlato.
Il collaterale LP non è una classe di asset omogenea. LP stable, LP di asset correlati, pool weighted, liquidità concentrata e altri design AMM possono ciascuno avere il proprio percorso di valorizzazione specifico dello Spoke, percorso di liquidazione e failure mode. Il framework esiste perché quelle differenze siano riflesse nel processo di aggiornamento invece di restare nascoste dietro un'unica impostazione di rischio generica.
Tre ruoli restano separati lungo tutto quel processo: Avana Risk Initiator, Avana Risk Guardian e Avana Risk Defender. La parte che raccomanda una modifica di routine non è la stessa che la controlla in modo indipendente, e il ruolo che può agire durante un'emergenza è intenzionalmente più ristretto del percorso di routine.
Regola operativa: reducing risk should be easier than expanding it.
Principi core
Separazione dei ruoli
Il framework assegna proposta, revisione e containment di emergenza ad attori diversi, così una sola parte non controlla da sola l'intero percorso.
Esecuzione vincolata
Le modifiche di rischio di routine vengono eseguite solo quando restano entro i bound di policy predefiniti e superano i controlli di validazione.
Coerenza pubblica
L'aggiornamento descritto pubblicamente dovrebbe essere lo stesso aggiornamento effettivamente messo in coda per l'esecuzione.
Consapevolezza dello Spoke
Ogni LP Collateral Spoke porta le proprie regole di listing, assunzioni sugli oracoli, percorso di liquidazione e profilo di rischio.
Asimmetria difensiva
Il processo è intenzionalmente sbilanciato così ridurre il rischio è più rapido e semplice che espanderlo.
Ruoli
Avana Risk Initiator
Il ruolo che prepara e raccomanda le modifiche di rischio di routine per l'Hub e gli LP Collateral Spoke.
- Pubblicare la rationale e classificare l'aggiornamento come difensivo o orientato alla crescita
- Inviare aggiornamenti di routine nel percorso di esecuzione in timelock
- Raccomandare modifiche a supply cap, borrow cap, LT/LTV, reserve factor e tassi di interesse entro i range approvati
- Avviare de-risking a livello di Spoke e onboarding di pool all'interno di template Spoke preapprovati
Avana Risk Guardian
Il revisore indipendente con autorità di veto sulle modifiche di routine in coda.
- Verificare che l'aggiornamento in coda corrisponda alla disclosure pubblica
- Controllare che l'azione resti entro i bound di policy approvati
- Rifiutare aggiornamenti basati su assunzioni invalide di oracolo, liquidità o liquidazione
- Annullare un aggiornamento in coda durante la finestra di timelock quando crea instabilità evidente a livello di Spoke o Hub
Avana Risk Defender
Il ruolo solo-emergenza usato per contenere incidenti quando il percorso normale in timelock è troppo lento.
- Ridurre borrow cap o supply cap a livelli difensivi
- Bloccare nuovi prestiti su uno Spoke o bloccare l'uso del collaterale per un pool, template o Spoke
- Disabilitare un adapter o percorso di prestito specifico quando si verificano condizioni di fallimento predefinite
- Bloccare l'origination di nuovo debito in condizioni di emergenza senza essere usato per ottimizzazione di routine o azioni di crescita
Flusso di aggiornamento
Le modifiche di routine seguono un percorso fisso così il protocollo può distinguere la manutenzione normale dei parametri dal containment di emergenza. La sequenza standard è avviso pubblico, submission, controlli sui bound, timelock, revisione del Guardian ed esecuzione se la proposta non viene vetata.
Avviso pubblico
Il Risk Initiator pubblica la modifica prevista, perché è necessaria e lo scope che si prevede di interessare.
Submission
Il Risk Initiator inserisce la modifica proposta nel percorso di esecuzione usato dal framework.
Validation
I controlli del framework confermano che l'aggiornamento resta entro i vincoli predefiniti e i bound di policy approvati.
Timelock
Se la validazione passa, la modifica entra in una finestra di timelock invece di essere eseguita immediatamente.
Revisione del Guardian
Durante il timelock, il Risk Guardian revisiona l'exact payload in coda e può annullarlo se necessario.
Execution
Se la modifica supera la revisione, viene eseguita automaticamente dopo la scadenza del timelock.
Percorso di emergenza
Se si verificano condizioni di emergenza, il Risk Defender può usare un percorso difensivo separato con autorità più ristretta.
Classi di parametri
Le modifiche ai parametri non portano tutte lo stesso rischio, quindi il framework le raggruppa in base a quanta autorità dovrebbero richiedere e quanto rapidamente dovrebbero potersi muovere.
Modifiche difensive
Queste sono le modifiche di routine più rapide perché riducono l'esposizione del protocollo.
- Abbassare i borrow cap
- Abbassare i supply cap
- Ridurre LTV o soglia di liquidazione
- Bloccare uso di prestito o collaterale
- Restringere le impostazioni dello Spoke
Modifiche di routine delimitate
Queste seguono il percorso standard Initiator -> Guardian -> timelock entro i bound approvati.
- Aumenti modesti dei cap
- Tuning modesto dei parametri entro i range approvati
- Aggiungere nuovi pool all'interno di un template Spoke esistente
Modifiche a livello di governance
Queste sono fuori dal framework di routine e richiedono un percorso decisionale di livello superiore.
- Creare una nuova famiglia di Spoke
- Abilitare un nuovo primitivo LP
- Aggiungere un nuovo modello di oracolo
- Abilitare un nuovo adapter di liquidazione
- Espandere materialmente la superficie di rischio oltre le assunzioni preapprovate
Disclosure pubblica
Ogni aggiornamento di routine dovrebbe essere pubblicato prima della submission in un formato che consenta a sviluppatori, utenti e revisori di confrontare l'avviso con l'azione esatta che viene poi messa in coda.
Standard minimo di disclosure
- Spoke interessato
- Pool o template interessati
- Parametri correnti
- Parametri proposti
- Motivo dell'aggiornamento
- Se l'aggiornamento è difensivo o orientato alla crescita
- Tempistica di submission prevista
- Finestra di timelock prevista
- Dipendenze o assunzioni rilevanti
Una disclosure coerente rende più facile revisionare una proposta per scope creep, assunzioni disallineate o semplici errori di esecuzione.
Azioni di emergenza
Le azioni di emergenza sono per il containment, non per il tuning di routine. Dovrebbero essere usate raramente, tenute il più ristrette possibile e strutturate così che il protocollo possa tornare al percorso standard una volta compreso il rischio immediato. Il Risk Defender dovrebbe agire solo quando una condizione di fallimento definita o altamente probabile rende non sicuro il percorso normale in timelock.
Trigger di emergenza
- Inconsistenza dell'oracolo
- Degrado del percorso di liquidazione
- Comportamento anomalo del pool
- Fallimento di dipendenza wrapper
- Compromise a livello di adapter
- Instabilità improvvisa a livello di Spoke
Disclosure post-azione richiesta
- The trigger
- L'azione intrapresa
- La durata prevista
- Il percorso di ritorno al funzionamento normale
L'autorità di emergenza esiste solo per casi di fallimento definiti o altamente probabili in cui aspettare il percorso normale in timelock non è sicuro. Non è un percorso per crescita o ottimizzazione di routine.
Raccomandazione, revisione e containment di emergenza restano separati perché il collaterale LP è una collezione di mercati con strutture e failure mode diverse, non un unico elenco di asset intercambiabili.