Directrices de protocolo unificadas presentadas por Aave Labs para optimizar la integración de activos digitales en múltiples plataformas

Tabla de contenido Aave Labs ha presentado un ARFC que propone un marco de listado de activos técnicos estandarizado en Aave V3, V4 y Horizon. La propuesta se centra en cómo se enumeran, mantienen y amplían los activos dentro del sistema de gobernanza del protocolo. Define una línea de base unificada para la evaluación técnica que cubre el comportamiento de ERC20, el diseño de Oracle y los controles de acceso. El marco tiene como objetivo hacer que las evaluaciones de activos sean más consistentes, transparentes y repetibles en todas las decisiones de gobernanza. Aave Labs diseñó el marco para mejorar la coherencia en las decisiones de incorporación de activos en múltiples implementaciones. La propuesta responde a una complejidad cada vez mayor a medida que Aave se expande a través de cadenas y tipos de activos. Formaliza cómo deben estructurarse las revisiones técnicas, especialmente para los contribuyentes a la gobernanza y los proveedores de riesgos. El objetivo es reducir la ambigüedad al evaluar si los activos cumplen con los requisitos técnicos básicos. El marco alinea las revisiones de activos con el Marco de clasificación de activos de Aave. Cada activo debe asignarse a su categoría antes de comenzar una evaluación más profunda. Esta clasificación determina qué tan estrictos se vuelven ciertos requisitos durante la revisión técnica. Los activos puente o que generan rendimiento enfrentan un escrutinio adicional según las reglas de riesgo específicas de cada categoría. Las reglas de preselección constituyen el primer paso antes de que se lleve a cabo una revisión completa. Los activos deben implementarse, verificarse y asignarse a una lista comparable cuando sea posible. La gobernanza también verifica la coherencia del contrato con las versiones auditadas y la alineación entre cadenas. Los activos que no pasan estas comprobaciones no pasan a la evaluación de incorporación completa. La metodología de evaluación separa los hallazgos fácticos de las recomendaciones. Los revisores deben documentar claramente los contratos, los riesgos, las mitigaciones y la exposición residual. Los informes pueden incluir calificaciones cualitativas pero evitan umbrales de puntuación fijos. Esta estructura garantiza que la gobernanza mantenga la flexibilidad al tiempo que mejora la claridad técnica. Aave Labs propone un marco de listado de activos técnicos estandarizado Aave Labs propuso un ARFC para adoptar un marco de listado de activos técnicos estandarizado para activos que buscan listado, listado continuo o expansión de parámetros de materiales en Aave V3, Aave V4 y Horizon. El marco… pic.twitter.com/jEKR9H0VcW – Wu Blockchain (@WuBlockchain) 29 de mayo de 2026 El cumplimiento de ERC20 constituye la base de los requisitos técnicos del marco. Los tokens deben comportarse de manera predecible sin comisiones por transferencia ni mecanismos de rebase. Aave también restringe los enlaces ERC777 y la lógica de transferencia incompatible. Estas limitaciones garantizan una contabilidad y componibilidad estables en todas las integraciones de DeFi. El diseño de Oracle sigue siendo una dependencia central en el proceso de cotización. Aave requiere fuentes de precios de Chainlink o adaptadores CAPO aprobados para los activos de rendimiento. Se deben validar la confiabilidad de la alimentación, los límites de latidos y los umbrales de desviación. Una infraestructura de Oracle débil o faltante puede retrasar o bloquear la incorporación de activos. Las reglas de control de acceso definen cómo se evalúan y clasifican los roles privilegiados. El marco clasifica la seguridad de roles desde el control de una sola clave hasta los modelos de gobernanza DAO. La autoridad de acuñación, pausa y actualización requiere una sólida protección multifirma o bloqueo de tiempo. Las configuraciones débiles pueden reducir directamente los niveles de exposición permitidos en las decisiones de gobernanza. Los sistemas puente, las auditorías y las dependencias externas completan la revisión de la superficie de riesgo. Los activos entre cadenas deben documentar claramente el suministro canónico y la arquitectura puente. El historial de auditoría no debe mostrar vulnerabilidades críticas no resueltas en el código implementado. Dependencias como los sistemas de custodia o de participación también se evalúan en busca de riesgo de falla.