Exploit de pools de Balancer v2

En noviembre de 2025, Balancer v2 — uno de los creadores de mercado automatizados más longevos de DeFi — fue explotado por aproximadamente 120 millones de dólares en múltiples pools estables y composables. El ataque encadenó dos problemas distintos: una comprobación de acceso faltante y un error de redondeo en la aritmética de invariantes del pool.

Qué ocurrió

El exploit apuntó a los pools estables composables de Balancer v2. La vulnerabilidad tenía dos partes:

1. Una comprobación de control de acceso faltante permitía a un llamador invocar una función sensible de mutación de estado del pool que debería haber estado restringida al propietario del pool.
2. Un error de redondeo en la lógica de manipulación de invariantes permitió al atacante mover el valor lastInvariant del pool a un estado que las matemáticas del AMM trataban como rentable para él.

Al explotar repetidamente el sesgo de redondeo bajo condiciones controladas por el atacante, el operador pudo extraer aproximadamente la parte de la comisión del protocolo del pool en cada iteración — compuesto a través de muchas transacciones y muchos pools.

La pérdida se extendió por los pools de Balancer y los protocolos construidos sobre ellos, incluyendo wrappers de activos vinculados a peg y portadores de rendimiento que usaban Balancer para liquidez.

Consecuencias

• La gobernanza de Balancer pausó los pools afectados.
• El equipo publicó un post-mortem y envió parches para v2; la próxima v3 ya había movido el mantenimiento de invariantes a una abstracción diferente menos susceptible a la misma clase de bug.
• Algunos protocolos aguas abajo absorbieron pérdidas directamente; otros negociaron recuperaciones parciales con el atacante.

Por qué importa

Balancer demostró de nuevo — cinco años en la era del DeFi-AMM — que las matemáticas de invariantes en AMM de producción siguen siendo una frontera. La dirección de redondeo, la truncación entera y la interacción entre setters de estado de pool y lectores de invariantes continúan siendo una clase de vulnerabilidad fértil. El patrón sucesor (v3, y diseños similares en Uniswap y Curve) explícitamente integra el mantenimiento de invariantes en librerías endurecidas y congeladas por auditoría en lugar de en código por pool.