50 millones USDT cambiados por 35.000 USD AAVE: ¿Cómo ocurrió el desastre? ¿A quién debemos culpar?

Este artículo es de: @Ehsan1579

Recopilado por: Ethan, Odaily Planet Daily

Con solo mirar el título del evento, uno podría pensar erróneamente que se trata de un ataque de explotación de vulnerabilidades.

El núcleo del evento es: alguien cambió USDT por $50.4 millones por AAVE por valor de solo $35.900.

Realmente me sorprendió cuando me enteré por primera vez de esto. Por lo tanto, revisé a fondo todo el evento: seguimiento de transacciones, rutas de solucionadores, llamadas a contratos, reservas históricas, datos de liquidación, procesos de adaptadores, código de interfaz Aave, SDK de préstamo flash CoW y el código de enrutamiento que determina si la cotización es "razonable".

Esto no es un ataque hacker. El protocolo básico de Aave no cometió ningún error. El asentamiento de vacas no cometió un error. Uniswap no cometió un error. SushiSwap no cometió un error. La transacción era válida, la firma era válida y todos los contratos se ejecutaban estrictamente de acuerdo con el código. Sin embargo, casi todo el valor económico se destruyó simplemente porque la ruta que se le permitió tomar era absurdamente irrazonable.

La cadena pública no tenía ningún problema; el problema era el enrutamiento.

En mi opinión, minimizar este incidente como un mero "error operativo del usuario" no es una actitud objetiva o rigurosa. De hecho, el usuario completó la firma de la orden, pero todo el sistema de software permitió una operación que involucró casi 50 millones de dólares en garantías para completar la cotización, firma, planificación de rutas y ejecución final, todo lo cual apunta a un fondo común de baja liquidez que tiene solo unos 331 AAVE. Esto debería haber sido completamente imposible, y al menos debería haber sido interceptado y rechazado firmemente por el sistema antes de que se iniciara la etapa de arreglo.

Información básica Rastreo de la transacción

El hash de esta transacción anormal es: 0x9fa9feab3c1989a33424728c23e6de07a40a26a98ff7ff5139f3492ce430801f, confirmado el 12 de marzo de 2026, a la altura del bloque mainnet de Ethereum 24643151, con el índice de transacción 1, consumiendo 3.780.570 unidades de gas, y la transacción ejecutada con éxito. La dirección de monedero perteneciente a la orden comienza con 0x98b9, mientras que la dirección de solver de ejecución real (emisor de transacciones) comienza con 0x3980, marcada como tsolver en los datos de competencia de CoW.

En primer lugar, es importante entender que no se trata de un simple cambio USDT a AAVE a nivel de billetera. El token vendido es aEthUSDT, que es el certificado de depósito USDT que devenga intereses en la plataforma Aave. El token comprado es aEthAAVE, que es el certificado de depósito AAVE que devenga intereses en la plataforma Aave. Por lo tanto, se trata en realidad de una permuta de garantías de Aave llevada a cabo a través del sistema de liquidación del protocolo de la Unión Europea y su proceso de adaptación de préstamos de urgencia.

Antes de la transacción, la cartera tenía aproximadamente 50.432.693.075254 aEthUSDT y 0 aEthAAVE. Después de la transacción, se quedó con solo 4.980399 aEthUSDT y recibió 327.241335505966487788 aEthAAVE. De hecho, la cartera vendió casi toda su posición.

Los metadatos indican más claramente que el enrutamiento ya era "tóxico" antes de la ejecución. La orden vino del proceso de intercambio de garantías de interfaz aave-v3. La API de CoW lo mostraba como una orden de venta firmada, mientras que los metadatos de la aplicación lo marcaban como un intercambio de garantías al estilo del mercado utilizando 121 puntos básicos de deslizamiento inteligente. El importe de venta firmado fue de 50.432.688.41618 aEthUSDT. El importe mínimo de compra firmado fue de 324.949260918413591035 aEthAAVE. La liquidación real pagó 327.241335505966487788 aEthAAVE.

Este es un detalle extremadamente importante. La orden no esperaba obtener miles de AAVE, solo para ser destruida de alguna manera a mitad de camino. Desde el principio, se construyó alrededor de un resultado de más de trescientos AAVE.

Enlace completo del colapso de enrutamiento

Una vez que sigues el seguimiento de la transacción, todo el proceso es brutalmente sencillo.

El flujo de capital de nivel superior se basa en el contrato de liquidación GPv2Settlement del protocolo CoW a partir de 0x9008. En primer lugar, el contrato HooksTrampolín que comienza con 0x60bf completa la operación de autorización de aEthUSDT, lo que permite a la capa de tesorería de CoW extraer activos de usuario sin autorización de transacción separada; a continuación, el contrato GPv2VaultRelayer que comienza con 0xc92e extrae 50.432.688.41618 aEthUSDT de la cartera del usuario en el proceso de liquidación. Hasta este punto, todas las operaciones se ajustan a la lógica normal.

El contrato de liquidación otorga entonces autoridad de operación aEthUSDT a un contrato auxiliar no verificado que comienza con 0xd524 e inicia una llamada a través del selector de función 0x494b3137; este contrato auxiliar luego transfiere autoridad de ejecución a un contrato de ejecutor no verificado que comienza con 0x699c, momento en el que se expone completamente la imagen completa del enrutamiento de transacción anormal.

La primera llamada efectiva apunta al contrato del pool de liquidez de Aave a partir de 0x87870, que destruye aEthUSDT a través de la función retirar (selector 0x69328dec) para canjear el USDT nativo subyacente; luego el enrutamiento salta al pool de negociación Uniswap V3 deep USDT/WETH a partir de 0x4e68, intercambiando todos los 50.432.688.41618 USDT por 17.957.810805702142342238 WETH.

La transacción en esta etapa es completamente normal: el tipo de cambio es de aproximadamente 2808.4 USDT por 1 WETH, consistente con el mercado en ese momento, sin problemas de escasez de liquidez y sin desviaciones de cálculo; el primer enlace de transacción de lúpulo no tiene anomalías.

El problema surge en el segundo salto; una vez que se ven las reservas de liquidez, el resto de la historia es inevitable.

Después de que el ejecutor obtenga 17,957.810805702142342238 WETH, transfiere todos los fondos al pool de negociación SushiSwap V2 AAVE/WETH en la dirección 0xd75ea151a61d06868e31f8988d28dfe5e9df57b4.

Comprobé los datos históricos de la reserva de liquidez de este pool de negociación justo antes de que se produjera la transacción anormal (altura del bloque 24643150), y el pool solo tenía:

331.631982538108027323 AAVE, 17.653276196397688066 WETH

Esto no es un error de entrada de datos, sino un hecho férreo.

Este enrutamiento de transacciones inyectó casi 17.958 WETH en su totalidad en un micro pool comercial que solo reserva 17,65 WETH, lo que corresponde a un inventario total de AAVE de solo 331,63 AAVE, siendo el volumen WETH de entrada aproximadamente 1017 veces las reservas WETH del pool.

No se trata de un problema común de "deslizamiento alto" o "liquidez ligeramente delgada", sino de una ruta de ejecución de órdenes de mercado extremadamente absurda, equivalente a obligar a un pool de AMM de producto constante muy pequeño a emprender una escala de transacciones miles de veces superior a su propia capacidad.

El pool comercial de AMM ejecutó la operación de acuerdo con el algoritmo establecido, casi agotando todas las reservas de AAVE en el pool.

El par de operaciones SushiSwap activó el evento de intercambio principal de Swap: el ejecutor transfirió 17,957.810805702142342238 WETH, solo recibiendo de vuelta 331.305315608938235428 AAVE. Después de la transacción, la liquidez restante en la cuenta mancomunada fue aproximadamente:

0,326666929169791895 AAVE, 17,975.464081898540030304 WETH

En términos sencillos, alrededor del 99,9% de las reservas de AAVE en la piscina se drenaron de un salto.

Sobre la base de las reservas antes de la transacción, el precio implícito del AAVE en el pool era de unos 149,50 dólares. El precio de ejecución real del usuario fue de aproximadamente 154,114.66 USDT para 1 AAVE. Esto es más de 1000 veces diferente del precio al contado antes de la transacción.

Posteriormente, estos AAVE se devolvieron a la reserva de liquidez de Aave, utilizando el selector 0x617ba037, es decir, supply(dirección,uint256,dirección,uint16). El resultado fue que el recién acuñado aEthAAVE fue devuelto al contrato de liquidación. En última instancia, el contrato de liquidación transfirió 327.241335505966487788 aEthAAVE al usuario. Alrededor de 4,06398010297174764 aEthAAVE permanecieron en el contrato de liquidación como excedentes en relación con lo que pagó el usuario.

Por lo tanto, el acuerdo no distorsionó repentinamente un buen resultado de ejecución en uno malo. Se limitó a ultimar el resultado que ya había producido el trazado.

Este es un punto clave que vale la pena declarar claramente: el desastroso resultado ya estaba "preestablecido" en el enrutamiento antes de la ejecución.

En los datos de llamada de contrato auxiliar incorporados en el enrutamiento, el importe de compra objetivo en el lado de la compra fue de aproximadamente 331.272185078031026739, el importe mínimo de compra acordado por el usuario fue de 324.949260918413591035 y el importe de liquidación real fue de 327.241335505966487788, con todos los valores básicos bloqueados en el nivel de más de trescientos AAVE antes de la liquidación.

Esta ruta nació mal.

¿Dónde está el defecto?

La respuesta es: cada capa del mecanismo de verificación del sistema está comprobando la dimensión incorrecta.

Todos los niveles solo comprueban si la transacción es ejecutable, si la firma es válida, si la cantidad es distinta de cero, pero casi no hay un nivel básico que compruebe si el enrutamiento de la transacción es económicamente razonable, lo que es la raíz central del fallo del mecanismo.

Defecto de código en la ruta de cotización del adaptador de interfaz Aave

El primer punto obvio de anomalía de código aparece en el proceso de cotización del adaptador CoW de la interfaz Aave: la función utilizada originalmente para adjuntar datos de aplicaciones específicas del adaptador al solicitar una cotización se obligó directamente a desactivarla.

Fuente: rates.helpers.ts:93 y adapters.helpers.ts:194

Esto significa que cuando la interfaz de Aave solicita un presupuesto a CoW, no adjunta los metadatos del préstamo flash y del gancho que se incluirían realmente al realizar un pedido. En otras palabras, lo que se cita no es totalmente lo que se va a ejecutar. Los comentarios del código incluso indican que el propósito de esta función de ayuda es hacer que las cotizaciones del adaptador sean más precisas, sin embargo, esta función fue deshabilitada por la fuerza.

Determinación de razonabilidad débil en la lógica de competencia de cotizaciones de vacas (defecto central)

El segundo y más grave problema radica en la lógica de competencia de cotizaciones del protocolo de CoW: en su código de servicio público, mientras la tarifa del gas de cotización sea positiva y la cantidad de salida no sea cero, se considerará una "cotización razonable".

Fuente: quote.rs:31

Para un sistema de enrutamiento que maneja órdenes de ocho dígitos, esta es una definición sorprendentemente débil de "razonabilidad".

El sistema no integró oráculos para las comprobaciones de solidez de precios, no tenía ningún mecanismo de interceptación para "cotizaciones que se desviaban del precio al contado en más de 500 veces", ni evaluación de riesgos para "encaminar piscinas de liquidez que agotan completamente" y ninguna advertencia para "liquidez de último salto gravemente desajustada con la escala de órdenes"; solo requería que el solucionador devolviera un plan de enrutamiento ejecutable, distinto de cero, que sería aceptado por el sistema, este es el defecto central de este incidente.

Defectos en la lógica de modelado de liquidez estilo Uniswap V2

El tercer problema radica en el enfoque de modelado de pools de liquidez estilo Uniswap V2: el código solo emplea el algoritmo de producto constante estándar, rechazando solo situaciones matemáticamente imposibles como reservas cero, desbordamiento y subdesbordamiento, sin realizar comprobaciones de viabilidad económica.

Fuente: pool_fetching.rs:118 y pool_fetching.rs:153

Este segmento de código no determina si el tamaño del fondo de liquidez es suficiente para acomodar la transacción de encaminamiento correspondiente; solo comprueba si la operación de permuta es matemáticamente válida. Por lo tanto, incluso un micro pool con solo 331 reservas de AAVE se consideraría un lugar válido para acomodar una solicitud de compra de 17.957 WETH, simplemente porque el algoritmo de producto constante puede producir un resultado distinto de cero, ignorando completamente la pérdida de activos catastrófica que este resultado causaría.

Fallo secundario del SDK de préstamo flash y mecanismo de verificación de pedidos

Posteriormente, el SDK de préstamos flash solidificó directamente esta cotización no válida en la carga útil de ejecución de órdenes y ganchos sin ninguna interceptación de riesgo secundario.

Entonces:

Fuente: index.js:484 e index.js:591.

Es por eso que siempre he dicho que esta ruta nace "mal". La capa adaptadora no "descubrió" una nueva cantidad mala durante la ejecución. Serializó la cantidad incobrable ya citada en los datos del gancho y determinó la dirección de la instancia. Una vez que exista una mala cita, los mecanismos restantes la transmitirán fielmente.

Incluso la lógica de verificación de pedidos de CoW no protegía realmente al usuario, ya que solo comprueba si el pedido supera el precio de mercado en el momento de la cotización, sin comprobar si la cotización en sí es absurda en relación con la liquidez real.

Fuente: order_validation.rs:694

Esta es una verificación de consistencia. Si la cita en sí ya es absurda, la orden todavía puede pasar.

El mecanismo de advertencia de interfaz de usuario es ineficaz

La interfaz Aave tiene advertencias de impacto de alto precio, pero no es un disyuntor duro. Cuando la pérdida de valor supera el 20%, se convierte en una casilla de verificación de confirmación.

Una vez que el usuario marca la casilla de verificación, se elimina la barrera:

Fuente: helpers.ts:24 y HighPriceImpactWarning.tsx:35

Por lo tanto, incluso si esta transacción casi vaciara todo el valor de los activos, el sistema solo la consideraba una operación que requería la confirmación del usuario, en lugar de una transacción de alto riesgo que debía ser rechazada firmemente por el sistema, y el mecanismo de alerta perdió completamente su función de interceptación de riesgos.

Basado en todos los fallos del mecanismo anterior, no estoy absolutamente de acuerdo con la conclusión despectiva de que "esto es solo estupidez del usuario". El usuario completó la firma, pero todo el sistema de software tuvo innumerables oportunidades para interceptar este desastre, sin embargo, cada capa solo realizó comprobaciones básicas, determinando "no cero, ejecutable, firmado", y directamente lo liberó, lo que finalmente resultó en consecuencias desastrosas.

El enrutamiento no fue manipulado

Esta sección es crucial, descartando directamente una gran cantidad de especulaciones erróneas: el proceso de interfaz oficial de Aave correspondiente a aave-v3-interface-collateral-swap calculará el monto de compra ajustado por deslizamiento en la línea 139 del archivo useSwapOrderAmounts.ts, combinando la cotización, las tarifas de red, las tarifas de socio y las tarifas de préstamo flash; la línea 331 lo convierte al valor buyAmountBigInt; luego, en la línea 191 del archivo CollateralSwapActionsViaCoWAdapters.tsx, este monto está firmado con precisión.

Los contratos de adaptador posteriores verificarán que los campos de pedido firmados coincidan completamente con los valores almacenados en la línea 141 del archivo AaveV3BaseAdapter.sol; el contrato de liquidación de CoW aplicará las reglas de límite acordadas firmadas en la línea 337 del archivo GPv2Settlement.sol. Por lo tanto, el resultado de la ejecución en cadena no superó los límites permitidos por la orden firmada, y los activos que el usuario recibió realmente estuvieron incluso por encima del límite mínimo acordado en la firma.

Esto es suficiente para demostrar que el desastre ocurrió antes de la etapa de arreglo, no durante el proceso de arreglo; el defecto fatal en el trazado ya había predeterminado el resultado.

¿Adónde fue el valor desaparecido?

La siguiente transacción en el mismo bloque (hash a partir de 0x45388b0f) completó un arbitraje de ejecución retrospectiva contra el grupo dañado de SushiSwap AAVE/WETH. Después de que la transacción anormal llenó el fondo con una cantidad masiva de WETH y drenó la mayor parte del AAVE, el árbitro vendió inmediatamente el AAVE de nuevo en el fondo, cosechando el exceso de valor traído por el desequilibrio de liquidez.

Este arbitraje revertido extrajo alrededor de 17,929.770158685933 WETH, luego pagó alrededor de 13,087.73 ETH al constructor del bloque y alrededor de 4,824.31 ETH a la dirección de ejecución del arbitraje.

Todo el valor económico perdido por el usuario se convirtió casi instantáneamente en beneficios de arbitraje MEV y beneficios de constructor de bloques dentro del mismo bloque.

Además, la comprobación de la secuencia temporal a nivel de bloque confirma: nadie manipuló maliciosamente el pool de operaciones de SushiSwap para tender una trampa a los usuarios; el par de operaciones AAVE/WETH fue tocado por primera vez por esta transacción anormal (índice de transacción 1); la transacción inmediatamente siguiente (índice de transacción 2) completó la primera vuelta atrás contra la distorsión de precios causada por esta transacción; el índice de transacción 3 también tocó este par de operaciones durante el proceso de corrección de mercado. El calendario lo verifica claramente: esta transacción anormal creó una distorsión extrema de los precios y las transacciones posteriores cosecharon directamente este beneficio distorsionado.

Entonces, ¿de quién es la culpa?

Si pregunta si el protocolo principal de Aave V3 colapsó, la respuesta es no. El pool de liquidez de Aave ejecutó las operaciones completamente de acuerdo a las instrucciones, completando con éxito el proceso de canje USDT y depósito AAVE.

Si preguntas si el contrato de GPv2Settlement de la Vaca se derrumbó, la respuesta es no. El acuerdo ejecutaba una orden firmada válida y pagaba una cantidad superior al límite mínimo acordado en la firma.

Si pregunta si los contratos de pares comerciales de Uniswap V3 o SushiSwap se derrumbaron, la respuesta también es no. Ambos tipos de grupos de negociación completaron los precios de transacción de acuerdo con sus propias reglas de algoritmo.

El verdadero fallo sistémico se produjo en las capas de enrutamiento y control de riesgos de nivel superior:

La principal parte responsable son los módulos de enrutamiento, cotización y resolución del protocolo CoW: los criterios de todo el sistema para determinar el "enrutamiento razonable" son demasiado débiles, lo que permite que las órdenes multimillonarias fluyan finalmente a los pools de micro baja liquidez, siempre y cuando el enrutamiento sea ejecutable y distinto de cero, se acepta, ignorando completamente la extrema irrazonabilidad en el nivel económico.

El responsable secundario es la interfaz frontend de Aave: no adjuntó los datos de la aplicación asociados al gancho al solicitar presupuestos de adaptador, pasando directamente los resultados erróneos al proceso de firma, y se basó únicamente en avisos sin un mecanismo de rechazo duro. Para transacciones de gran envergadura tan extremas, estas medidas de control de riesgos son completamente insuficientes para prevenir riesgos.

Se trata de una falla extrema de las barreras de control de calidad y riesgo del enrutamiento de transacciones, transformando directamente una operación de canje de garantías legítima y conforme en un evento catastrófico de pérdida de activos.