Por Canuto  

Un pool de liquidez estilo Balancer V1 perdió aproximadamente USD $234.000 tras un exploit que convirtió una entrada de apenas 1 satoshi de WBTC en una emisión desproporcionada de BPT. El incidente comparte la misma familia de errores de redondeo que contribuyó al drenaje de USD $116 millones sufrido por pools V2 de Balancer en noviembre pasado.
***

  • Un atacante redujo casi a polvo las reservas de WBTC de un pool y aprovechó un cálculo redondeado hacia abajo.
  • La función joinswapPoolAmountOut permitió solicitar BPT mientras el contrato calculaba de forma inversa la entrada necesaria.
  • El incidente ocurre meses después del cierre corporativo de Balancer Labs, anunciado tras el hackeo de USD $116 millones.

Un pool de liquidez basado en el diseño de Balancer V1 perdió aproximadamente USD $234.000 el 31 de agosto de 2026, después de que un atacante explotara una falla de redondeo en el cálculo de intercambios. El incidente representa una pérdida menor frente a otros ataques contra el ecosistema, pero resulta especialmente relevante porque pertenece a la misma familia de errores que permitió drenar USD $116 millones de pools V2 de Balancer en noviembre pasado.

Una vulnerabilidad conocida vuelve a aparecer

La firma de seguridad blockchain SlowMist alertó sobre el nuevo exploit contra un pool estilo Balancer V1 y describió una secuencia en la que las reservas de WBTC quedaron reducidas a una cantidad prácticamente insignificante. El atacante aprovechó entonces la forma en que el contrato calculaba la cantidad de activos necesaria para entregar una suma determinada de BPT, los tokens que representan una participación en el pool.

En los intercambios habituales, un usuario entrega una cantidad de un activo y recibe otro token calculado según las reservas disponibles y las reglas del contrato. Sin embargo, la función joinswapPoolAmountOut permite invertir esa lógica: quien la invoca especifica cuántos BPT desea recibir, mientras el protocolo calcula hacia atrás qué cantidad de tokens debe aportar.

Esa operación inversa dependía de la función calcSingleInGivenPoolOut, que utiliza matemática de punto fijo con 18 decimales para determinar el monto de entrada. Cuando las reservas de WBTC se redujeron casi por completo, el resultado calculado cayó por debajo del umbral que el contrato podía representar con precisión y terminó redondeado a solo 1 satoshi.

Un satoshi equivale a la unidad más pequeña de BTC y, en el contexto descrito por el análisis, representaba una fracción de centavo frente al valor total de los BPT emitidos. El fallo permitió que el atacante solicitara una cantidad desproporcionada de tokens del pool y pagara una entrada que la aritmética del contrato había reducido artificialmente.

Cómo se ejecutó el ataque

La secuencia comenzó con una serie de swaps públicos destinados a comprimir las reservas de WBTC hasta dejarlas en niveles cercanos a cero. Esa condición no produjo por sí sola el drenaje, pero preparó el estado interno del pool para que el cálculo inverso enfrentara una cifra extremadamente pequeña y vulnerable al redondeo.

Una vez que las reservas quedaron reducidas a polvo, el atacante utilizó joinswapPoolAmountOut para indicar cuántos BPT quería recibir. El contrato recurrió a calcSingleInGivenPoolOut, calculó la entrada requerida con precisión fija y terminó aceptando 1 satoshi de WBTC debido al redondeo hacia abajo.

La consecuencia económica fue una emisión de BPT que no guardaba proporción con los activos entregados en la operación. Según la alerta de SlowMist, la diferencia entre el valor solicitado y el monto efectivamente aportado permitió extraer alrededor de USD $234.000 del pool afectado.

El análisis señaló que el contrato carecía de varias defensas que podrían haber limitado o impedido el abuso. Entre ellas figuraban una entrada mínima efectiva, un saldo mínimo obligatorio para el pool y una validación del error relativo entre el valor esperado y el valor calculado.

La verificación MIN_BALANCE tampoco cubría los swaps ordinarios, de acuerdo con la revisión técnica, porque solo se aplicaba durante las funciones bind y rebind. Esa cobertura parcial dejó abierta una ruta en la que las reservas podían caer a niveles peligrosos sin activar el control que habría protegido el saldo mínimo.

El antecedente de los pools V2

El nuevo ataque recuerda el incidente que afectó a los pools V2 de Balancer en noviembre de 2025 y que provocó pérdidas estimadas en USD $116 millones a través de varias cadenas. En aquel caso, la falla también estuvo relacionada con la forma en que el protocolo manejaba cálculos de tokens y redondeos, lo que convirtió una particularidad matemática en una vulnerabilidad con consecuencias financieras amplias.

La diferencia principal está en la escala y en el activo involucrado: el ataque reciente afectó WBTC dentro de un pool estilo Balancer V1, mientras que el episodio anterior alcanzó pools V2 y generó un daño mucho mayor. La comparación, sin embargo, muestra que una categoría de error puede persistir en implementaciones relacionadas incluso cuando el protocolo original ya no opera bajo la misma estructura corporativa.

En marzo de 2026, Balancer Labs anunció que cerraría como entidad corporativa, cinco meses después del exploit de noviembre. La empresa citó la creciente exposición legal derivada de incidentes de seguridad anteriores. Su cofundador Fernando Martinelli explicó que el protocolo continuaría bajo una estructura descentralizada.

El cierre corporativo no elimina automáticamente los contratos desplegados ni las consecuencias de una lógica vulnerable en redes públicas. Un contrato puede continuar recibiendo transacciones y custodiando activos después de que el equipo que lo desarrolló reduzca sus operaciones, por lo que la seguridad de los fondos depende también de las salvaguardas incorporadas en el código y de la gestión de los usuarios.

La billetera vinculada al hackeo original tampoco desapareció del radar del mercado. Cinco meses después de aquel ataque, volvió a mover 1.100 ETH a través de Thorchain, un comportamiento que mantuvo activa la preocupación sobre el destino de los fondos y la capacidad de rastrear activos que pasan por distintos protocolos.

Riesgos para WBTC y las finanzas descentralizadas

El incidente también pone el foco sobre WBTC, una representación tokenizada de bitcoin utilizada dentro de aplicaciones de finanzas descentralizadas. Aunque el activo busca reflejar el valor de BTC, su uso en pools, puentes y contratos inteligentes introduce riesgos operativos y técnicos distintos de los que enfrenta bitcoin en su propia red.

Para los proveedores de liquidez, el caso demuestra que la profundidad aparente de un pool no basta para evaluar su seguridad. Las fórmulas de emisión, los límites de reservas, la precisión numérica y las condiciones extremas de liquidez pueden determinar si una operación legítima se mantiene dentro de parámetros razonables o se convierte en una vía de extracción.

Los controles recomendados por el análisis apuntan precisamente a esos puntos: impedir entradas efectivas demasiado pequeñas, mantener un saldo mínimo y comparar el error relativo antes de permitir la emisión de tokens. Ninguna de esas medidas reemplaza una auditoría completa, pero juntas pueden reducir el margen de maniobra de un atacante que intente llevar las reservas hasta un estado límite.

El problema no depende necesariamente de una caída o subida del precio de bitcoin. El valor de mercado de BTC puede mantenerse firme mientras los instrumentos envueltos y tokenizados utilizados en DeFi enfrentan fallas propias, de modo que la exposición de un usuario depende tanto del activo subyacente como del contrato que lo administra.

SlowMist publicó como parte de su alerta la billetera asociada al atacante y la dirección del contrato utilizado en el ataque. Esos datos pueden facilitar el seguimiento de los fondos y la revisión independiente de la operación, aunque la identificación de una dirección no implica por sí misma conocer la identidad de la persona que la controla.

El exploit deja una advertencia para protocolos que reutilizan diseños antiguos o mantienen contratos desplegados durante largos periodos: los errores de precisión pueden parecer irrelevantes en condiciones normales y volverse críticos cuando las reservas se acercan a cero. Para los usuarios, la lección es igualmente concreta, porque aportar liquidez a un protocolo exige considerar el riesgo del código, la actividad del equipo y la existencia de mecanismos de emergencia, no solo el rendimiento ofrecido.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados