El 10 de marzo, una configuración técnica errónea en la infraestructura del oráculo de Aave provocó liquidaciones forzadas, poniendo a prueba la dependencia de DeFi en sistemas de gestión automatizada de riesgos.
El evento de liquidación de $21.7M en Aave
Los usuarios de Aave sufrieron aproximadamente $21.7M en liquidaciones el 10 de marzo después de que una restricción en cadena en el agente de riesgo de Wrapped stETH (wstETH) causara una subvaloración de los activos de garantía. En total, 34 cuentas fueron liquidadas porque el protocolo valoró wstETH aproximadamente un 2.85% por debajo de su verdadero precio de mercado.
El protocolo finalmente no incurrió en deudas incobrables y compensó a los usuarios afectados. Sin embargo, el evento expuso debilidades estructurales en cómo la gestión automatizada de riesgos de DeFi ejecuta cambios sin intervención humana. También mostró con qué rapidez un parámetro mal configurado puede generar liquidaciones a gran escala de posiciones que de otro modo serían saludables.
Según los datos posteriores al incidente, los usuarios que mantenían wstETH como garantía contra deuda de WETH parecían estar subcolateralizados solo debido a la valoración incorrecta. Además, sus posiciones habrían permanecido seguras a los precios reales del mercado, lo que subraya que la falla fue infraestructural en lugar de impulsada por el mercado.
La mecánica del fallo de CAPO
El incidente se originó en el sistema CAPO (Correlated Asset Price Oracle) de Aave, construido para proteger contra la manipulación de activos con precios correlacionados, como wstETH y stETH. CAPO obtiene el ratio wstETH/stETH de Lido, aplica un límite protector a través del WstETHPriceCapAdapter, luego multiplica el resultado por el precio de ETH para obtener una valoración en USD.
A las 12:47 UTC del 10 de marzo, el motor Edge Risk off-chain de Chaos Labs recomendó actualizar el precio máximo de CAPO a 1.1933947 wstETH/ETH. En ese momento, el ratio real del mercado se situaba en 1.2285, lo que implica que el límite propuesto ya estaba materialmente por debajo de los precios vigentes.
El AgentHub de BGD ejecutó esta recomendación un bloque después a través de su sistema de Oracle Automation, sin ningún tiempo de revisión entre la recomendación off-chain y la implementación en cadena. Dicho esto, este pipeline instantáneo es precisamente lo que convirtió un error de configuración en un evento de impacto inmediato para los usuarios.
El desajuste resultante del 2.85% causó que el protocolo subvalorara el colateral de wstETH. Como resultado, las cuentas que deberían haber estado seguras según los datos reales del mercado fueron marcadas como subcolateralizadas y liquidadas. La cascada procesó 10,938 wstETH en 34 cuentas y generó aproximadamente 512 ETH en bonificaciones de liquidación para los liquidadores antes de que se detectara y revirtiera el problema.
Causa raíz técnica: desalineación de snapshot
La falla técnica se originó por un desajuste de parámetros entre snapshotRatio y snapshotTimestamp dentro de CAPO. El Agente de Riesgo off-chain de Chaos Labs calculó un ratio objetivo de aproximadamente 1.2282, anclado a un snapshot de 7 días de antigüedad. Sin embargo, el sistema en cadena limitó la rapidez con la que el ratio podía moverse.
Bajo las reglas protectoras de CAPO, el valor anterior en cadena de aproximadamente 1.1572 solo podía aumentar un 3% cada 3 días. En la práctica, esto significaba que el ratio solo podía aumentar a aproximadamente 1.1919 en una sola actualización, incluso si el objetivo off-chain se había desviado más alto. Además, la actualización no alineó estas restricciones con la lógica del timestamp.
El snapshotTimestamp se configuró como si el anclaje en cadena ya reflejara el ratio off-chain de 7 días de antigüedad de 1.2282. Esto creó una inconsistencia crítica entre las referencias de tiempo y precio. En consecuencia, CAPO calculó un tipo de cambio máximo de aproximadamente 1.1939, alrededor de un 2.85% por debajo del tipo de mercado real de 1.2285.
Este incidente marcó la primera actualización automatizada impulsada en cadena por el CAPO Risk Agent de Chaos Labs desde su implementación. Dicho esto, el hecho de que la ejecución inaugural produjera liquidaciones de usuarios hizo que la configuración errónea fuera particularmente alarmante tanto para la gobernanza como para los usuarios.
La cadena de ejecución automatizada de Edge Risk a AgentHub
Edge Risk es el motor de riesgo off-chain propietario de Chaos Labs que prepara e impulsa cambios de parámetros desde una dirección designada. AgentHub, desarrollado por BGD, escucha estos cambios utilizando Oracle Automation y luego los propaga al protocolo.
El cambio de parámetro defectuoso se movió a través del stack de riesgo automatizado de Chaos Labs en una secuencia de dos transacciones. Primero, el motor Edge Risk recomendó cambiar el límite a 1.191926 wstETH/ETH en la transacción 0xfbafeaa8c58dd6d79f88cdf5604bd25760964bc8fc0e834fe381bb1d96d3db95. Luego, AgentHub ejecutó el cambio un bloque después a través de la transacción 0x32c64151469cf2202cbc9581139c6de7b34dae2012eba9daf49311265dfe5a1e.
Las liquidaciones diarias en Aave en febrero fueron relativamente modestas, rara vez superando los $5M, ya que las condiciones del mercado se mantuvieron estables. El pico del 10 de marzo a $21.6M se destaca como un valor atípico aislado, aproximadamente un salto de 4 veces desde los niveles típicos. Además, los volúmenes de liquidación volvieron rápidamente a la línea base después de la corrección, confirmando que el estrés provino de la ruta del oráculo en lugar de una insolvencia más amplia del protocolo.
Este comportamiento reforzó la conclusión de que el problema de precios de wstETH fue una falla de configuración discreta. No fue un síntoma de deterioro de la calidad del colateral, problemas de liquidez o desapalancamiento sistémico dentro del ecosistema de Aave.
Detección, mitigación y plan de compensación de liquidación
La configuración errónea fue detectada en minutos, lo que provocó una respuesta acelerada al incidente por parte del equipo de Aave y sus proveedores de riesgo. Para contener una mayor exposición, los límites de préstamo de wstETH tanto en Aave Core como en Aave Prime se redujeron rápidamente a 1, congelando efectivamente la nueva actividad de préstamo contra ese activo.
A través de la intervención manual de Risk Steward, el equipo realineó el snapshotRatio con el snapshotTimestamp en vivo, restaurando el feed del oráculo a su valor correcto. Se impulsó una corrección del oráculo a través de la transacción 0xb883ad2f1101df8d48f014ba308550f3251c2e0a401e7fc9cf09f9c2a158259d, mientras que los cambios en el límite de préstamo para establecer la capacidad de préstamo de wstETH en 1 wstETH se ejecutaron a través de la transacción 0x34f568b28dbcaf6a8272038ea441cbc864c8608fe044c590f9f03d0dac9cf7f8.
A pesar de la venta forzada, el protocolo no incurrió en deudas incobrables y publicó un análisis detallado posterior en los foros de gobernanza de Aave. Sin embargo, las pérdidas de los usuarios por las liquidaciones requirieron una respuesta política separada, lo que finalmente condujo a un plan de compensación de liquidación estructurado.
Para compensar las cuentas afectadas, Aave recuperó 141.5 ETH en bonificaciones de liquidación a través de reembolsos de BuilderNet. La tesorería de la DAO luego cubrió la brecha restante, con una restitución total para los usuarios limitada a 358 ETH. Es importante destacar que el plan se implementó a través de una Aave Improvement Proposal (AIP) directa, asegurando que los usuarios afectados recibieran compensación completa a pesar de que el error se originó en la infraestructura.
Contexto del mercado alrededor del incidente del 10 de marzo
La actividad cross-chain en Aave mostró un crecimiento robusto de usuarios durante el período de febrero a marzo. Por ejemplo, Avalanche registró 38,445 usuarios depositantes el 10 de febrero, mientras que Base registró 31,763 usuarios depositantes el 6 de marzo, solo cuatro días antes del evento de liquidación impulsado por el oráculo.
Estos picos destacan el creciente compromiso de los usuarios en las redes respaldadas por Aave, incluso cuando el protocolo navegó un incidente técnico complejo. Además, los depósitos y préstamos generales de Aave se mantuvieron estables durante principios de 2026, lo que sugiere que la confianza en el diseño central del protocolo no se debilitó materialmente después del evento.
La estabilidad de los depósitos, combinada con la rápida normalización de las liquidaciones, subraya que el error de precios de wstETH surgió de problemas de configuración, no de un estrés fundamental en los mercados de colateral. Dicho esto, el riesgo de concentración en los proveedores de automatización y las rutas de oráculos sigue siendo una preocupación estructural para las plataformas DeFi a la escala de Aave.
Gobernanza, transparencia y el futuro de la ejecución automatizada de oráculos
El incidente del 10 de marzo ilustra las compensaciones de gobernanza creadas por la ejecución automatizada de oráculos en los principales protocolos de préstamos DeFi. Edge Risk de Chaos Labs recomendó un límite por debajo del mercado, AgentHub de BGD lo ejecutó un bloque después, y las liquidaciones siguieron en minutos, dejando casi sin tiempo para la intervención humana.
Aave respondió con detección rápida, acciones correctivas decisivas y compensación completa para los usuarios financiada en parte por la tesorería de la DAO. Sin embargo, el episodio reveló deficiencias en la validación previa a la ejecución y destacó los riesgos de la dependencia excesiva de un único motor de riesgo propietario. En particular, la naturaleza cerrada de los cálculos de Chaos Labs Edge Risk limita la verificación independiente y coloca un control operativo significativo en manos de proveedores de servicios externos.
A medida que más protocolos DeFi adoptan marcos automatizados de CAPO Risk Agent y sistemas similares, el incidente muestra que la gobernanza debe incorporar pruebas robustas, ventanas de revisión explícitas y supervisión transparente. Además, la arquitectura más amplia del oráculo de Aave probablemente necesitará capas de seguridad adicionales, como verificaciones cruzadas de múltiples fuentes o mecanismos de implementación escalonada, para garantizar que futuros errores técnicos no se traduzcan directamente en pérdidas para los usuarios.
En resumen, las liquidaciones del 10 de marzo no fueron una crisis de mercado, sino una prueba de estrés de gobernanza e infraestructura. La combinación de automatización, ejecución rápida y modelado de riesgo opaco subraya por qué los protocolos DeFi deben equilibrar la eficiencia con salvaguardas transparentes y auditables para proteger a los usuarios.
Source: https://en.cryptonomist.ch/2026/03/23/aave-oracle-liquidations/
