Artículo original de: @Ehsan1579
Compilado | Odaily Planet Daily (@OdailyChina); Traductor | Ethan (@ethanzhang_web3)
Si solo se lee el titular del evento, es muy probable que se malinterprete como un ataque de explotación de vulnerabilidades.
El núcleo del evento es: alguien cambió 50.4 millones de dólares en USDT y finalmente obtuvo solo 35,900 dólares en AAVE.
Cuando escuché esto por primera vez, me sorprendió. Por lo tanto, investigué a fondo todo el evento: seguimiento de transacciones, ruta del solver, llamadas a contratos, reservas históricas, datos de liquidación, flujo del adaptador, código de la interfaz de Aave, SDK del flash loan de CoW y el código de enrutamiento que determina si una cotización es "razonable".
No fue un hackeo. El protocolo central de Aave no falló. La liquidación de CoW no falló. Uniswap no falló. SushiSwap no falló. La transacción fue válida, las firmas fueron válidas, todos los contratos se ejecutaron estrictamente según el código. Sin embargo, casi todo el valor económico fue destruido, simplemente porque se permitió que tomara una ruta absurdamente mala.
La cadena de bloques no falló, falló el enrutamiento.
En mi opinión, restarle importancia y clasificar esto como un simple "error del usuario" no es una actitud objetiva y rigurosa. Ciertamente, el usuario firmó la orden, pero todo el sistema de software permitió que una operación que involucraba casi 50 millones de dólares en rotación de garantía pasara por la cotización, firma, planificación de ruta hasta la ejecución final, y todo el flujo apuntaba a un grupo de baja liquidez que contenía solo alrededor de 331 AAVE. Esto debería haber sido completamente imposible, o al menos el sistema debería haberlo rechazado rotundamente antes de que comenzara la liquidación.
Seguimiento de la información central de la transacción
El hash de esta transacción anómala es: 0x9fa9feab3c1989a33424728c23e6de07a40a26a98ff7ff5139f3492ce430801f, confirmada el 12 de marzo de 2026 en el bloque principal de Ethereum número 24643151, índice de transacción 1, consumo de Gas 3780570 unidades, ejecutada con éxito. La dirección de la billetera a la que pertenece la orden comienza con 0x98b9, y la dirección del ejecutor real de la transacción (remitente) comienza con 0x3980, marcada como tsolver en los datos de competencia de CoW.
Lo primero que hay que entender es que esto no fue un simple intercambio de USDT a AAVE a nivel de billetera. El token vendido fue aEthUSDT, es decir, el certificado de depósito de USDT que genera intereses en la plataforma Aave. El token comprado fue aEthAAVE, es decir, el certificado de depósito de AAVE que genera intereses en la plataforma Aave. Por lo tanto, esto fue en realidad un canje de garantía de Aave a través del sistema de liquidación del protocolo CoW y su flujo adaptador de flash loan.
Antes de la transacción, la billetera contenía aproximadamente 50,432,693.075254 aEthUSDT y 0 aEthAAVE. Después de la transacción, solo le quedaban 4.980399 aEthUSDT y recibió 327.241335505966487788 aEthAAVE. De hecho, la billetera vendió casi toda su posición.
Los metadatos muestran más claramente que la ruta ya era "tóxica" antes de la ejecución. La orden provino del flujo aave-v3-interface-collateral-swap. La API de CoW la muestra como una orden de venta firmada, y los metadatos de la aplicación la marcan como un canje de garantía de tipo mercado usando un deslizamiento inteligente de 121 puntos básicos. El monto de venta firmado fue de 50,432,688.41618 aEthUSDT. El monto mínimo de compra firmado fue de 324.949260918413591035 aEthAAVE. La liquidación real pagó 327.241335505966487788 aEthAAVE.
Este es un detalle extremadamente importante. Esta orden nunca esperó obtener miles de AAVE que luego fueron destruidos en el camino. Se construyó desde el principio alrededor de un resultado de poco más de trescientos AAVE.
Cadena completa del colapso del enrutamiento
Una vez que se sigue el rastro de la transacción, todo el proceso es brutalmente directo.
El flujo central de fondos de nivel superior se basa en el contrato de liquidación GPv2Settlement 0x9008 del protocolo CoW. Primero, el contrato HooksTrampoline 0x60bf completa la operación de autorización de aEthUSDT, permitiendo que el relé de la bóveda de CoW extraiga los activos del usuario sin una transacción de autorización separada; luego, el contrato GPv2VaultRelayer 0xc92e extrae 50,432,688.41618 aEthUSDT de la billetera del usuario hacia el proceso de liquidación. Hasta esta etapa, todas las operaciones fueron lógicas.
El contrato de liquidación luego otorga permisos de operación de aEthUSDT a un contrato auxiliar no开源 que comienza con 0xd524, e inicia una llamada a través del selector de función 0x494b3137; este contrato auxiliar luego transfiere los permisos de ejecución a un contrato ejecutor no开源 que comienza con 0x699c. En este punto, la imagen completa de la ruta de transacción anómala queda completamente expuesta.
La primera llamada efectiva apunta al contrato del grupo de fondos de Aave 0x87870, a través de la función withdraw (selector 0x69328dec) para destruir aEthUSDT y canjear el USDT nativo subyacente; luego la ruta salta al grupo de transacciones profundo USDT/WETH de Uniswap V3 0x4e68, cambiando la totalidad de los 50,432,688.41618 USDT por 17,957.810805702142342238 WETH.
Esta etapa de la transacción fue completamente normal: la tasa de cambio fue de aproximadamente 2808.4 USDT por 1 WETH, acorde con las condiciones del mercado en ese momento, sin problemas de liquidez insuficiente, sin desviaciones de cálculo. El primer salto de la ruta no presentó ninguna anomalía.
El problema surgió en el segundo salto. Una vez que se ven las reservas de liquidez, el resto de la historia es inevitable.
El ejecutor, después de obtener 17,957.810805702142342238 WETH, transfirió todos los fondos al grupo de transacciones SushiSwap V2 AAVE/WETH en la dirección 0xd75ea151a61d06868e31f8988d28dfe5e9df57b4.
Verifiqué los datos históricos de reserva de liquidez de este grupo justo antes de que ocurriera la transacción anómala (bloque 24643150). El grupo contenía solo:
331.631982538108027323 AAVE, 17.653276196397688066 WETH
Esto no es un error de entrada de datos, es un hecho irrefutable.
Esta ruta de transacción inyectó casi 17,958 WETH en un grupo de transacciones minúsculo que solo tenía una reserva de 17.65 WETH, con un inventario total de AAVE correspondiente de solo 331.63. El volumen de WETH ingresado fue aproximadamente 1017 veces la reserva de WETH en el grupo.
Esto no es un problema rutinario de "deslizamiento alto" o "liquidez un poco baja". Es una ruta de ejecución de orden de mercado extremadamente absurda, equivalente a forzar a un grupo AMM de producto constante y tamaño extremadamente pequeño a aceptar una transacción masiva miles de veces más grande que él mismo.
El grupo de transacciones AMM ejecutó la operación según su algoritmo establecido, agotando casi por completo toda la reserva de AAVE del grupo.
El par de transacciones de SushiSwap activó el evento central de intercambio Swap: el ejecutor transfirió 17,957.810805702142342238 WETH y solo recibió 331.305315608938235428 AAVE a cambio. Después de la transacción, la liquidez restante en este grupo fue aproximadamente:
0.326666929169791895 AAVE, 17,975.464081898540030304 WETH
En pocas palabras, aproximadamente el 99.9% del inventario de AAVE en el grupo fue drenado en un solo salto.
Según las reservas previas a la transacción, el precio implícito de AAVE en el grupo era de aproximadamente 149.50 dólares. El precio de ejecución real del usuario fue de aproximadamente 154,114.66 USDT por 1 AAVE. Esto es más de 1000 veces peor que el precio spot anterior a la transacción.
Luego, estos AAVE se suministraron de vuelta al grupo de fondos de Aave, usando el selector 0x617ba037, es decir, supply(address,uint256,address,uint16). El resultado fue que los nuevos aEthAAVE acuñados se enviaron de vuelta al contrato de liquidación. El contrato de liquidación finalmente transfirió 327.241335505966487788 aEthAAVE al usuario. Aproximadamente 4.06398010297174764 aEthAAVE permanecieron en el contrato de liquidación como excedente en relación con el pago del usuario.
Entonces, la liquidación no torció repentinamente un buen resultado de ejecución en uno malo. Simplemente finalizó el resultado que la ruta ya había producido.
Este es un punto clave que vale la pena enunciar claramente: El resultado catastrófico ya estaba "preestablecido" en la ruta antes de su ejecución.
En los datos de llamada del contrato auxiliar incrustados en la ruta, el monto objetivo del lado de la compra era de aproximadamente 331.272185078031026739, el monto mínimo de compra acordado por la firma del usuario era de 324.949260918413591035, y el monto de liquidación real fue de 327.241335505966487788. Todos los valores centrales se bloquearon en el rango de poco más de trescientos AAVE antes de la liquidación.
Esta ruta nació mala.
¿Dónde está la vulnerabilidad?
La respuesta es: cada capa del sistema de verificación estaba comprobando la dimensión incorrecta.
Todos los niveles solo verificaban si la transacción era ejecutable, si las firmas eran válidas, si los montos eran distintos de cero, pero casi ningún nivel central verificaba si la ruta de la transacción era económicamente razonable. Esta es la raíz central del fallo del mecanismo.
Defecto del código en la ruta de cotización del adaptador de la interfaz de Aave
El primer punto anómalo obvio en el código aparece en el flujo de cotización del adaptador de CoW de la interfaz de Aave: la función originalmente destinada a adjuntar datos de aplicación específicos del adaptador al solicitar una cotización fue deshabilitada por la fuerza.
Fuente: rates.helpers.ts:93 y adapters.helpers.ts:194
Esto significa que la interfaz de Aave, al solicitar una cotización a CoW, no adjuntó los metadatos de flash loan y hooks que sí se adjuntarían al publicar la orden realmente. En otras palabras, lo que se cotizó no era exactamente lo que se iba a ejecutar. El comentario en el código incluso dice que el propósito de esta función auxiliar es hacer que las cotizaciones del adaptador sean más precisas, y sin embargo, esta función fue deshabilitada a la fuerza.
La lógica de competencia de cotizaciones de CoW para determinar la razonabilidad es demasiado débil (vulnerabilidad central)
El segundo y más grave problema reside en la lógica de competencia de cotizaciones del protocolo CoW: en su código de servicio público, siempre que el costo de Gas de la cotización sea positivo y el monto de salida sea distinto de cero, se consideraba una "cotización razonable".
Fuente: quote.rs:31
Para un sistema de enrutamiento que maneja órdenes de ocho cifras, esta es una definición de "razonabilidad" sorprendentemente débil.
El sistema no incorporaba un oráculo para verificar la cordura del precio, no tenía un mecanismo de intercepción para "cotizaciones que se desvían más de 500 veces del precio spot", no tenía una determinación de riesgo de "la ruta agotaría completamente el grupo de liquidez", no tenía una alerta de "la liquidez del último salto está severamente desajustada con el tamaño de la orden"; solo requería que el solver devolviera un plan de ruta ejecutable y distinto de cero para que el sistema lo aceptara. Esta es la vulnerabilidad central de este evento.
Defecto en la lógica de modelado de liquidez estilo Uniswap V2
El tercer problema radica en la forma de modelar los grupos de liquidez al estilo Uniswap V2: el código solo empleaba el algoritmo estándar de producto constante, solo rechazaba situaciones matemáticamente imposibles como reservas cero, subdesbordamiento numérico, desbordamiento de reservas, y no realizaba verificaciones de viabilidad económica.
Fuente: pool_fetching.rs:118 y pool_fetching.rs:153
Este código no juzgaba si el tamaño del grupo de liquidez era suficiente para manejar la transacción de la ruta correspondiente, solo juzgaba si la operación de intercambio era matemáticamente válida. Por lo tanto, incluso un grupo minúsculo con solo 331 AAVE en reserva era considerado un lugar válido para una solicitud de compra de 17,957 WETH, solo porque el algoritmo de producto constante podía calcular un resultado distinto de cero, ignorando por completo que este resultado causaría una pérdida devastadora de activos.
Fallo secundario del SDK de flash loan y el mecanismo de validación de órdenes
Posteriormente, el SDK de flash loan solidificó directamente esta cotización fallida en la carga útil de ejecución de la orden y los hooks, sin realizar ninguna intercepción de riesgo secundaria.
Luego:
Fuente: index.js:484 y index.js:591
Por eso he estado diciendo que esta ruta "nació mala". La capa del adaptador no "descubrió" un nuevo monto malo en el momento de la ejecución. Serializó el monto malo ya cotizado en los datos del hook y las direcciones de instancia determinadas. Una vez que existía la mala cotización, el resto de los mecanismos la transmitían fielmente.
Incluso la lógica de validación de órdenes de CoW no protegió realmente al usuario aquí, porque solo verifica si la orden excede el precio de mercado en el momento de la cotización, no verifica 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 era un disparate, la orden aún podía pasar.
Mecanismo de advertencia de la UI frontal es ineficaz
La interfaz de Aave sí tiene una advertencia de alto impacto de precio, pero no es un interruptor de corte 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, el obstáculo se elimina:
Fuente: helpers.ts:24 y HighPriceImpactWarning.tsx:35
Por lo tanto, incluso si esta transacción casi vaciaría todo el valor de los activos, el sistema solo lo consideró una operación que requería la confirmación del usuario, en lugar de una transacción de alto riesgo que el sistema debía rechazar rotundamente. El mecanismo de advertencia perdió completamente su función de interceptación de riesgos.
Basándome en todos estos fallos de mecanismo, no estoy de acuerdo en absoluto con la conclusión simplista de que "solo fue un error del usuario". El usuario sí firmó, pero todo el sistema de software tuvo innumerables oportunidades de interceptar este desastre, y cada capa solo realizó verificaciones básicas, determinó que era "distinto de cero, ejecutable, firmado" y lo dejó pasar, lo que finalmente condujo a este mal resultado.
La ruta no fue alterada
Este es un eslabón crucial que descarta muchas suposiciones erróneas: el flujo correspondiente a aave-v3-interface-collateral-swap de la interfaz oficial de Aave, en el archivo useSwapOrderAmounts.ts línea 139, combina la cotización, las tarifas de red, las tarifas de socios, las tarifas de flash loan para calcular el monto de compra ajustado por deslizamiento; la línea 331 lo convierte en el valor buyAmountBigInt; luego, en el archivo CollateralSwapActionsViaCoWAdapters.tsx línea 191, firma precisamente este monto.
Posteriormente, el contrato adaptador en el archivo AaveV3BaseAdapter.sol línea 141 verifica que los campos de la orden firmada coincidan completamente con los valores almacenados; el contrato de liquidación de CoW en el archivo GPv2Settlement.sol línea 337 hace cumplir estrictamente las reglas de límite acordadas en la firma. Por lo tanto, el resultado de la ejecución en cadena no excedió el rango permitido por la orden firmada, y el usuario realmente recibió activos por encima del mínimo acordado en la firma.
Esto es suficiente para probar: el desastre ocurrió antes de la etapa de liquidación, no durante ella. El defecto fatal de la ruta ya había decidido el resultado.
¿A dónde fue el valor perdido?
La siguiente transacción dentro del mismo bloque (hash que comienza con 0x45388b0f) realizó un arbitraje de retroceso contra el grupo SushiSwap AAVE/WETH dañado. Después de que la transacción anómala llenara el grupo con una enorme cantidad de WETH y agotara la gran mayoría de los AAVE, el arbitrajista inmediatamente vendió AAVE de vuelta al grupo, cosechando el valor excedente generado por el desequilibrio de liquidez.
Este arbitraje de retroceso extrajo aproximadamente 17,929.770158685933 WETH, y luego pagó aproximadamente 13,087.73 ETH al constructor del bloque y aproximadamente 4,824.31 ETH a la dirección de ejecución del arbitraje.
Todo el valor económico perdido por el usuario finalmente se transformó, casi instantáneamente, en ganancias de arbitraje MEV dentro del mismo bloque y ganancias para el constructor del bloque.
Además, verificar la secuencia temporal a nivel de bloque confirma: nadie manipuló maliciosamente el grupo de transacciones de SushiSwap antes de la transacción para engañar al usuario; este par de transacciones AAVE/WETH fue tocado por primera vez por esta transacción anómala (índice de transacción 1); la siguiente transacción inmediata (índice de transacción 2) realizó el primer retroceso contra la distorsión de precio causada por esta transacción; el índice de transacción 3 también tocó este par de transacciones durante la corrección del mercado. La línea de tiempo claramente confirma: esta transacción anómala creó un precio extremadamente distorsionado, y las transacciones posteriores cosecharon directamente los beneficios de esta distorsión.
Entonces, ¿de quién es la culpa?
Si preguntas si el protocolo central de Aave V3 colapsó, la respuesta es no. El grupo de fondos de Aave ejecutó las operaciones exactamente según las instrucciones, completando normalmente los procesos de canje de USDT y depósito de AAVE.
Si preguntas si el contrato GPv2Settlement de CoW colapsó, la respuesta es no. La liquidación hizo cumplir una orden firmada válida y pagó un monto por encima del mínimo firmado.
Si preguntas si los contratos de los pares de transacciones de Uniswap V3 o SushiSwap colapsaron, la respuesta también es no. Ambos grupos de transacciones fijaron el precio según sus propias reglas algorítmicas.
El verdadero fallo sistémico ocurrió en niveles superiores de enrutamiento y control de riesgos:
El principal responsable son los módulos de enrutamiento, cotización y solver del protocolo CoW: todo el sistema tenía un criterio demasiado débil para determinar una "ruta razonable", permitiendo que órdenes masivas de millones de dólares terminaran fluyendo hacia grupos de baja liquidez minúsculos, siempre que la ruta fuera ejecutable y distinta de cero, ignorando por completo la extrema irracionalidad económica.
El responsable secundario es la interfaz frontal de Aave: al solicitar una cotización del adaptador, no adjuntó los datos de aplicación asociados a los hooks, introduciendo directamente el resultado erróneo en el flujo de firma, y dependiendo solo de advertencias, sin un mecanismo de rechazo duro. Para transacciones extremadamente grandes como esta, estas medidas de control de riesgo son completamente insuficientes para prevenir riesgos.
Este fue un fallo extremo en la calidad del enrutamiento de transacciones y las barreras de control de riesgo, que transformó directamente una operación legal y regulatoria de canje de garantía en un evento de pérdida de activos devastadora.
