[Hilo en inglés] Análisis en profundidad del ataque a Balancer V2: mecanismo de la vulnerabilidad, pasos del ataque y lecciones aprendidas

Guía de Chainfeeds:

El atacante configuró deliberadamente los parámetros, incluyendo el número de iteraciones y el monto de entrada, para maximizar el efecto de la pérdida de precisión.

Fuente del artículo:

Autor del artículo:

BlockSec

Opinión:

BlockSec: El 3 de noviembre de 2025, el Composable Stable Pool de Balancer V2, junto con varios proyectos en cadena basados en su Fork, sufrieron un ataque coordinado cross-chain, resultando en una pérdida total superior a los 125 millones de dólares. BlockSec emitió una alerta temprana y posteriormente publicó un análisis preliminar. Se trató de un ataque de alta complejidad. Nuestra investigación muestra que la causa raíz provino de la pérdida de precisión en el cálculo del invariante, lo que permitió manipulación de precios a través de dicha pérdida de precisión, afectando así el precio del BPT (Balancer Pool Token). El atacante se benefició de pools estables específicos mediante una sola operación batchSwap. El componente afectado fue el Composable Stable Pool de Balancer V2. Este tipo de pool está diseñado para activos que se espera mantengan una tasa de cambio cercana a 1:1, permitiendo grandes transacciones con mínimo slippage y mejorando significativamente la eficiencia de capital entre activos similares o relacionados. Cada pool tiene su propio BPT, cuyo precio puede aproximarse como: Precio de BPT = D / totalSupply, donde D es el invariante en la matemática estable, representando el valor total virtual del pool. Según la fórmula, si D se reduce matemáticamente (aunque los fondos reales no se pierdan), el precio del BPT se verá más bajo. Balancer V2 ofrece la función batchSwap(), que permite swaps múltiples dentro del Vault, y en SwapRequest existen los modos GIVEN_IN y GIVEN_OUT. En el modo GIVEN_OUT, quien llama especifica el monto de salida deseado y el pool calcula el monto de entrada necesario. En los pools estables, al calcular el amountIn requerido, se debe resolver una ecuación polinómica basada en la fórmula del invariante, y estos cálculos se realizan con Upscaling y Downscaling. Teóricamente, ambos son operaciones opuestas, pero en la implementación real existe una diferencia en la dirección del redondeo: el Upscaling solo utiliza redondeo hacia abajo (mulDown), mientras que el Downscaling puede redondear hacia arriba o hacia abajo (divUp/divDown). Esta inconsistencia dejó espacio para el ataque. La raíz de la vulnerabilidad está en que en BaseGeneralPool._swapGivenOut(), al hacer Upscaling de swapRequest.amount, se utiliza redondeo hacia abajo. El valor así redondeado se usa como amountOut en la entrada de _onSwapGivenOut(), lo que provoca que el amountIn calculado sea menor al realmente necesario, violando el principio de que el redondeo debe favorecer siempre al protocolo. Para pools como (wstETH/rETH/cbETH), el atacante puede intercambiar una menor cantidad de un activo para obtener más de otro, reduciendo el invariante D y, por ende, bajando el precio del BPT. El atacante ejecutó el ataque en dos fases. La primera fase realiza la lógica principal del ataque en una sola transacción, pero sin obtener ganancias inmediatas; la segunda fase consiste en retirar las ganancias mediante una transacción separada. La primera fase se divide en el cálculo de parámetros y el batch swap. Tomando como ejemplo la transacción de ataque en la red Arbitrum (TX: 0x7da32e…55773), el atacante primero obtiene los parámetros del pool, incluyendo scaling factors, A (factor de amplificación), tasa de BPT, swap fee, etc., luego calcula trickAmt y simula mediante un contrato auxiliar desplegado. El atacante ajusta con precisión los parámetros del siguiente swap, combinando cálculos offline y simulaciones on-chain, incluyendo el número de iteraciones y los valores de entrada y salida de cada una. En cada iteración se realizan tres swaps: en el primero, se lleva la cantidad del token objetivo a trickAmt + 1; en el segundo, se sigue haciendo swap del token objetivo, activando el redondeo hacia abajo de _upscale(); en el tercero, se hace un swap inverso, truncando el saldo del pool hacia abajo eliminando los dos decimales más altos antes de intercambiarlo de vuelta. Por ejemplo, 324,816 → 320,000. En algunos casos, debido a que la matemática StableSwap utiliza el método de Newton–Raphson, puede fallar, por lo que el atacante preparó dos fallbacks, reintentando con 9/10 del valor original. Tras el ataque, debido a que algunas mecánicas de Balancer no pueden pausarse, el impacto se amplificó y surgieron ataques imitativos y copias en varias cadenas, con una pérdida total superior a los 125 millones de dólares. Este incidente expuso problemas clave en los protocolos descentralizados en cuatro áreas: mecanismos de redondeo inconsistentes, evolución constante de las técnicas de los atacantes, incapacidad de pausar que amplifica las pérdidas, y falta de monitoreo en tiempo real del estado de inicialización y operación. El Upscaling solo permite redondeo hacia abajo, mientras que el Downscaling permite ambos, lo que en parámetros extremos acumula una pérdida de precisión explotable. El redondeo, que debería favorecer siempre al protocolo, en este caso perjudicó sus intereses. El atacante usó una técnica en dos fases: en la primera ejecuta el ataque sin mostrar ganancias en los balances, y en la segunda retira las ganancias, evitando así los modelos de monitoreo on-chain. Cada paso del ataque combinó simulaciones off-chain y on-chain, e incluso el contrato auxiliar reutilizó la implementación StableMath de Balancer, manteniendo los mismos mensajes de error. Tras el ataque, se replicó en múltiples cadenas y muchos proyectos Fork también se vieron afectados, lo que demuestra que mientras la matemática estable y la lógica de redondeo sean iguales, la vulnerabilidad puede propagarse entre ecosistemas. El incidente demuestra que los protocolos DeFi necesitan cálculos matemáticos de mayor precisión, validaciones de redondeo más estrictas y mecanismos de simulación de rutas sospechosas, así como la capacidad de pausar de emergencia ante situaciones anómalas. [El artículo original está en inglés]