Risk Framework
Cómo Avana propone, revisa y ejecuta cambios de riesgo en el Hub y los LP Collateral Spokes.
Descripción general
El Avana Risk Framework define cómo se proponen, comprueban y ejecutan los cambios de parámetros en el Hub y los LP Collateral Spokes. Cubre los controles usados cuando el protocolo ajusta supply y borrow caps, ajustes LT/LTV, entradas de tasas de interés, estado del mercado y otros parámetros que dependen de precios, utilización, profundidad del pool, concentración, volatilidad, comportamiento del peg, circuit breakers, salud de la posición y estado relacionado.
El colateral LP no es una clase de activo homogénea. Los LPs estables, los LPs de activos correlacionados, los pools ponderados, la liquidez concentrada y otros diseños AMM pueden tener cada uno su propia ruta de valoración específica del Spoke, ruta de liquidación y modo de fallo. El framework existe para que esas diferencias se reflejen en el proceso de actualización en lugar de ocultarse detrás de un único ajuste genérico de riesgo.
Tres roles se mantienen separados a lo largo de ese proceso: Avana Risk Initiator, Avana Risk Guardian y Avana Risk Defender. La parte que recomienda un cambio rutinario no es la misma que lo comprueba de forma independiente, y el rol que puede actuar durante una emergencia es intencionalmente más estrecho que la ruta rutinaria.
Regla operativa: reducing risk should be easier than expanding it.
Principios centrales
Separación de roles
El framework asigna proponer, revisar y contención de emergencia a actores distintos para que una sola parte no controle sola toda la ruta.
Ejecución restringida
Los cambios rutinarios de riesgo se ejecutan solo cuando permanecen dentro de los límites de política predefinidos y pasan las comprobaciones de validación.
Consistencia pública
La actualización descrita públicamente debe ser la misma que luego se pone en cola para ejecución.
Conciencia del Spoke
Cada LP collateral Spoke lleva sus propias reglas de listing, supuestos de oráculo, ruta de liquidación y perfil de riesgo.
Asimetría defensiva
El proceso está sesgado de forma intencional para que reducir riesgo sea más rápido y simple que ampliarlo.
Roles
Avana Risk Initiator
El rol que prepara y recomienda cambios rutinarios de riesgo para el Hub y los LP Collateral Spokes.
- Publicar la justificación y clasificar la actualización como defensiva u orientada al crecimiento
- Enviar actualizaciones rutinarias a la ruta de ejecución con timelock
- Recomendar cambios de supply caps, borrow caps, LT/LTV, reserve factor y tasas de interés dentro de rangos aprobados
- Iniciar des-riesgo a nivel de Spoke y onboarding de pools dentro de plantillas de Spoke preaprobadas
Avana Risk Guardian
El revisor independiente con autoridad de veto sobre cambios rutinarios en cola.
- Verificar que la actualización en cola coincida con la divulgación pública
- Comprobar que la acción permanezca dentro de los límites de política aprobados
- Rechazar actualizaciones basadas en supuestos inválidos de oráculo, liquidez o liquidación
- Cancelar una actualización en cola durante la ventana de timelock cuando cree inestabilidad obvia a nivel de Spoke o de Hub
Avana Risk Defender
El rol solo de emergencia usado para contener incidentes cuando la ruta normal con timelock es demasiado lenta.
- Reducir borrow caps o supply caps a niveles defensivos
- Congelar nuevos préstamos en un Spoke o congelar el uso de colateral para un pool, plantilla o Spoke
- Deshabilitar un adapter o ruta de préstamo específica cuando se cumplan condiciones de fallo predefinidas
- Bloquear la originación de nueva deuda bajo condiciones de emergencia sin usarse para optimización rutinaria ni acciones de crecimiento
Flujo de actualización
Los cambios rutinarios siguen una ruta fija para que el protocolo pueda distinguir el mantenimiento normal de parámetros de la contención de emergencia. La secuencia estándar es aviso público, envío, comprobaciones de límites, timelock, revisión del Guardian y ejecución si la propuesta no se veta.
Aviso público
El Risk Initiator publica el cambio previsto, por qué se necesita y el alcance que se espera que afecte.
Submission
El Risk Initiator coloca el cambio propuesto en la ruta de ejecución usada por el framework.
Validation
Las comprobaciones del framework confirman que la actualización permanece dentro de restricciones predefinidas y límites de política aprobados.
Timelock
Si la validación pasa, el cambio entra en una ventana de timelock en lugar de ejecutarse de inmediato.
Revisión del Guardian
Durante el timelock, el Risk Guardian revisa el payload exacto en cola y puede cancelarlo si es necesario.
Execution
Si el cambio sobrevive a la revisión, se ejecuta automáticamente tras expirar el timelock.
Ruta de emergencia
Si se cumplen condiciones de emergencia, el Risk Defender puede usar una ruta defensiva separada con autoridad más estrecha.
Clases de parámetros
No todos los cambios de parámetros conllevan el mismo riesgo, así que el framework los agrupa según cuánta autoridad deberían requerir y con qué rapidez deberían poder moverse.
Cambios defensivos
Estos son los cambios rutinarios más rápidos porque reducen la exposición del protocolo.
- Bajar borrow caps
- Bajar supply caps
- Reducir LTV o umbral de liquidación
- Congelar el uso de préstamo o de colateral
- Apretar ajustes del Spoke
Cambios rutinarios acotados
Estos siguen la ruta estándar Initiator -> Guardian -> timelock dentro de límites aprobados.
- Aumentos modestos de caps
- Ajustes modestos de parámetros dentro de rangos aprobados
- Agregar nuevos pools dentro de una plantilla de Spoke existente
Cambios a nivel de gobernanza
Estos quedan fuera del framework rutinario y requieren una ruta de decisión de nivel superior.
- Crear una nueva familia de Spoke
- Habilitar una nueva primitiva LP
- Agregar un nuevo modelo de oráculo
- Habilitar un nuevo liquidation adapter
- Ampliar materialmente la superficie de riesgo más allá de los supuestos preaprobados
Divulgación pública
Toda actualización rutinaria debería publicarse antes del envío en un formato que permita a desarrolladores, usuarios y revisores comparar el aviso con la acción exacta que luego se pone en cola.
Estándar mínimo de divulgación
- Spoke afectado
- Pools o plantillas afectados
- Parámetros actuales
- Parámetros propuestos
- Motivo de la actualización
- Si la actualización es defensiva u orientada al crecimiento
- Momento esperado de envío
- Ventana de timelock esperada
- Dependencias o supuestos relevantes
Una divulgación coherente facilita revisar una propuesta por ampliación de alcance, supuestos desalineados o simples errores de ejecución.
Acciones de emergencia
Las acciones de emergencia son para contención, no para ajuste rutinario. Deben usarse rara vez, mantenerse lo más estrechas posible y estructurarse para que el protocolo pueda volver a la ruta estándar una vez entendido el riesgo inmediato. El Risk Defender solo debería actuar cuando una condición de fallo definida o altamente probable haga insegura la ruta normal con timelock.
Triggers de emergencia
- Inconsistencia del oráculo
- Degradación de la ruta de liquidación
- Comportamiento anormal del pool
- Fallo de dependencia del wrapper
- Compromiso a nivel de adapter
- Inestabilidad súbita a nivel de Spoke
Divulgación requerida posterior a la acción
- The trigger
- La acción tomada
- La duración prevista
- La ruta de vuelta a la operación normal
La autoridad de emergencia existe solo para casos de fallo definidos o altamente probables en los que esperar la ruta normal con timelock es inseguro. No es una ruta para crecimiento o optimización rutinarios.
La recomendación, la revisión y la contención de emergencia se mantienen separadas porque el colateral LP es una colección de mercados con estructuras y modos de fallo distintos, no una lista intercambiable de activos.