Un token pequeño de BNB Chain perdió casi todo el USDT de su pool en una sola transacción el 4 de noviembre, y dos días antes un fondo de seguros del mismo ecosistema se quedó sin 260,21 BNB por un préstamo relámpago. Los importes son pequeños al lado del robo a Binance, y precisamente por eso se pueden leer enteros: muestran con claridad quién paga cuando un contrato de finanzas descentralizadas se rompe.
El primer caso es el de TENDRIL, un token con un impuesto del 30 % en cada venta. El segundo es el de CoreVault, una bóveda que calculaba el precio de sus reembolsos leyendo un pool de liquidez. Los dos ataques usaron la misma idea, que el contrato confíe en un número que el atacante puede mover dentro de la misma transacción, y ese es el hilo que une los dos incidentes de la semana.
Entre ambos se llevaron unos 735.000 dólares, una cifra que no mueve el mercado y que sí explica por qué el seguro de muchos protocolos es una promesa más frágil de lo que parece. Los dos ataques ocurrieron con dos días de diferencia y se contaron como casos separados, aunque comparten la misma causa y probablemente el mismo tipo de autor.
El hook de venta que dejó el pool a cero
TENDRIL cobra un impuesto al vender, y ese impuesto se ejecuta dentro de una función que el propio token controla. Según el análisis de BlockSec Phalcon, una venta disparó el impuesto del 30 %, el contrato de gestión vendió esos tokens, llamó a la función `controlburn()` y después a `sync()`, que sincroniza las reservas del pool con el saldo real.
Ese `sync()` dejó la reserva de TENDRIL en 6.678 wei, prácticamente cero. Los tokens del vendedor llegaron al pool después, y el intercambio que siguió se llevó casi los 4,42 millones de USDT que había en la reserva contraria, un movimiento que el análisis de Tendril en blockintAI reconstruye transacción a transacción.
El detalle técnico importa menos que la consecuencia. Cualquiera que pudiera vender podía disparar la secuencia completa, así que el atacante no necesitaba un permiso especial ni una clave: bastaba con ejecutar la venta en el momento adecuado. La transacción dejó un resultado neto de 555.670,54 USDT fuera del pool, con un préstamo relámpago de 30,6 millones que se devolvió dentro de la misma operación.
El dinero no se movió. A las 7:19 del 5 de noviembre, la cartera de beneficio tenía 309.111,24 USDT y 0,008 BNB, sin ninguna salida en las 21 horas anteriores. El atacante financió la operación con siete retiros de Tornado Cash en BNB, 24,96 BNB repartidos entre el 27 de octubre y el 4 de noviembre, lo que confirma una preparación de una semana para un ataque que duró un bloque.
Esa paciencia contradice la imagen del ataque oportunista. El atacante no improvisó el día del incidente, montó la posición con una semana de antelación y eligió el momento en que la reserva era más rentable de vaciar.
CoreVault o el fondo de seguros como víctima
El segundo caso tiene una vuelta de tuerca. El atacante no se llevó el dinero de los usuarios del protocolo, se llevó el de la reserva creada para cubrirlos. El InsurancePool de CoreVault perdió 260,21 BNB, unos 180.300 dólares, en una operación que CertiK describió como un ataque de oráculo financiado con préstamo relámpago.
La secuencia fue la siguiente. El atacante pidió 143,6 millones de dólares en WBNB al mercado de préstamos Moolah, de Lista DAO, y con ese capital hizo intercambios muy grandes contra un pool para arrastrar su precio interno lejos del de mercado. CoreVault calculaba el importe de sus reembolsos leyendo el precio de ese pool, así que el reembolso salió a 33 veces su tamaño normal y el atacante se quedó con 160,26 BNB, unos 111.000 dólares de beneficio antes de comisiones.
Todo ocurrió dentro de un bloque, lo que significa que ningún mecanismo de pausa humana podía intervenir en el proceso. La lección es que un fondo de seguros es un contrato más, con las mismas dependencias de oráculo y las mismas prisas de lanzamiento que el producto que debía proteger.
El patrón que ya lleva cuatro casos
Los analistas que siguieron el ataque a TENDRIL señalaron que la misma técnica de quemar y sincronizar se usó contra YSDAO en mayo, contra AIDC en junio y contra SKYDAO en septiembre. Cuatro incidentes con el mismo mecanismo en siete meses no son mala suerte, son una categoría de error que los desarrolladores siguen repitiendo.
La causa es siempre la misma. Un token con lógica propia en la transferencia puede modificar el estado del pool mientras la operación está en marcha, y los contratos que leen el precio antes de que la operación termine reciben un valor manipulado. Ninguna auditoría encuentra esto si no se prueba con transacciones concretas.
Hay un detalle que agrava el problema y que aparece en los cuatro casos. El atacante no necesita encontrar un fallo en el protocolo que lee el precio, le basta con elegir un token cuyo comportamiento en la transferencia sea lo bastante raro. Eso convierte a los emisores de tokens con impuestos y rebases en la puerta de entrada preferida, y explica por qué los protocolos serios publican una lista de tokens admitidos en lugar de aceptar cualquiera.
La misma lógica aparece en incidentes de mayor tamaño. El puente de zkLink Nova cayó por una prueba forjada y la red de Initia se detuvo tras perder tokens, dos ejemplos de que el problema no es el tamaño del protocolo sino la confianza en un dato que alguien puede fabricar.
Ese patrón tiene un nombre en la literatura de seguridad de contratos: dependencia de una fuente de verdad controlable por el atacante. Ninguna herramienta la detecta automáticamente, porque no es un error de sintaxis sino una decisión de diseño que solo se ve al leer el flujo completo de una operación.
La cobertura solo existe si el contrato aguanta
Cualquier usuario que esté pensando en aportar liquidez a un par poco conocido puede hacer tres comprobaciones antes de firmar. La primera es leer el contrato del token y buscar funciones que quemen o sincronicen reservas dentro de una transferencia. La segunda es comprobar si el protocolo pausa operaciones y quién puede activar la pausa. La tercera es mirar la profundidad del pool, porque un par con menos de un millón de dólares en reserva se puede mover con un préstamo relámpago de tamaño medio.
Ninguna de las tres requiere saber programar y las tres están en la documentación pública del proyecto, que es otro motivo por el que estos incidentes resultan frustrantes. La información para evitar la pérdida estaba disponible antes de que ocurriera y nadie la convirtió en una advertencia visible dentro de la interfaz que usa el inversor.
Hay una cuarta comprobación que conviene añadir a la lista y que casi nadie hace. Consiste en leer el historial de incidentes del protocolo y ver si alguno de los cuatro casos anteriores afectó a un contrato parecido, porque un equipo que ya ha vivido esto suele endurecer las mismas piezas.
El episodio de THORChain, que reabrió solo 10 de sus 13 cadenas tras un fallo contable, completa el mapa de la semana. Los tres casos comparten la misma pregunta de fondo sobre qué garantiza realmente un protocolo cuando el mercado se mueve más rápido que sus controles, y la respuesta que dan los auditores es la misma que da el mercado: un contrato que nadie ha probado con dinero ajeno.
