EL DÍA EN QUE BINANCE SUFRIÓ EL ATAQUE Y POR QUÉ MANTENGO LA CALMA
30 de octubre de 2026
Hoy ha sido un día difícil para las criptomonedas. Según se informa, Binance sufrió un incidente de seguridad relacionado con unos 6.300 millones de dólares. Es una cifra enorme, y no voy a fingir que no lo es. Pero leí los detalles y creo que la historia completa es más complicada de lo que daban a entender los primeros titulares. Esto es lo que me llamó la atención.
QUÉ PASÓ
Según la información compartida por Binance, el ataque tuvo como objetivo una de sus billeteras calientes. Una billetera caliente es una billetera en línea que un exchange utiliza para procesar transacciones y retiros. Es distinta del almacenamiento en frío, donde los activos se guardan sin conexión.
El codirector ejecutivo de Binance, Richard Teng, dijo que los fondos de los clientes no se vieron afectados. Explicó que la mayoría de los activos de los usuarios se mantienen en billeteras frías y solo se transfieren a billeteras calientes cuando se necesitan para los retiros. Binance también dijo que los depósitos siguieron funcionando con normalidad.
Para contener el incidente, Binance pausó los retiros. Según la empresa, las salidas de fondos se detuvieron tras la suspensión. Ese fue un primer paso importante mientras el equipo investigaba lo sucedido.
QUÉ HIZO BINANCE A CONTINUACIÓN
Me gusta juzgar a un equipo por cómo responde cuando las cosas salen mal, no solo por lo que dice cuando todo va bien. Binance dijo que pausó los retiros, revocó las autorizaciones asociadas con las direcciones afectadas y se puso en contacto con las fuerzas del orden y con empresas de inteligencia de cadenas de bloques.
La empresa también informó que, con ayuda de sus socios, se habían congelado en la cadena unos 3.000 millones de dólares. Además, Binance dijo que había asignado más de 6.340 millones de dólares de sus propios fondos corporativos para cubrir la pérdida, de los cuales aproximadamente 5.000 millones ya estaban en los tokens afectados.
El mensaje de Teng fue que Binance cubriría las pérdidas en lugar de trasladárselas a los clientes. Si ese compromiso se cumple tal como se indicó, los usuarios no deberían tener que asumir el impacto financiero. Esa distinción me importa porque las consecuencias de un incidente de seguridad dependen no solo de cuánto se perdió, sino también de quién termina pagando por ello.
LAS BUENAS NOTICIAS PARA BNB CHAIN
Esta es una parte de la historia que, creo, merece atención. BNB Chain dijo que BNB Smart Chain, opBNB, BNB Greenfield y sus puentes entre cadenas no se vieron afectados por el incidente. Según el proyecto, sus redes siguieron funcionando con normalidad y los fondos mantenidos en la cadena permanecieron seguros.
Esa distinción es importante. Un incidente de seguridad que involucra la billetera de un exchange no significa automáticamente que la cadena de bloques subyacente haya sido comprometida. Son capas diferentes del ecosistema cripto, y debemos entender esa diferencia antes de sacar conclusiones.
Si el problema sigue limitado a la billetera afectada y la cadena continúa funcionando según lo informado, los desarrolladores pueden seguir creando y los usuarios pueden seguir interactuando con sus aplicaciones. PancakeSwap también dijo que sus contratos inteligentes y servicios funcionaban con normalidad.
BNB Chain expresó su apoyo al equipo de Binance y destacó la importancia de proteger la confianza en toda la industria. Estoy de acuerdo con ese principio. La seguridad no es algo que una empresa pueda tratar como si fuera responsabilidad de otra. Los exchanges, los desarrolladores de cadenas de bloques, los proveedores de infraestructura y los usuarios individuales tienen un papel que desempeñar.
LO QUE SIGO OBSERVANDO
Quiero ser sincero, porque la confianza depende de que estemos dispuestos a reconocer lo que todavía no sabemos. Hay varias preguntas importantes que aún necesitan respuestas claras.
En primer lugar, está la pregunta de cómo ocurrió el ataque. Binance señaló inicialmente que la computadora portátil de un ingeniero de DevOps había sido comprometida, pero luego indicó que el incidente implicó más de una acción y que los investigadores habían identificado puntos de entrada adicionales. La empresa también dijo que el atacante utilizó la funcionalidad EIP-7702 de Ethereum para obtener autorización sobre la billetera caliente, eludiendo los controles de aprobación habituales. La secuencia exacta de los hechos aún debe establecerse mediante una explicación técnica detallada.
En segundo lugar, está la cuestión de las claves privadas. Binance dijo que no había encontrado pruebas de que se hubieran filtrado claves privadas.