Por Joey Awwad | Usuario de Binance desde 2019 | Ángel de Binance
Hay momentos en los que dejas de desplazarte, lees algo dos veces y realmente necesitas unos segundos para asimilar lo que acabas de ver. El 29 de octubre de 2026 fue uno de esos momentos. Binance, la plataforma que uso desde 2019 y donde inicié mi aventura con las criptomonedas con tan solo 20 $ que me regaló mi primo, había sufrido un grave incidente de seguridad. Las cifras eran casi imposibles de comprender. Se habían visto afectados aproximadamente 6,34 mil millones de dólares en activos digitales. Seis mil millones. Trescientos cuarenta millones. De dólares. Tómate un momento para asimilarlo.
Como usuaria, inversora, operadora y Binance Angel, esto no fue simplemente otro titular sobre otro exchange que sufría un problema de seguridad. Me afectó de otra manera. Llevo años aprendiendo gracias a Binance, operando en Binance, participando en su comunidad, asistiendo a eventos, compartiendo contenido educativo y animando a la gente de mi entorno a comprender las oportunidades y los riesgos de este sector. También llevo años explicando por qué confío en esta plataforma. Así que, naturalmente, presté atención a cada actualización. Pero quiero dejar algo claro desde el principio: no iba a fingir que el incidente era insignificante. Fue grave, preocupante y exigía rendición de cuentas. Sin embargo, preocuparse por un incidente de seguridad y perder de inmediato la confianza en una plataforma son dos cosas distintas.
No entré en pánico. No decidí de repente que ocho años de experiencia no significaban nada. Y desde luego no vi motivos para abandonar una plataforma antes de entender qué había ocurrido y, más importante aún, cómo respondería. Lo que siguió fue un incidente de seguridad, una investigación compleja, una carrera contrarreloj, la reposición de miles de millones en activos, la reconstrucción de la infraestructura y una operación de recuperación que merece documentarse adecuadamente.
Esta es la historia de lo que ocurrió, cómo ocurrió, qué hizo Binance después y por qué esta experiencia, como usuaria y Binance Angel, reforzó en mí algo importante sobre la rendición de cuentas.
No empezó el 29 de octubre. Uno de los aspectos más interesantes de este incidente es que el ataque no comenzó el día en que se movieron los fondos. Según la investigación inicial de Binance, los atacantes llevaban meses preparando su entrada en la infraestructura de la empresa. El primer hecho relevante se remonta a junio de 2026. Un ingeniero del equipo Wallet DevOps de Binance, identificado en la investigación como Ingeniero A, descargó una instalación manipulada de Homebrew mientras buscaba una popular herramienta de programación con IA. La instalación comprometida estaba diseñada para introducir actividad maliciosa en el entorno de desarrollo. El equipo de seguridad de Binance detectó una anomalía, sustituyó el dispositivo afectado y cambió las credenciales relacionadas como medida de precaución. Sin embargo, los atacantes ya habían obtenido información valiosa sobre el cargo del ingeniero y los colegas vinculados al equipo de infraestructura de monederos. Después llegó septiembre. Un segundo empleado, el Ingeniero de software B, fue contactado a través de una plataforma legítima de búsqueda de empleo. Alguien que se hizo pasar por director de proyectos se puso en contacto con él para hablarle de una posible oportunidad en una empresa ficticia. El acercamiento estaba cuidadosamente preparado. Primero hubo una entrevista con alguien que decía trabajar en Recursos Humanos. Se realizó mediante una videollamada en directo. Para dar credibilidad, la persona que entrevistaba compartió una cuenta en redes sociales con fotos y videos personales, creando la apariencia de alguien auténtico con una presencia en línea consolidada. Después llegó la segunda entrevista. Esta vez, la conversación tuvo lugar a través de una popular aplicación de mensajería social. Cerca del final de la entrevista, le pidieron al Ingeniero B que descargara una prueba de programación. Esa prueba era la trampa.
El repositorio contenía código malicioso que se ejecutaba durante el proceso de configuración en su computadora de trabajo. El malware utilizó sofisticadas técnicas de ofuscación, sustituyó un componente legítimo de una herramienta de desarrollo por una versión maliciosa y estableció comunicación con un servidor externo controlado por los atacantes. El malware era una amenaza de día cero que no fue detectada por las herramientas de seguridad de los dispositivos que estaban instaladas en ese momento. En otras palabras, no se trató simplemente de alguien que adivinó una contraseña o aprovechó una debilidad evidente en un sistema de retiros. Los atacantes combinaron ingeniería social, software malicioso, dispositivos comprometidos y acceso interno para avanzar hacia un objetivo mucho más delicado. Y ese objetivo era la infraestructura de los monederos.
20 de octubre: los atacantes se adentran aún más. La siguiente fecha importante fue el 20 de octubre de 2026. Según la investigación de Binance, los atacantes aprovecharon la computadora comprometida del Ingeniero B y una herramienta interna de IA para hacerse con el control de las cuentas y los accesos de otros dos empleados: el Ingeniero A, de Wallet DevOps, y el Ingeniero de software C. Durante este proceso, los atacantes descubrieron que el Ingeniero A tenía guardado en su computadora un token de permisos para desplegar contenedores. Fue un hallazgo crucial. Un token de despliegue puede dar acceso a sistemas responsables de ejecutar software y servicios. En las manos equivocadas, ese acceso puede convertirse en un puente hacia una infraestructura que nunca debería estar bajo el control de una persona no autorizada. Los atacantes ya tenían una vía hacia las operaciones de firma de monederos.
29 de octubre: el día en que todo salió a la luz. La etapa final comenzó el 29 de octubre. Entre las 17:15 y las 19:56 UTC, los atacantes accedieron a la computadora del Ingeniero de software C, utilizaron credenciales robadas al Ingeniero A, desplegaron un contenedor y activaron un script malicioso. El entorno comprometido les dio acceso no autorizado a un servicio interno de firma de transacciones de monederos. Aquí es donde la parte técnica cobra especial importancia. Un servicio de firma de monederos se encarga de autorizar transacciones de blockchain. Es un componente de seguridad crítico porque las transacciones deben firmarse antes de poder enviarse a una blockchain. Los atacantes abusaron de este acceso para iniciar transacciones al margen del proceso normal de retiros de Binance. Aproximadamente a las 20:05 UTC comenzaron los movimientos sospechosos de activos. Entre las 20:05 y las 20:09 UTC, cinco monederos calientes de Binance transfirieron aproximadamente 233.46 millones de XRP a una dirección controlada por los atacantes. Los atacantes también movieron aproximadamente: 970,500 SOL a través de monederos calientes de Binance en Solana. 44.2 millones de OP a través de monederos calientes de Binance en Optimism. 18,270 BTC desde un monedero caliente de Binance. El incidente afectó a varias redes y distintos activos, y su impacto total se estimó en aproximadamente 6.34 mil millones de dólares. Binance recibió una alerta interna sobre transferencias de gran volumen e inició una investigación de inmediato. Pero los atacantes tenían otro truco.
El exploit técnico: cómo se abusó de EIP-7702. Uno de los elementos técnicos más importantes de este incidente involucró el mecanismo de autorización EIP-7702 de Ethereum. Para quienes no lo conozcan, EIP-7702 es una mejora de Ethereum que permite que una cuenta de propiedad externa delegue temporalmente ciertas capacidades de ejecución a código de contrato inteligente. No es necesario exponer la clave privada de la cuenta. En este incidente, los atacantes abusaron del servicio de firma para crear delegaciones EIP-7702 maliciosas, otorgando a un contrato inteligente bajo su control derechos de ejecución parciales sobre un monedero caliente de Binance. Enviaron 50 transacciones de firma para manipular el nonce de la cuenta y establecer estas autorizaciones maliciosas. Esto creó un problema de contención particularmente difícil. ¿Por qué? Porque detener el sistema normal de retiros no era suficiente. Las autorizaciones maliciosas ya existían en la cadena y podían funcionar de manera independiente de la infraestructura habitual de retiros de Binance. Binance podía suspender los retiros, apagar los servicios de monederos calientes y restringir el procesamiento normal de transacciones, pero esas medidas no invalidarían automáticamente las autorizaciones que ya se habían establecido en la blockchain. Había otra complicación: el monedero caliente afectado utilizaba Computación Multipartita, o MPC. La MPC distribuye el proceso de firma entre varias partes, en lugar de depender de una sola clave privada. Este diseño de seguridad es importante, pero también significaba que Binance no podía utilizar simplemente una clave privada para revocar de inmediato las autorizaciones maliciosas. El equipo de ingeniería tuvo que desarrollar y ejecutar un procedimiento especializado para eliminar esos permisos mediante transacciones adicionales en la cadena. Esto explica por qué el incidente no se pudo contener simplemente pulsando un botón o suspendiendo temporalmente los retiros. Se necesitó una respuesta técnica coordinada.
La última transferencia no autorizada: 23:56 UTC. Según el informe de Binance, la última transferencia no autorizada, por un monto de 2,961.9 ETH, quedó finalizada en la cadena a las 23:56 UTC del 29 de octubre. La transacción se había difundido antes y permaneció pendiente antes de ser confirmada. Binance informó que no hubo más transferencias no autorizadas después de esa transacción.
A las 00:10 UTC del 30 de octubre, Binance ejecutó una nueva autorización desde el monedero caliente Binance14 a la dirección cero, eliminando el código de delegación maliciosa EIP-7702. Se detuvo el movimiento inmediato no autorizado de fondos. Sin embargo, detener el ataque era solo el principio. El siguiente desafío era posiblemente igual de importante: proteger a los usuarios, restaurar los activos afectados, reabrir los retiros y demostrar que la empresa podía asumir el impacto financiero.
La primera decisión importante: los usuarios no pagarían por esto. Aquí es donde creo que la respuesta merece especial atención. Binance se comprometió públicamente a asumir el impacto financiero de los fondos robados, en lugar de trasladar esas pérdidas a sus usuarios.
Lo repito.
La empresa no anunció que los clientes tendrían que aceptar una reducción de sus saldos. No anunció que los usuarios serían responsables de cubrir los activos robados. Se comprometió a cubrir el incidente con sus propios recursos.
El 30 de octubre, Binance explicó que ya había reservado más de 6.34 mil millones de dólares para cubrir las pérdidas. Aproximadamente 5 mil millones de dólares se mantenían en los mismos activos de tokens afectados, y la empresa adquirió los activos restantes mediante compras en el mercado y operaciones extrabursátiles.
La cobertura procedía de dos fuentes principales:
1. SAFU: Fondo de Activos Seguros para los Usuarios. SAFU es la reserva de protección de emergencia de Binance, creada para ayudar a proteger a los usuarios en circunstancias extremas. No es una cuenta de trading corriente ni un monedero personal de un ejecutivo. Es un fondo dedicado a la protección de los usuarios.
2. Recursos corporativos de Binance. Binance también comprometió recursos propios de la empresa y fondos de tesorería para cubrir el incidente.
Esta distinción importa porque la responsabilidad se asumió a nivel de empresa. No ha habido ningún anuncio oficial de que la recuperación se financiara mediante una cuenta personal de Richard Teng, una cuenta personal de CZ o el patrimonio privado de otro ejecutivo. Las fuentes de financiación señaladas fueron SAFU y los recursos corporativos de Binance.
Como usuario, esta fue una de las partes más importantes de toda la historia para mí. El ataque fue grave, pero la empresa estaba asumiendo la responsabilidad por sus consecuencias financieras, en vez de trasladárselas a las personas que confiaron sus activos a la plataforma.
La operación de recuperación: miles de millones, socios de blockchain y una carrera contrarreloj. Mientras se organizaba la cobertura financiera, Binance también trabajaba para recuperar y reponer los activos afectados. La primera prioridad era rastrear los fondos robados e impedir que siguieran moviéndose en la medida de lo posible. Binance coordinó sus acciones con organismos encargados de hacer cumplir la ley, empresas de inteligencia de blockchain, emisores de tokens y socios del sector. Para cuando publicó su informe de investigación del 3 de noviembre, Binance afirmó que se habían congelado o interceptado aproximadamente 2.85 mil millones de dólares en activos. Esta cifra estaba sujeta a conciliación y a la volatilidad de los precios del mercado. Congelar fondos y reponerlos son dos procesos distintos. Los activos congelados son fondos cuyo movimiento o llegada a su destino previsto se ha impedido mediante la coordinación con las redes y los socios pertinentes. Reponerlos, en cambio, significa que Binance adquiere activos de reemplazo para restaurar los saldos de los tokens afectados. Binance recurrió a compras en el mercado y a canales OTC para adquirir los activos necesarios, incluidos tokens con menor liquidez, que por lo tanto eran más difíciles de obtener en grandes cantidades. Y fue entonces cuando las cifras de recuperación empezaron a avanzar rápidamente.
30 de octubre: más de 6.34 mil millones de dólares reservados. Binance confirmó que había destinado más de 6.34 mil millones de dólares en recursos de la empresa para cubrir el incidente, y que ya mantenía aproximadamente 5 mil millones de dólares en los activos de tokens afectados. La empresa también colaboró con socios del sector para congelar activos y contener el incidente.
31 de octubre: aproximadamente el 90 % repuesto. La actualización de recuperación n.º 3 de Binance informó que se había repuesto aproximadamente el 90 % de los activos robados. La empresa también proporcionó una instantánea de su Prueba de Reservas como parte de sus esfuerzos de transparencia.
1 y 2 de noviembre: comienzan a reabrirse los retiros. Una vez protegida la infraestructura afectada y completadas las comprobaciones necesarias, Binance comenzó a reabrir los retiros por fases. No se trató de volver a activarlo todo de golpe. Cada activo y red necesitaba superar comprobaciones individuales de seguridad y preparación. El 2 de noviembre, Binance también confirmó que su instantánea de la Prueba de Reservas del 31 de octubre ya se podía verificar por completo mediante su prueba de conocimiento cero. Esto ofreció a los usuarios otra forma de verificar de manera independiente el respaldo de los saldos cubiertos.
3 de noviembre: la investigación se hace pública. Binance publicó sus conclusiones iniciales detalladas y explicó cómo los atacantes habían penetrado en el entorno, comprometido dispositivos de empleados, aprovechado el acceso interno y abusado de EIP-7702. También dio a conocer las mejoras de seguridad que ya había implementado. Entre ellas: reconstruir el sistema de monederos afectado en un nuevo entorno, reconstruir la herramienta interna de IA afectada y sus controles de acceso, sustituir los dispositivos afectados, retirar las credenciales y los tokens asociados a los ingenieros afectados, realizar análisis de seguridad exhaustivos en los dispositivos de los empleados, reforzar los controles de riesgo del servicio de monederos y ampliar la detección de anomalías de comportamiento basada en IA.
Binance también anunció que estaba contratando a expertos independientes en ciberseguridad para revisar el incidente y validar sus conclusiones. La empresa afirmó que la información más reciente del FBI atribuía el ataque a la República Popular Democrática de Corea (Corea del Norte).
4 de noviembre: 98 % repuesto. El último hito de recuperación disponible al momento de escribir este artículo se publicó el 4 de noviembre. Binance informó que se había repuesto aproximadamente el 98 % de los activos afectados. El 2 % restante correspondía a tokens con menor liquidez, que Binance dijo que seguía comprando a través de los mercados y los canales OTC. La empresa también publicó una nueva instantánea de la Prueba de Reservas, fechada el 4 de noviembre, y amplió la cobertura de 10 a 44 tokens. Se esperaba que la prueba de conocimiento cero completa tardara aproximadamente entre 50 y 60 horas en generarse. Este es un detalle importante: Binance ya había reservado más del 100 % de la cobertura financiera necesaria, pero la reposición efectiva de los activos de tokens afectados seguía siendo de aproximadamente el 98 %. Prefiero explicarlo con precisión antes que afirmar que ya se había restaurado hasta el último token.
5 de noviembre: se reabren más retiros. La recuperación continuó. En la actualización de recuperación n.º 8, publicada el 5 de noviembre, Binance anunció que los retiros de activos adicionales empezarían a reabrirse a partir de las 04:00 UTC. La reapertura se estaba realizando de forma progresiva, y cada activo y red se sometía a comprobaciones de seguridad y preparación.
Y esa es la situación al momento de escribir esta historia. El ataque estaba contenido, la empresa había cubierto económicamente un monto superior a las pérdidas estimadas, se había repuesto aproximadamente el 98 % de los activos de tokens afectados y los servicios de retiro seguían restableciéndose por fases.
¿Binance realmente cubrió las pérdidas? ¿De dónde salió el dinero? Creo que esto merece su propia sección porque probablemente será una de las primeras preguntas que la gente hará. ¿De dónde saca una empresa 6.34 mil millones de dólares? La respuesta no es que un director ejecutivo haya abierto una cuenta bancaria personal y transferido miles de millones de dólares. Binance declaró que el impacto financiero se cubriría mediante SAFU y otros recursos de la empresa. SAFU existe específicamente como mecanismo de protección de emergencia para los usuarios, mientras que los recursos de tesorería corporativa aportan capacidad financiera adicional. Binance dijo que ya había reservado más del 100 % del monto necesario. En la práctica, esto significa que la empresa se comprometió a aportar los recursos financieros necesarios para garantizar que se pudieran cubrir los saldos de los usuarios afectados sin pedirles que asumieran las pérdidas. El codirector ejecutivo Richard Teng también habló públicamente sobre la situación financiera de la empresa durante la Hong Kong FinTech Week, el 3 de noviembre. Describió a Binance como una empresa con una situación financiera muy sólida y dijo que podía cubrir el incidente. También confirmó que se estaban utilizando SAFU y otros fondos de la empresa para cubrir las pérdidas. Esa es la distinción que quiero que los lectores entiendan: se trató de una responsabilidad financiera corporativa, no de una donación personal de un ejecutivo.
La parte que me importa: nunca sentí la necesidad de salir corriendo. Ahora quiero volver a mi propia experiencia. Me uní a Binance en 2019. Mi viaje comenzó con 20 $. Nada extraordinario. Ninguna cartera enorme, ninguna cuenta de operaciones institucionales, ninguna estrategia de inversión complicada. Solo un regalo de cumpleaños de mi primo que me introdujo a un mundo financiero completamente nuevo. Con los años, aprendí, hice operaciones, cometí errores, exploré distintos productos y vi cómo evolucionaba el sector. Con el tiempo, mi relación con Binance pasó de ser simplemente usar un exchange. Me convertí en Binance Angel. Empecé a participar en actividades comunitarias, conversaciones educativas, AMAs, creación de contenido e iniciativas en toda la región de MENA. Asistí a Binance Blockchain Week en Dubái en 2025, me uní a la comunidad de Angels y tuve la oportunidad de contribuir al ecosistema de distintas maneras. Eso hace que este incidente sea personal en otro sentido. Cuando una empresa a la que has apoyado durante años atraviesa una crisis de esta magnitud, naturalmente prestas atención. Quieres respuestas. Quieres transparencia. Quieres saber si la empresa puede respaldar lo que ha prometido. Y así lo hice. Seguí los anuncios, leí las explicaciones técnicas, estuve pendiente de las actualizaciones sobre la recuperación y observé lo que la empresa estaba haciendo realmente. No me interesaba una lealtad ciega. Quería pruebas. Y lo que vi fue una empresa que reconoció el incidente, investigó los puntos de entrada, explicó el mecanismo técnico, destinó sus propios recursos, colaboró con socios del sector, repuso los activos afectados y restableció gradualmente los servicios. ¿Se podría haber evitado el ataque? Esa es precisamente la pregunta que Binance debe seguir investigando. ¿Se podría mejorar la respuesta? Sin duda. La propia Binance ha reconocido que debe reforzar aún más sus procesos de respuesta a incidentes y los controles de sus monederos. Pero un incidente de seguridad no debería juzgarse únicamente por la magnitud de los daños que causa. También debería juzgarse por la respuesta de la organización, su transparencia, cómo protege a sus clientes y si asume la responsabilidad de las consecuencias. Para mí, la respuesta fue importante. No olvidé de repente por qué empecé a usar Binance en 2019. No dejé de confiar en la plataforma porque uno de los ataques más sofisticados de su historia tuviera éxito. Creo que la confianza se construye con el tiempo, pero también se pone a prueba en los momentos difíciles. Y esta fue una prueba importante.
De la recuperación al agradecimiento: la campaña comunitaria de Binance. Mientras Binance trabajaba en la recuperación, ocurrió algo más. El 2 de noviembre, Binance lanzó su Campaña de Agradecimiento a la Comunidad, vigente hasta el 21 de noviembre de 2026. Me pareció especialmente interesante porque no era simplemente una promoción genérica de trading. Se presentó como una forma de agradecer a la comunidad su continua confianza y apoyo. La campaña incluye dos actividades principales:
1. Un cupón de reembolso de comisiones de trading Spot de 100 USDC: Los usuarios elegibles cuya identidad haya sido verificada pueden recibir un cupón de reembolso de comisiones de trading Spot de 100 USDC a través del Centro de recompensas. Aquí hay una distinción importante: se trata de un cupón de reembolso de comisiones de trading, no de un regalo en efectivo de 100 USDC sin restricciones. El reembolso se distribuye conforme a las reglas de la campaña. El cupón ofrece un reembolso diario del 30 % de las comisiones restantes elegibles de trading Spot, una vez deducidas las comisiones por referidos, y los reembolsos se acreditan en USDC en la Cuenta Spot. Los usuarios deben reclamar el cupón en Perfil > Centro de recompensas, y es importante tener en cuenta los plazos aplicables para reclamarlo y su vencimiento.
La campaña también incluye un fondo de recompensas de 20,000,000 USDC. Los usuarios que operen pares de trading Spot, Margin, Convert, Futuros USDⓈ-M, Futuros COIN-M, bStocks y acciones que cumplan los requisitos, y alcancen un volumen efectivo acumulado de trading equivalente a al menos 10,000 $, durante el periodo de la campaña, pueden optar a una parte del fondo. La recompensa individual se calcula de acuerdo con la proporción que representa el volumen efectivo total de trading de cada usuario elegible, con una recompensa máxima de 4,000 USDC en cupones de tokens por usuario elegible en esta actividad.
2. Hasta un 10 % de TAE a través de productos Earn elegibles: La segunda actividad ofrece a los usuarios elegibles la oportunidad de obtener hasta un 10 % de TAE mediante productos seleccionados. Estos incluyen: Simple Earn Flexible de USDC, Simple Earn Flexible de USDT, RWUSD y BFUSD. La TAE exacta depende del producto, los requisitos de elegibilidad del usuario, el monto mantenido, el nivel VIP cuando corresponda y el nivel de bonificación aplicable. Por ejemplo, los usuarios elegibles que no sean VIP y mantengan menos del equivalente a 50,000 USD en USDC pueden recibir una TAE de bonificación del 7 % en el nivel que cumpla los requisitos, además de la TAE base en tiempo real. Para USDT Flexible, la campaña ofrece una TAE de bonificación del 8 % en el nivel elegible, además de la TAE base en tiempo real. RWUSD y BFUSD también tienen sus propias estructuras de bonificación. Es importante entender que hasta un 10 % de TAE no significa que todos los usuarios reciban una rentabilidad fija garantizada del 10 % por cada dólar que mantengan. Las tasas dependen del producto, se aplican por niveles y pueden cambiar.
La campaña se lleva a cabo desde el 2 de noviembre a las 11:30 UTC hasta el 21 de noviembre a las 23:59 UTC, sujeta a los requisitos de elegibilidad y a la disponibilidad regional.
Para mí, esta es otra parte de la historia que merece mencionarse. Binance seguía restableciendo los servicios y reforzando la seguridad, al tiempo que reconocía a la comunidad que permaneció a su lado durante todo ese difícil periodo. Por supuesto, una campaña promocional no sustituye a la seguridad, la transparencia ni la rendición de cuentas. Esos aspectos deben sostenerse por sí mismos. Pero, teniendo en cuenta todo lo que ocurrió, sigue siendo una iniciativa comunitaria significativa.
Lo que este incidente me enseñó sobre la confianza. Si hay algo que quiero que la gente se lleve de esta experiencia, es que confiar nunca debería significar ignorar los hechos. Soy Binance Angel, pero eso no significa que deba evitar hacer preguntas. Soy usuario desde hace mucho tiempo, pero eso no significa que deba fingir que un incidente de seguridad no es nada. Y creo en la plataforma, pero aun así espero transparencia, rendición de cuentas y mejoras continuas. El incidente dejó al descubierto debilidades que debían abordarse. También demostró por qué la seguridad nunca es un proyecto terminado. La tecnología evoluciona, los atacantes se vuelven más sofisticados e incluso las organizaciones consolidadas deben poner a prueba sus propios sistemas continuamente. Para Binance, el trabajo no termina con la reposición de los activos. La empresa debe seguir mejorando sus controles internos, las revisiones de seguridad independientes, la infraestructura de los monederos, la seguridad de los dispositivos de los empleados y los procedimientos de respuesta a incidentes. Para los usuarios, la lección es igual de importante: utilicen medidas de seguridad sólidas para sus cuentas, activen las protecciones disponibles, manténganse alerta ante la ingeniería social y nunca descarguen archivos sospechosos ni compartan credenciales confidenciales. Y para el sector, este es otro recordatorio de que la seguridad no consiste únicamente en proteger las claves privadas. También se trata de las personas, los dispositivos, las cadenas de suministro de software, los permisos internos, los procedimientos operativos y la capacidad de responder cuando algo sale mal.
Ocho años después, sigo aquí. Al recordar mi trayectoria desde 2019, recuerdo cómo empecé con 20 $, aprendí qué eran las criptomonedas, hice mis primeras operaciones, descubrí nuevos productos y, con el tiempo, pasé a formar parte de una comunidad global. Nunca imaginé que algún día escribiría sobre un incidente de seguridad de 6.34 mil millones de dólares que involucraría a la plataforma que me introdujo a este sector. Pero aquí estamos. Y si hay algo que puedo decir tras seguir toda esta situación es que valoro la diferencia entre una empresa que simplemente promete proteger a sus usuarios y una empresa que asume su responsabilidad financiera cuando algo sale muy mal. Binance tiene mucho trabajo por delante. Todavía hay que reponer los activos restantes, los servicios de retiro deben seguir restableciéndose de forma segura y las revisiones de seguridad independientes deben traducirse en mejoras significativas. Pero no he perdido la confianza en la plataforma. Empecé este camino en 2019 con 20 $. Sigo aquí en 2026, no porque crea que alguna empresa sea inmune a los ataques, sino porque creo que la rendición de cuentas se demuestra con acciones, no con eslóganes. El incidente de 6.34 mil millones de dólares fue un capítulo doloroso en la historia de Binance. Nunca debería restársele importancia, y nunca deberían olvidarse las lecciones. Pero también se convirtió en una prueba de responsabilidad financiera, resiliencia operativa y de la relación entre una plataforma y sus usuarios. Y, en lo personal, no me voy por un titular. Estoy aquí desde 2019. He visto crecer el ecosistema, he formado parte de su comunidad y he visto a Binance afrontar uno de sus mayores desafíos hasta ahora. Sigo confiando. Pero, más importante aún, seguiré exigiendo la transparencia y la rendición de cuentas que esa confianza merece. Porque estar SAFU no significa creer que nunca puede salir nada mal. Significa saber qué ocurre cuando algo sale mal.
Siempre he creído en Binance, pero esta experiencia ha reforzado aún más esa convicción. Creo en mi equipo, en esta increíble comunidad y en cada usuario que nos apoya. Ustedes son mi segunda familia. Estamos unidos, nos apoyamos mutuamente y nos respaldamos. Mi más sincero agradecimiento a @CZ , a todo el equipo de seguridad de Binance, a los desarrolladores, ingenieros y a todas las personas que trabajaron incansablemente entre bastidores para proteger nuestros fondos. Estaré siempre agradecida, primero como usuaria desde 2019 y ahora como Binance Angel.@Binance MENA @Binance Angels Quizás esto sea más personal de lo que la gente imagina. Mi país, Líbano, ha sufrido un colapso financiero que hizo desaparecer los ahorros de toda una vida de muchas personas y nos dejó a muchos con poco o nada en lo que apoyarnos. Sé lo que se siente al ver desaparecer años de trabajo duro y preguntarse si tu dinero está realmente a salvo. Binance me ofreció una experiencia diferente y, cuando llegó otro gran desafío, volvió a respaldar a sus usuarios. Circunstancias distintas, protecciones distintas, pero algo siguió igual: no tuve que afrontar la pérdida sola.
Binance, gracias por estar a nuestro lado. Gracias por proteger aquello por lo que tanto nos esforzamos y por darme otra razón para creer. Eternamente agradecida.🙏🏼