50 millones de USDT intercambiados por 35 mil AAVE en el incidente del protocolo CoW de Aave

Este artículo proviene de: @Ehsan1579

Compilado por Odaily Planet Daily (@OdailyChina); Traductor: Ethan (@ethanzhang_web3

Al ver solo el título del evento, es probable que se interprete erróneamente como un ataque de explotación de vulnerabilidad.

El núcleo del evento es: alguien intercambió USDT por un valor de 50,4 millones de dólares, y finalmente obtuvo solo AAVE por un valor de 35,9 mil dólares.

Cuando escuché por primera vez este asunto, quedé realmente sorprendido. Por lo tanto, revisé por completo todo el evento: rastreo de transacciones, ruta del solucionador, llamadas al contrato, reservas históricas, datos de liquidación, proceso del adaptador, código de la interfaz de Aave, SDK de CoW Flash Loan y el código de enrutamiento para determinar si la cotización es "razonable".

Esto no fue un ataque de hacker. El protocolo principal de Aave no tuvo errores. La liquidación de CoW no tuvo errores. Uniswap no tuvo errores. SushiSwap no tuvo errores. Las transacciones eran válidas, las firmas eran válidas, y todos los contratos se ejecutaron estrictamente según el código. Sin embargo, casi todo el valor económico fue destruido solo porque se permitió una ruta absurda.

La cadena pública no tuvo problemas; el problema fue con la ruta.

En mi opinión, reducir este incidente a una simple “error de operación del usuario” no es una actitud objetiva ni rigurosa. Ciertamente, el usuario firmó la orden, pero todo el sistema de software permitió que una operación de rotación de garantías de casi 50 millones de dólares completara el proceso de cotización, firma, planificación de enrutamiento y ejecución final, con todo el flujo dirigiéndose hacia un pool de baja liquidez que solo posee aproximadamente 331 AAVE. Esto debería haber sido completamente imposible; al menos, el sistema debería haber bloqueado y rechazado la operación antes de que se iniciara el proceso de liquidación.

El hash de la transacción anómala es: 0x9fa9feab3c1989a33424728c23e6de07a40a26a98ff7ff5139f3492ce430801f, confirmado en el bloque 24643151 de la red principal de Ethereum el 12 de marzo de 2026, con índice de transacción 1, consumiendo 3780570 unidades de Gas, y ejecutada con éxito. La dirección de la billetera asociada a la orden comienza con 0x98b9, mientras que la dirección del solucionador (remitente de la transacción) que realizó efectivamente la transacción comienza con 0x3980, marcada como tsolver en los datos de CoW竞赛.

Primero, debes entender que esto no es un intercambio simple de USDT a AAVE a nivel de billetera. El token vendido es aEthUSDT, el comprobante de depósito de USDT que genera intereses en la plataforma Aave. El token comprado es aEthAAVE, el comprobante de depósito de AAVE que genera intereses en la plataforma Aave. Por lo tanto, en realidad se trata de un intercambio de garantías en Aave realizado a través del sistema de liquidación de CoW Protocol y su adaptador de flash loan.

Antes de la operación, esta billetera tenía aproximadamente 50,432,693.075254 aEthUSDT y 0 aEthAAVE. Después de la operación, solo le quedan 4.980399 aEthUSDT y recibió 327.241335505966487788 aEthAAVE. En realidad, esta billetera vendió casi toda su posición.

Los metadatos indican con mayor claridad que la ruta ya era "tóxica" antes de su ejecución. El pedido proviene del proceso aave-v3-interface-collateral-swap. La API de CoW lo muestra como un pedido de venta firmado, mientras que los metadatos de la aplicación lo etiquetan como un intercambio de garantía tipo mercado con un deslizamiento inteligente de 121 puntos básicos. El monto de venta firmado es de 50,432,688.41618 aEthUSDT. El monto mínimo de compra firmado es de 324.949260918413591035 aEthAAVE. El pago real liquidado fue de 327.241335505966487788 aEthAAVE.

Este es un detalle extremadamente importante. Este pedido nunca se esperaba que obtuviera miles de AAVE, y luego se eliminara de alguna manera en el camino. Desde su creación, estaba diseñado para lograr un resultado de más de trescientos AAVE.

Una vez que sigas el seguimiento de la operación, todo el proceso es crípicamente directo.

La transferencia central de fondos se basa principalmente en el contrato de liquidación GPv2Settlement que comienza con 0x9008. En primer lugar, el contrato HooksTrampoline que comienza con 0x60bf completa la autorización de aEthUSDT, permitiendo que el relay del cofre CoW extraiga los activos del usuario sin necesidad de autorizaciones de transacción separadas; posteriormente, el contrato GPv2VaultRelayer que comienza con 0xc92e extrae 50432688.41618 aEthUSDT desde la billetera del usuario para ingresarlos al proceso de liquidación; hasta este punto, todas las operaciones cumplen con la lógica normal.

El contrato de liquidación otorga posteriormente los permisos de operación de aEthUSDT al contrato auxiliar no abierto que comienza con 0xd524 y realiza una llamada mediante el selector de función 0x494b3137; este contrato auxiliar transfiere luego los permisos de ejecución al contrato ejecutor no abierto que comienza con 0x699c, revelando así por completo la ruta de la transacción anómala.

La primera llamada válida apunta al contrato del pool de Aave que comienza con 0x87870, que mediante la función withdraw (selector 0x69328dec) quema aEthUSDT y rescata los USDT nativos subyacentes; luego, la ruta se redirige al pool de intercambio Uniswap V3 profundo de USDT/WETH que comienza con 0x4e68, donde se intercambian todos los 50432688.41618 USDT por 17957.810805702142342238 WETH.

El intercambio en esta fase se realizó completamente normalmente: el tipo de cambio fue de aproximadamente 2808.4 USDT por 1 WETH, coherente con las condiciones del mercado en ese momento, sin problemas de liquidez ni desviaciones de cálculo, y no se detectó ninguna anomalía en la primera ruta de la transacción.

El problema está en el segundo salto; una vez que veas la reserva de liquidez, el resto de la historia es inevitable.

Tras obtener 17957.810805702142342238 WETH, el ejecutor transfirió todos los fondos al pool de intercambio SushiSwap V2 AAVE/WETH en la dirección 0xd75ea151a61d06868e31f8988d28dfe5e9df57b4.

Verifiqué los datos históricos de reservas de liquidez del pool justo antes del evento de transacción anómala (altura de bloque 24643150), y el pool solo contenía:

331.631982538108027323 unidades de AAVE, 17.653276196397688066 unidades de WETH

This is not a data entry error, but a hard fact.

Esta ruta de operación inyecta casi 17,958 WETH en un minúsculo par de intercambio que solo tiene 17.65 WETH en reserva y un total de 331.63 AAVE, lo que significa que la cantidad de WETH ingresada es aproximadamente 1,017 veces la reserva de WETH en el par.

Esto no es un problema común de “slippage alto” o “liquidez ligeramente baja”, sino una ruta de ejecución de orden de mercado extremadamente absurda, que obliga a un pool AMM de producto constante de tamaño extremadamente pequeño a asumir una operación de volumen miles de veces mayor que su tamaño.

El pool de intercambio AMM realizó operaciones según el algoritmo establecido, agotando casi por completo las reservas de AAVE en el pool.

SushiSwap: El par de intercambio desencadenó un evento de intercambio core Swap: el ejecutor transfirió 17957.810805702142342238 WETH y recibió solo 331.305315608938235428 AAVE. Tras completarse la operación, la liquidez restante en el pool es aproximadamente:

0.326666929169791895 unidades de AAVE, 17975.464081898540030304 unidades de WETH

En otras palabras, aproximadamente el 99,9% de los fondos de AAVE en el pool fueron extraídos en un solo salto.

Según las reservas previas a la operación, el precio implícito de AAVE en el pool es de aproximadamente 149.50 dólares. El precio real de ejecución del usuario es de aproximadamente 154,114.66 USDT por 1 AAVE. Esto representa una diferencia de más de 1000 veces respecto al precio spot previo a la operación.

Luego, estos AAVE se proporcionan de nuevo al pool de Aave utilizando el selector 0x617ba037, es decir, supply(address,uint256,address,uint16). Como resultado, los aEthAAVE recién acuñados se envían de vuelta al contrato de liquidación. El contrato de liquidación finalmente transfirió 327.241335505966487788 aEthAAVE al usuario. Aproximadamente 4.06398010297174764 aEthAAVE, como excedente respecto al pago del usuario, permanecieron en el contrato de liquidación.

Por lo tanto, el asentamiento no distorsionó repentinamente un buen resultado de ejecución en uno malo; simplemente confirmó finalmente el resultado que ya había generado la ruta.

Estos son los puntos clave, merece la pena decirlo claramente: los resultados desastrosos ya estaban "preestablecidos" antes de la ejecución de la ruta.

En los datos de llamada al contrato auxiliar incrustado en la ruta, el monto objetivo de compra es aproximadamente 331.272185078031026739, el monto mínimo de compra acordado por la firma del usuario es 324.949260918413591035, y el monto liquidado real es 327.241335505966487788; todos los valores clave se bloquearon previamente a la liquidación en una escala de más de trescientas unidades de AAVE.

This route was born to be bad.

La respuesta es: cada mecanismo de validación del sistema está verificando errores en su dimensión correspondiente.

Todos los niveles solo verifican si la operación es ejecutable, si la firma es válida y si el monto es distinto de cero, pero casi no verifican si la ruta de la operación es económicamente razonable; esta es la raíz central del fallo del mecanismo.

Defect in the code path for Aave interface adapter quoting

El primer punto evidente de anomalía en el código aparece en el proceso de cotización del adaptador CoW de la interfaz de Aave: la función que originalmente se utilizaba para incluir datos de aplicación específicos del adaptador al solicitar una cotización fue desactivada directamente.

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

Esto significa que la interfaz de Aave, al solicitar un precio a CoW, no adjunta los metadatos de préstamos relámpago y ganchos que se agregarán al publicar realmente la orden. En otras palabras, lo que se cotiza no es exactamente lo que se ejecutará. Incluso los comentarios del código indican que el propósito de esta función auxiliar es hacer que las cotizaciones del adaptador sean más precisas, pero esta función fue desactivada de forma rígida.

La lógica de evaluación de la validez de las ofertas de CoW es demasiado débil (vulnerabilidad central)

El segundo problema, también el más grave, radica en la lógica de competencia de ofertas del protocolo CoW: en su código de servicio público, cualquier oferta con tarifa de gas positiva y monto de salida distinto de cero se considera una "oferta válida".

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 integra un oráculo para la validación de la integridad de precios, no cuenta con un mecanismo de bloqueo para "desviaciones de cotización superiores a 500 veces el precio spot", no realiza una evaluación de riesgo para "rutas que agoten por completo los pools de liquidez", ni emite alertas para "desajustes graves entre la liquidez del último salto y el tamaño del pedido"; solo se requiere que el solucionador devuelva una ruta ejecutable y distinta de cero para que sea aceptada por el sistema, lo cual constituye la vulnerabilidad central de este evento.

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

La tercera cuestión radica en el modelo de piscinas de liquidez estilo Uniswap V2: el código solo utiliza el algoritmo estándar de producto constante y rechaza únicamente imposibilidades matemáticas, como reservas cero, desbordamiento numérico hacia abajo o desbordamiento de reservas, sin realizar verificaciones de viabilidad económica.

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

Este código no verifica si el volumen del pool de liquidez es suficiente para absorber la operación de ruta correspondiente, solo evalúa si la operación de intercambio es matemáticamente válida. Por lo tanto, incluso un minúsculo pool con solo 331 AAVE en reserva será considerado como un lugar válido para aceptar una solicitud de compra de 17,957 WETH, simplemente porque el algoritmo de producto constante puede calcular un resultado distinto de cero, ignorando por completo que este resultado provocaría una pérdida catastrófica de activos.

Segunda falla en el SDK de préstamos relámpago y el mecanismo de validación de órdenes

Luego, el SDK de préstamos relámpago inmovilizó directamente esta oferta expirada en la carga de ejecución de la orden y el gancho, sin realizar ninguna segunda拦截 de riesgo.

Continuar:

Fuente: index.js:484 y index.js:591

Por eso he dicho siempre que esta ruta es "mal nacida". La capa de adaptador no "descubre" un monto defectuoso nuevo en tiempo de ejecución; serializa la secuencia de montos defectuosos ya cotizados en los datos del gancho y la dirección de la instancia determinada. Una vez que existe la cotización defectuosa, el resto de los mecanismos la transmiten fielmente.

Incluso la lógica de validación de órdenes de CoW no protege realmente a los usuarios aquí, ya que solo verifica si la orden excede el precio de mercado en el momento de la cotización, pero no evalúa 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 coherencia. Si la cotización en sí ya es sin sentido, la orden aún puede ser ejecutada.

El mecanismo de alerta frontend de la interfaz de usuario es puramente formal

La interfaz de Aave sí muestra una advertencia de impacto de precio elevado, pero no es un interruptor de corte automático. Cuando la pérdida de valor supera el 20%, se convierte en una casilla de confirmación.

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

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

Por lo tanto, aunque esta transacción casi agotaría el valor total de los activos, el sistema solo la clasifica como una operación que requiere confirmación del usuario, no como una transacción de alto riesgo que el sistema deba rechazar de forma obligatoria, lo que hace que el mecanismo de alerta pierda completamente su función de interceptación de riesgos.

Dado que todos los mecanismos anteriores fallaron, no acepto en absoluto la conclusión evasiva de que “solo fue un error del usuario”. El usuario efectivamente completó la firma, pero el sistema de software tuvo innumerables oportunidades para interceptar este desastre, y en cada capa solo realizó verificaciones básicas, permitiendo el paso tras determinar que era “distinto de cero, ejecutable y firmado”, lo que finalmente provocó el desastre.

Esta etapa es crucial y descarta directamente numerosas suposiciones erróneas: el flujo oficial de la interfaz de Aave para aave-v3-interface-collateral-swap calcula el monto de compra ajustado por deslizamiento en la línea 139 del archivo useSwapOrderAmounts.ts, combinando la cotización, los costos de red, los costos de socios y los costos de préstamos relámpago; en la línea 331 lo convierte en el valor buyAmountBigInt; posteriormente, en la línea 191 del archivo CollateralSwapActionsViaCoWAdapters.tsx, se firma con precisión esta cantidad.

El contrato adaptador posterior verificará en la línea 141 del archivo AaveV3BaseAdapter.sol que el campo de la orden firmada coincida exactamente con el valor almacenado; el contrato de liquidación de CoW aplicará en la línea 337 del archivo GPv2Settlement.sol las reglas de límite establecidas en la firma. Por lo tanto, el resultado de la ejecución en cadena no excede el rango permitido por la orden firmada, y los activos recibidos por el usuario son incluso superiores al límite mínimo acordado en la firma.

Esto es suficiente para demostrar: el desastre ocurrió antes del cálculo, no durante el proceso de liquidación; el defecto fatal en la ruta ya estaba destinado a ese resultado.

La siguiente transacción en el mismo bloque (con hash que comienza con 0x45388b0f) realizó un arbitraje de corrida sobre el pool dañado de SushiSwap AAVE/WETH. Tras saturar el pool con una gran cantidad de WETH y extraer la mayor parte del AAVE, el arbitrajista vendió inmediatamente el AAVE de vuelta al pool, capturando el valor excedente generado por el desequilibrio de liquidez.

En este arbitraje de rebote, se extrajeron aproximadamente 17929.770158685933 WETH, seguido de un pago de aproximadamente 13087.73 ETH al constructor del bloque y de aproximadamente 4824.31 ETH a la dirección de ejecución del arbitraje.

El valor económico total perdido por el usuario se convierte casi instantáneamente en beneficios de arbitraje MEV y beneficios para el constructor del bloque dentro del mismo bloque.

Además, la verificación de la secuencia temporal a nivel de bloque confirma: antes de la transacción, nadie manipuló maliciosamente el pool de SushiSwap para tender una trampa a los usuarios; el par AAVE/WETH se tocó por primera vez en esta transacción anómala (índice de transacción 1); la siguiente transacción (índice de transacción 2) aprovechó inmediatamente la distorsión de precio causada por esta transacción; la transacción con índice 3 también tocó este par durante el proceso de corrección del mercado. La línea de tiempo confirma claramente: esta transacción anómala generó un precio extremadamente distorsionado, y las transacciones posteriores capturaron directamente estos beneficios distorsionados.

Si te preguntas si el protocolo central de Aave V3 se derrumbó, la respuesta es no. Los fondos de Aave realizaron completamente las operaciones según las instrucciones, completando normalmente el reembolso de USDT y el depósito de AAVE.

Si te preguntas si el contrato GPv2Settlement de CoW se colapsó, la respuesta es no. La liquidación ejecutó un pedido firmado válido y pagó una cantidad superior al mínimo firmado.

Si preguntas si los contratos de pares de intercambio de Uniswap V3 o SushiSwap se han colapsado, la respuesta es igualmente no. Ambos tipos de pools de intercambio completan la fijación de precios según sus propias reglas algorítmicas.

El verdadero fallo sistémico ocurrió en los niveles superiores de enrutamiento y control de riesgos:

La responsabilidad principal recae en los módulos de enrutamiento, cotización y solucionador del protocolo CoW: el sistema completo tiene criterios demasiado débiles para determinar un “enrutamiento razonable”, permitiendo órdenes masivas de millones de dólares que terminan en piscinas minúsculas con baja liquidez, siempre que el enrutamiento sea ejecutable y distinto de cero, ignorando por completo la extrema irracionalidad económica.

La parte responsable secundaria es la interfaz frontal de Aave: al solicitar una cotización del adaptador, no se adjuntaron los datos de la aplicación asociados al gancho, se transmitió directamente el resultado de error al proceso de firma, y solo se confía en alertas de advertencia sin un mecanismo de rechazo obligatorio; para este tipo de transacciones extremadamente grandes, tales medidas de control de riesgo son completamente insuficientes para prevenir el riesgo.

This was an extreme failure in trade routing quality and risk control safeguards, directly turning a legitimate and compliant collateral rotation operation into a catastrophic asset loss event.