Aave Labs propone un marco de referencia de credenciales técnicas; los activos con fallas técnicas graves se enfrentan a restricciones para su listado

Aave Labs publicó el 29 de mayo una propuesta ARFC (Aave Request for Comments), en la que propone establecer un marco estandarizado para listar activos técnicos en Aave V3, V4 y Horizon. Los activos con defectos técnicos importantes se enfrentarán a la reducción de los límites de préstamo, la limitación de parámetros de colateral, el retraso del lanzamiento o la recomendación de rechazar el protocolo de acceso. La propuesta confirma que el marco no sustituye el análisis de riesgos de mercado ni el juicio de gobernanza, sino que proporciona un punto de referencia mínimo de calificación técnica.

Los siete “riesgos ocultos” confirmados en la propuesta ARFC y el diseño central del marco

En la propuesta, Aave Labs confirma que el marco está diseñado para abordar siete categorías de “riesgos ocultos”: acuñación sin límites, control de actualizaciones débil, suministro puenteado inconsistente, rutas de reembolso no transparentes, dependencia de custodia fuera de cadena, rutas de oráculos poco fiables y falta de auditorías para dependencias externas. La propuesta enfatiza especialmente revisiones adicionales para activos con dependencias fuera de cadena como activos entre cadenas, activos generadores de rendimiento y RWA, incluidas la estructura del puente, los arreglos legales fuera de cadena, los mecanismos de custodia y la integridad del suministro.

El marco define seis niveles de seguridad para funciones privilegiadas (de nivel 0 a nivel 5), desde ausencia de retraso con una sola clave (nivel 0) hasta gobernanza DAO en cadena con bloqueo de tiempo (nivel 5). En los casos con un nivel de seguridad inferior a 2, se definen como “configuración de seguridad débil”, lo que activará restricciones de acceso más estrictas. En cuanto a las rutas del oráculo, Chainlink es la principal fuente de datos requerida; cualquier diseño que no sea Chainlink debe tener una razón explícita y justificable.

El flujo de seis pasos de integración de gobernanza y el mecanismo de actualización anual confirmados en la propuesta

Aave Labs confirma que el marco debe integrarse en el proceso de lanzamiento de activos con seis pasos: preselección (confirmar la clasificación AAcA y la verificación del contrato), revisión técnica (evaluar según los ocho capítulos centrales del marco), coordinación con proveedores de riesgo, publicación de documentos de gobernanza, seguimiento de correcciones y actualizaciones continuas.

La propuesta confirma que la evaluación de todos los activos listados activos debe actualizarse una vez al año y, tras cambios importantes, actualizarse de inmediato, incluyendo actualizaciones de contratos, despliegues en nuevas cadenas, cambios de enrutamiento del puente, cambios de tenedores de roles privilegiados y eventos de seguridad. La entidad emisora debe notificar con antelación a Aave Labs y al DAO cualquier cambio relevante en función de sus obligaciones continuas.

Preguntas frecuentes

¿Cuál es el estado de gobernanza actual de la propuesta ARFC de Aave Labs y ya fue aprobada?

ARFC forma parte del proceso “Aave Request for Comments”, perteneciente a la fase de discusión de propuestas de gobernanza y aún no ha entrado en votación o aprobación formal. La propuesta requiere revisión y votación por parte de participantes de la gobernanza de Aave DAO para implementarse oficialmente.

El alcance de este marco, ¿qué escenarios cubre y en cuáles no se aplica?

Según la propuesta confirmada, el marco se aplica a: la incorporación de activos en cualquier instancia de Aave V3, V4 y Horizon; cambios importantes de parámetros en activos ya listados; y actualizaciones técnicas periódicas o no periódicas. El marco no sustituye el análisis de riesgos de liquidez y profundidad de mercado; esta parte sigue siendo responsabilidad de los proveedores de riesgo del DAO.

¿Qué tipos de defectos técnicos activan el rechazo de acceso o la limitación del lanzamiento?

Según la propuesta confirmada, los defectos que activan las limitaciones incluyen: acuñación sin límites, configuración de seguridad débil con niveles de seguridad para roles privilegiados en 0 o 1, suministro del puente inconsistente, falta de una ruta de oráculo adecuada y problemas de auditoría graves o de alto riesgo que no hayan sido resueltos. Estos defectos provocarán la reducción de los límites de préstamo, la limitación de parámetros del colateral o la recomendación de rechazar el protocolo de acceso.