Bitget hackeado por 351,6 millones de dólares: ¿Está Lazarus detrás?

La primera transferencia fue lo bastante pequeña como para parecer inofensiva: se enviaron 0,84 Ether desde una cartera identificada como de Bitget a una dirección recién creada. Lo que ocurrió después no lo fue. Stablecoins, oro tokenizado, Ether, Avalanche, BNB y posiblemente 93,7 millones de XRP se movieron por varias redes mientras las carteras receptoras convertían y dispersaban los activos a gran velocidad.

Aviso de seguridad de la CEO de Bitget, Gracy Chen, sobre el incidente de 351,6 millones de dólares de la cartera caliente de X, al 24 de septiembre de 2026.

Aviso de seguridad de Bitget sitúa el importe afectado en unos 351,6 millones de dólares. El exchange afirma que sus sistemas detectaron transferencias no autorizadas a las 18:31 UTC del 24 de septiembre, que las carteras frías permanecieron seguras, que los saldos de los usuarios eran correctos y que las retiradas se pausaron durante una revisión de seguridad. Son revelaciones importantes, pero todavía no explican cómo un servicio de carteras generó transacciones que la empresa no tenía intención de autorizar.

Esa explicación ausente es el centro de la historia. La directora ejecutiva de Bitget, Gracy Chen, ha descrito un posible compromiso de la cadena de suministro que afectaría a un servicio de carteras del backend, en lugar de a una clave privada filtrada. Por separado, el investigador on-chain Specter ha relacionado parte del rastro de XRP robado con fondos asociados al hackeo de AFX de julio de 2026. Ese caso anterior fue atribuido a TraderTraitor, un grupo de amenazas vinculado a la República Popular Democrática de Corea (DPRK). La conexión es lo bastante concreta como para investigarla, pero no lo bastante completa como para afirmar como un hecho establecido que el atacante de Bitget fuera el Grupo Lazarus.

Qué ocurrió en el hackeo de Bitget

El rastro público de las transacciones se desarrolló por partes, por lo que las primeras estimaciones fueron mucho menores que la cifra final de Bitget. Los primeros rastreadores se centraron en redes compatibles con Ethereum Virtual Machine (EVM) y contabilizaron entre 170 y 183,8 millones de dólares. Más tarde, Bitget incluyó un conjunto más amplio de activos y redes en su estimación de 351,6 millones de dólares. La diferencia aparente no es automáticamente una contradicción, pero no se ha publicado una conciliación transacción por transacción.

La secuencia inicial más clara es la siguiente:

• Prueba inicial: Una transferencia de 0,84 Ether llegó a una dirección nueva aproximadamente en el mismo minuto en que Bitget afirma que sus sistemas de seguridad detectaron el incidente.

• Salidas de stablecoins: Según los informes, la dirección recibió unos 34,75 millones de Tether, 12,85 millones de USD Coin y 3.000 unidades de Tether Gold desde carteras identificadas como pertenecientes a exchanges.

• Conversión rápida: En Arbitrum, una dirección nueva independiente utilizó alrededor de 19,67 millones de USDT0 para comprar aproximadamente 7.111 Ether a través de UniswapX y 1inch Fusion. Según los informes, algunas ejecuciones pagaron una prima de hasta el 5 %, lo que sugiere que la velocidad importaba más que la eficiencia del precio.

• Redes adicionales: Se informó de alrededor de 821.012 Avalanche y de una transferencia posterior de 8,2 millones de USD Coin desde una infraestructura identificada como Bitget en Avalanche. La actividad en BNB Chain también apareció en la reconstrucción más amplia.

• Tramo de XRP: Según los informes, dos carteras identificadas como Bitget enviaron un total combinado de 93,7 millones de XRP a una nueva dirección de XRP Ledger. A los precios citados durante el incidente, ese tramo tenía un valor aproximado de 143 millones de dólares y podría explicar gran parte de la diferencia entre los primeros totales de EVM y la estimación de Bitget.

Divulgación inicial de Bitget sobre el incidente de la cartera del 24 de septiembre de 2026, la estimación de los fondos afectados y la suspensión temporal de retiros de Bitget, consultada el25 de septiembre de 2026, alrededor de las 02:40 UTC.

Por ahora, afectados es la palabra correcta para la cifra de 351,6 millones de dólares. Todavía no es un cálculo final de la pérdida neta. La cifra final debería restar cualquier activo que permaneciera bajo el control de Bitget, que hubiera sido congelado por emisores o exchanges, que hubiera sido devuelto o que se hubiera recuperado. Ninguna de esas categorías se había conciliado públicamente al cierre de la investigación.

El momento de los hechos también merece atención. La detección a las 18:31 UTC no puso fin de inmediato a todos los movimientos notificados. La transferencia de 8,2 millones de USD Coin en Avalanche fue reconstruida alrededor de las 20:55 UTC, más de dos horas después. Siguen siendo posibles varias explicaciones: es posible que las transacciones firmadas ya estuvieran en cola, que distintas redes requirieran medidas de contención separadas o que la vía comprometida aún pudiera enviar transacciones. Hasta que Bitget publique los registros de firma y la cronología de contención, la detección y la contención no deberían considerarse el mismo evento.

Por qué las primeras estimaciones de pérdidas fueron menores

Los incidentes de blockchain rara vez llegan acompañados de una factura clara. Los analistas ven distintas direcciones en momentos diferentes, las etiquetas de las carteras pueden retrasarse y un mismo conjunto de valor puede aparecer varias veces al intercambiarse o transferirse entre redes. Por tanto, sumar todas las cifras de un flujo de datos en tiempo real exageraría la pérdida.

Tres problemas contables determinaron las estimaciones de Bitget:

• Las transferencias y los intercambios se solapan: Si 19,67 millones de USDT0 se convierten en 7.111 Ether, el valor en dólares de ambos activos no puede sumarse como si fueran dos pérdidas independientes.

• Los puentes crean dos tramos visibles: Un activo puede salir de una cadena y aparecer en otra. Contar ambos lados sin cotejar el evento del puente duplica el mismo valor.

• Los precios se movieron durante el ataque: Se estaba comprando Ether de forma agresiva mientras los rastreadores valoraban el flujo. Un cálculo realizado diez minutos después podría producir un total en dólares diferente sin que se hubiera producido ningún robo nuevo.

La parte de XRP es el elemento no resuelto más importante. Si los 93,7 millones de XRP estaban controlados por el mismo atacante, la actividad en EVM más la transferencia de XRP sitúan la reconstrucción externa mucho más cerca de los 351,6 millones de dólares. Si ese destino correspondía a una función interna de Bitget o a otra contraparte legítima, la diferencia necesitaría otra explicación. Las etiquetas públicas por sí solas no pueden determinar la propiedad.

Actividad de Ethereum asociada a la dirección principal del incidente de Bitget comunicada desde Etherscan, consultado el 25 de septiembre de 2026. 

Un análisis post mortem adecuado eliminaría gran parte de esta ambigüedad al publicar las direcciones afectadas, los hashes de las transacciones, las funciones de los monederos internos, los activos transferidos, los activos convertidos, los importes congelados, los importes recuperados y la pérdida final pendiente. Sin ese libro contable, la estimación de 351,6 millones de dólares es creíble como total interno de Bitget, pero no puede reproducirse de forma independiente.

Cómo puede un monedero enviar una transacción válida que el exchange nunca autorizó

Una cadena de bloques solo comprueba si una transacción cumple sus reglas de autorización criptográfica. No sabe si el equipo de riesgos del exchange aprobó el pago, si un empleado vio el destino correcto o si un sistema backend comprometido proporcionó datos de transferencia falsos a un firmante que funcionaba correctamente.

Esta distinción ayuda a entender la explicación preliminar de Chen. Dijo que el incidente podría parecerse a un ataque a la cadena de suministro en el que una herramienta de terceros utilizada por Bitget afectó a un servicio backend crítico del monedero. Según ese relato, información de transferencia falsificada llegó a una máquina de firma aunque el atacante no hubiera extraído directamente una clave privada. La posibilidad de que hubiera una persona interna implicada se describió como baja, no imposible, y el vector final seguía bajo investigación.

En un proceso normal de retirada, varios controles deberían coincidir antes de mover los fondos:

1. Un cliente o un proceso interno de tesorería crea una solicitud de transferencia legítima.

2. Las comprobaciones de la cuenta, el dispositivo, la dirección y el riesgo determinan si se permite la solicitud.

3. Un motor de políticas comprueba el activo, la red, el destino, el importe, la velocidad y el umbral de aprobación.

4. Uno o varios componentes de firma autorizan los datos exactos de la transacción.

5. Un servicio de difusión envía la transacción firmada a la red.

6. Los sistemas de monitorización comparan el resultado con la solicitud empresarial aprobada y detienen cualquier actividad anómala posterior.

Comprometer una sola etapa puede no ser suficiente si los controles restantes son realmente independientes. La preocupación en el análisis preliminar de Bitget es que un componente de software de confianza podría haber estado lo bastante cerca del flujo de firma como para influir en lo que el firmante aprobó. Si el firmante solo validó que una solicitud procedía de un servicio permitido, en lugar de confirmar de forma independiente el destino y el importe comparándolos con un registro de aprobación inmutable, las firmas válidas aún podrían autorizar transferencias maliciosas.

Las vías más plausibles de fallo de los controles

Ninguna de las siguientes hipótesis ha sido demostrada, pero cada una ofrece una lección diferente:

• Proveedor o actualización de software comprometidos: Un atacante corrompe una dependencia, una herramienta administrativa o un servicio utilizado en el flujo de la cartera. El exchange podría confiar en las solicitudes originadas por ese componente.

• Robo de credenciales del backend: Una cuenta de servicio, una credencial de interfaz de programación de aplicaciones, una sesión o un token privilegiado permite al atacante hacerse pasar por un sistema interno autorizado.

• Elusión del motor de políticas: La solicitud de firma llega al firmante sin que se apliquen los límites habituales, las listas de direcciones permitidas, los controles de velocidad o los umbrales de aprobación.

• Manipulación de la interfaz de firma: Los operadores humanos aprueban una transacción mientras el sistema de firma recibe otra. Esto puede ocurrir cuando la pantalla y la carga útil firmada no están vinculadas de forma independiente.

• Compromiso de una participación de clave o de un firmante: Un diseño de firma múltiple o de computación multipartita (MPC) también puede fallar si el atacante compromete a suficientes firmantes, al coordinador o al proceso de aprobación que los rodea.

• Acceso privilegiado de empleados internos o contratistas: Una persona autorizada, o un atacante que utilice el acceso de esa persona, envía o aprueba transferencias maliciosas. Actualmente, Bitget considera improbable un ataque interno, pero no ha publicado pruebas que lo descarten.

La descripción de Bitget de las carteras calientes, templadas y frías no determina qué vía falló. Una cartera caliente está diseñada para transacciones frecuentes en línea. Una cartera templada suele añadir aprobaciones o aislamiento más sólidos, sin dejar de estar disponible para las operaciones. Una cartera fría mantiene la autoridad de firma fuera de línea o separada de otro modo de los sistemas habituales conectados a Internet. Estas etiquetas describen el uso previsto, no los controles reales aplicados a cada dirección la noche de la brecha.

Los rastreadores externos también etiquetaron al menos una fuente como infraestructura fría, mientras que Bitget afirma que no se comprometió ninguna billetera fría. Cualquiera de las partes podría estar utilizando una clasificación diferente. El conflicto solo puede resolverse asignando las direcciones públicas a sus funciones internas y explicando cómo se operó cada firmante.

Por qué importa la velocidad de conversión

El atacante no parecía interesado en conservar una cesta ordenada de los activos sustraídos. Las stablecoins y el oro tokenizado plantean un problema evidente para un ladrón: los emisores podrían congelar los saldos identificados. El Ether tiene más liquidez en plataformas descentralizadas y no cuenta con un emisor central que disponga de un mecanismo de congelación equivalente.

Por tanto, pagar una prima para adquirir Ether a través de agregadores parece menos irracional de lo que inicialmente aparenta. Un atacante sofisticado puede aceptar una ejecución desfavorable cuando cada minuto aumenta la probabilidad de que un emisor, puente, exchange o servicio de validadores bloquee el siguiente paso. El patrón de conversión sugiere preparación, acceso a rutas preseleccionadas y disposición a perder parte del valor para mejorar la movilidad.

No identifica al atacante. La conversión rápida de stablecoins se ha convertido en un comportamiento operativo habitual en muchos robos de criptomonedas de gran escala. La técnica puede respaldar una atribución más amplia, pero no puede sostenerla por sí sola.

Por qué se sospecha de hackers vinculados a Corea del Norte

La teoría de Corea del Norte se basa en tres tipos diferentes de pruebas: un comportamiento que se asemeja al de robos anteriores vinculados a Estados, indicadores técnicos privados descritos por el director ejecutivo de Bitget y una afirmación pública en la cadena que conecta parte del rastro de XRP con el exploit anterior de AFX. Esas capas no tienen la misma solidez, y combinarlas no las convierte automáticamente en una prueba.

1. El comportamiento de blanqueo resulta familiar, pero no es distintivo

La primera pista es la velocidad del atacante. Las stablecoins y Tether Gold se convirtieron en Ether, los fondos se dividieron entre direcciones nuevas y la actividad atravesó varias redes. El aviso del FBI sobre Bybit describió a los actores de TraderTraitor convirtiendo rápidamente los activos robados y dispersándolos entre miles de direcciones y múltiples cadenas de bloques tras el robo de febrero de 2025.

Ese parecido explica por qué la RPDC apareció tan rápidamente en la conversación. Sigue siendo la capa más débil. Los grupos criminales copian rutas de blanqueo exitosas, los agregadores seleccionan caminos similares para usuarios no relacionados y cualquier atacante que posea tokens susceptibles de congelación tiene el mismo incentivo para pasarse a un activo más resistente a la censura. «Cambiaron rápidamente a Ether» es una coincidencia de comportamiento, no una huella digital.

2. Bitget afirma que los indicadores de IP y VPN se parecen a los de un grupo de la RPDC

Chen también mencionó direcciones del Protocolo de Internet (IP) y opciones de redes privadas virtuales (VPN) que los investigadores asociaron con un grupo vinculado a la RPDC. Los registros internos de acceso podrían ser relevantes si muestran la misma infraestructura poco común controlada anteriormente por un actor conocido, especialmente cuando se combinan con pruebas coherentes relacionadas con dispositivos, malware, dominios o autenticación.

El público no ha visto ese material. Una dirección IP puede pertenecer a una VPN comercial, un servidor comprometido, un proxy residencial u otra víctima. Varios actores pueden pasar por el mismo punto de conexión, y un atacante cuidadoso puede tomar deliberadamente infraestructura asociada con un rival. Una coincidencia de IP solo resulta convincente cuando los investigadores explican cómo se atribuyó la dirección, quién la controlaba durante el minuto pertinente y qué otros indicadores la acompañaban.

La hipótesis de Bitget sobre la cadena de suministro es compatible con las tácticas conocidas de la RPDC, pero la compatibilidad no equivale a una atribución. Un aviso de ciberseguridad de TraderTraitor describe técnicas de ingeniería social y aplicaciones de criptomonedas troyanizadas utilizadas para acceder a empleados y sistemas corporativos. Un posterior informe del FBI sobre el robo de DMM Bitcoin explica cómo un falso reclutador, una prueba de programación maliciosa, información de sesión robada y la manipulación de una solicitud legítima de transacción quedaron vinculados en una misma operación.

Estos precedentes demuestran que los operadores de la RPDC han atacado las capas humana y de software que rodean a las carteras de criptomonedas, no solo las claves privadas. No demuestran que se utilizara el mismo método de entrada contra Bitget. El exchange aún debe identificar el componente comprometido, la vía de acceso inicial, las credenciales afectadas y el fallo de la política de firma.

3. TraderTraitor es una etiqueta de amenaza específica, no un sinónimo de cualquier hackeo de criptomonedas

TraderTraitor es el nombre utilizado por el Gobierno de EE. UU. para referirse a determinadas actividades cibernéticas maliciosas de Corea del Norte dirigidas contra la industria de la cadena de bloques y las criptomonedas. También puede hacerse referencia al mismo ecosistema más amplio con etiquetas como Lazarus Group, APT38, Jade Sleet, UNC4899 o Slow Pisces, dependiendo de la agencia, la empresa de seguridad, la operación y el periodo.

Estas etiquetas se solapan, pero no son atajos intercambiables. Afirmar que un grupo relacionado con AFX fue atribuido a TraderTraitor no demuestra que todas las direcciones conectadas estén operadas por las mismas personas, ni demuestra que la intrusión de Bitget utilizara el mismo malware o equipo de acceso. Los grandes programas vinculados a Estados pueden involucrar a distintos operadores, infraestructuras, intermediarios y especialistas en blanqueo.

La terminología importa porque decir que «Lazarus hackeó Bitget» suena definitivo. Las pruebas disponibles en la fecha de corte respaldan una afirmación más limitada: Se sospecha de actores vinculados a Corea del Norte porque un investigador externo conectó el rastro de XRP con una ruta de fondos de AFX asociada a TraderTraitor, mientras que Bitget afirma que los indicadores internos de IP y VPN apuntan en la misma dirección.

4. Qué convertiría la sospecha en una atribución defendible

Un caso público más sólido combinaría pruebas independientes de varias capas:

• Trazado reproducible de la cadena de bloques: Hashes exactos de las transacciones de XRP y entre cadenas, eventos de puentes, direcciones controladas por el actor, reglas de agrupación y una explicación de cualquier exposición a través de servicios compartidos.

• Pruebas de infraestructura: Dominios, servidores, certificados, cuentas VPN, historial de proxies o errores operativos vinculados a una infraestructura controlada anteriormente por el mismo actor.

• Pruebas de intrusión: Malware, scripts, tráfico de mando y control, robo de credenciales, secuestro de sesiones o un paquete de proveedor comprometido con coincidencias de código o infraestructura.

• Coherencia de la cronología: Pruebas de que el actor controlaba las direcciones y la infraestructura vinculadas en el momento de ambos incidentes, el de AFX y el de Bitget.

• Revisión independiente: Una empresa forense identificada, un consorcio de exchanges o una autoridad pública que reproduzca el hallazgo, en lugar de repetir una etiqueta de las redes sociales.

• Atribución de una autoridad pública: Una declaración gubernamental que identifique al actor y publique suficientes direcciones o indicadores técnicos para que la industria pueda actuar.

El caso de Bybit de 2025 ofrece un punto de referencia útil. Cinco días después del robo, el FBI atribuyó públicamente el incidente a Corea del Norte, nombró a TraderTraitor, describió el comportamiento de blanqueo y enumeró docenas de direcciones de Ethereum relacionadas. El caso de Bitget apenas tiene unas horas en el momento de cierre de este artículo. La falta de una confirmación equivalente no resulta sorprendente todavía, pero significa que la redacción debe seguir siendo provisional.

5. Qué podría debilitar la teoría de Corea del Norte

La hipótesis actual perdería fuerza si la supuesta coincidencia con AFX resultara ser una dirección compartida de un exchange, puente o servicio; si el destino de XRP no estuviera controlado por el atacante; si la cronología demostrara que el monedero común cambió de manos; o si la atribución a AFX no pudiera reproducirse de forma independiente. También se debilitaría si las pruebas internas de Bitget apuntaran a un conjunto de intrusión diferente o a un empleado interno con motivación económica.

También existe el riesgo de una operación de falsa bandera. Una vez que los patrones de blanqueo de Lazarus están ampliamente documentados, otro grupo puede imitarlos. Copiar una ruta de intercambio es fácil. Recrear un clúster de monederos de larga duración, una infraestructura privada, un linaje de malware y errores operativos es mucho más difícil.

Por tanto, el veredicto más justo es indicio creíble, atribución incompleta. La teoría de Corea del Norte tiene más fundamento que un rumor anónimo porque incluye un vínculo propuesto entre fondos de ambos incidentes y una pista independiente de infraestructura del lado de la empresa. Sigue estando por debajo del estándar necesario para afirmar que Lazarus Group llevó a cabo el hackeo de Bitget.

Lo que Bitget todavía debe explicar

El primer aviso del exchange respondió a las preguntas más urgentes de los clientes: se produjo un incidente, los retiros se pausaron y la empresa afirmó que los saldos y los monederos fríos seguían a salvo. El próximo informe debe pasar de las garantías a las pruebas.

Los elementos que faltan son concretos:

• Causa raíz: ¿Qué software, proveedor, servicio, credencial o capa de aprobación se vio comprometido?

• Ruta de firma: ¿El atacante generó nuevas firmas, manipuló los datos de las transacciones antes de la firma o abusó de transacciones ya autorizadas?

• Infraestructura afectada: ¿Qué direcciones eran calientes, templadas o frías, y qué controles de monedero se aplicaban a cada una?

• Contención: ¿Por qué continuaron las transferencias notificadas después de la detección y cuándo se deshabilitó realmente la ruta maliciosa?

• Conciliación de pérdidas: ¿Cómo llega el exchange a 351,6 millones de dólares entre activos y cadenas sin contabilizar dos veces los intercambios o puentes?

• Recuperación: ¿Cuánto se congeló, devolvió o recuperó, y cuánto sigue fuera del control de Bitget?

• Acceso de los clientes: ¿Cuándo se reabrirán los retiros, en qué redes y con qué límites o condiciones de cola?

• Medidas correctivas: ¿Qué controles cambiaron antes de que se pudiera volver a confiar en la misma ruta de firma o backend?

• Atribución: ¿Qué pruebas respaldan la sospecha sobre la RPDC y algún investigador externo identificado la ha reproducido?

Alrededor de las 02:40 UTC del 25 de septiembre, los retiros seguían oficialmente suspendidos y el informe de incidentes prometido para 24 horas después aún no había vencido. Que los depósitos y el trading sigan operativos no responde a la misma cuestión que los retiros. Un saldo en un libro mayor interno adquiere relevancia práctica cuando el cliente puede canjearlo mediante una vía de retiro operativa y segura.

¿Puede el Fondo de Protección de Bitget cubrir la pérdida?

Bitget afirma que su Fondo de Protección de Usuarios contiene más de 464 millones de dólares y cubre por completo el importe afectado de 351,6 millones de dólares. Sus materiales públicos identifican 5.500 Bitcoin como la tenencia principal. A un precio de Bitcoin de aproximadamente 84.403 dólares, esa posición valdría unos 464,2 millones de dólares.

Las cuentas cuadran a ese precio, pero el margen es menor de lo que sugiere el titular:

• Cobertura nominal: Aproximadamente el 132 % de la estimación de fondos afectados.

• Bitcoin necesario: Aproximadamente 4.166 Bitcoin para igualar los 351,6 millones de dólares.

• Fondo utilizado: Aproximadamente el 75,7 % si toda la pérdida se pagara con esa posición en Bitcoin.

• Remanente nominal: Aproximadamente 1.334 Bitcoin, antes de costes de transacción, variaciones de precio, otras reclamaciones elegibles o impacto de mercado.

• Precio de equilibrio: Aproximadamente 63.927 dólares por Bitcoin reducirían los 5.500 Bitcoin al tamaño de la pérdida declarada.

Más importante aún, el fondo es una reserva controlada por la empresa, no un seguro de depósitos respaldado por el Gobierno. Las pruebas públicas aún no han demostrado si los activos están segregados, libres de cargas, son transferibles de inmediato o están formalmente comprometidos con este incidente. La pregunta útil ya no es si 464 millones de dólares son más que 351,6 millones de dólares. Es si el fondo puede verificarse y utilizarse sin crear un segundo problema de liquidez.

El informe de septiembre Prueba de reservas (PoR) aporta contexto, no una conclusión. Bitget publicó un coeficiente de reservas agregado del 135 % en 19 activos antes de la brecha de seguridad. Esa instantánea puede mostrar que los activos cubiertos superaban los saldos correspondientes incluidos en el momento de la medición. No puede mostrar la posición posterior al incidente, demostrar que se incluyeron todos los pasivos ni demostrar que los controles de las carteras son seguros.

Qué deben comprobar los traders después de una brecha de seguridad en cualquier exchange

La seguridad de un exchange no puede reducirse a un único porcentaje, certificación, fondo de tipo asegurador o afirmación sobre el almacenamiento en frío. El enfoque útil consiste en examinar varias capas y entender qué puede y qué no puede demostrar cada una.

• Comportamiento de los retiros: Comprueba si los retiros funcionan con los activos y las redes que realmente utilizas. Un retiro pequeño y exitoso aporta más información que la visualización de un saldo interno.

• Evidencia de reservas: Busca instantáneas recientes de activos y pasivos, pruebas de titularidad de las carteras, informes históricos y una forma de verificar que tu propio saldo estaba incluido.

• Seguridad operativa: Revisa el diseño de la custodia, la separación de firmantes, los controles de direcciones, la supervisión, la respuesta ante incidentes y las pruebas independientes.

• Información corporativa: Comprueba la entidad operativa, la jurisdicción, las condiciones legales, la información financiera y si los activos de los clientes se tratan por separado.

• Historial de incidentes: Lee los informes posteriores al incidente, no solo los anuncios. La calidad de una respuesta se aprecia en las direcciones, las cronologías, las causas raíz y los detalles de las medidas correctivas que publica.

• Controles de la cuenta: Activa la autenticación de dos factores (2FA) mediante una aplicación, utiliza una contraseña única, activa un código antiphishing, revisa los dispositivos activos y aplica listas de direcciones permitidas para retiros cuando estén disponibles.

• Límites de custodia: Mantén en una plataforma centralizada solo la cantidad necesaria para operar o realizar transferencias a corto plazo. La autocustodia elimina el riesgo de custodia del exchange, pero introduce sus propios riesgos de gestión y recuperación de claves.

Comparativa de los principales exchanges de criptomonedas en materia de transparencia

Esto no es una clasificación de seguridad. Cada fila describe una vía pública de verificación disponible el 25 de septiembre de 2026 y la pregunta que puede ayudar a responder. Ninguna demuestra que un exchange no pueda ser hackeado, que haya revelado todos sus pasivos o que mantenga los retiros abiertos durante una crisis.

Lo que realmente revela la comparación de exchanges

La tabla no determina un ganador universal porque los exchanges divulgan distintos tipos de pruebas. Coinbase ofrece informes corporativos convencionales mediante estados financieros trimestrales y auditorías independientes anuales. Binance y OKX publican sistemas criptográficos de reservas con datos de monederos y herramientas de verificación para usuarios. Kraken combina la verificación a nivel de cuenta con ratios de reservas para los activos admitidos, mientras que Bybit y Toobit ofrecen formas basadas en Merkle para que los usuarios comprueben si sus saldos se incluyeron en una instantánea concreta de reservas.

Estas divulgaciones responden a preguntas relacionadas, pero diferentes:

• Prueba de Reservas: ¿Mostró el exchange suficientes activos cubiertos para igualar los saldos de clientes incluidos en un momento determinado?

• Verificación de inclusión de usuarios: ¿Puede una persona confirmar que su saldo se contabilizó entre los pasivos declarados?

• Evidencia de propiedad de las carteras: ¿Ha demostrado el exchange el control de las direcciones presentadas como reservas?

• Estados financieros: ¿Cómo son los activos, pasivos, ingresos, gastos, riesgos y obligaciones corporativas generales de la empresa?

• Evaluaciones de seguridad: ¿Han comprobado especialistas externos partes de la plataforma, las aplicaciones, la infraestructura de custodia o los controles internos?

• Fondos de protección: ¿Ha reservado el exchange un fondo separado que pueda responder ante incidentes de seguridad definidos?

Ningún elemento responde a todo. Un exchange puede mantener reservas suficientes y aun así sufrir el compromiso de una cartera. Puede superar una evaluación de seguridad y posteriormente introducir una integración vulnerable. Puede mantener un fondo de protección sin demostrar con qué rapidez puede utilizarse. También puede publicar estados financieros auditados sin ofrecer a los usuarios una forma criptográfica de verificar la inclusión de sus saldos individuales.

La comparación útil no consiste simplemente en qué exchange muestra el porcentaje más alto. Consiste en cuántas capas independientes pueden comprobarse, qué tan actualizadas están y si las pruebas coinciden con el riesgo que se está evaluando.

Por qué la Prueba de Reservas no puede demostrar la seguridad de las carteras

La PoR puede mostrar que existían activos cubiertos frente a los saldos de clientes incluidos en una instantánea definida. No está diseñada para demostrar que los sistemas que controlan esos activos sean imposibles de comprometer.

El incidente de Bitget deja clara esa distinción. Su informe de septiembre mostró un ratio de reservas agregado del 135 % en 19 activos antes de la brecha de seguridad. El excedente declarado no impidió que una vía de transacción no autorizada moviera fondos. El problema investigado se refiere a las operaciones de las carteras, la autorización de transacciones o el software que las rodea, no simplemente a si los activos aparecían en las carteras de reserva antes del incidente.

Un informe de reservas puede ayudar a responder:

• ¿Se incluyeron los saldos de clientes cubiertos en el cálculo de pasivos?

• ¿Las carteras divulgadas contenían una cantidad suficiente de los activos pertinentes?

• ¿Podían los usuarios verificar su inclusión mediante una ruta de Merkle u otro método criptográfico?

• ¿Existe un historial de informes que pueda compararse a lo largo del tiempo?

Por lo general, no puede responder:

• ¿Puede un backend comprometido enviar una solicitud de firma maliciosa?

• ¿Se aplican las políticas de retiro de forma independiente de la aplicación que crea la transacción?

• ¿Podría un empleado, contratista o proveedor influir en varias capas de aprobación?

• ¿Se incluyen todas las deudas corporativas, pasivos contingentes, préstamos y obligaciones legales?

• ¿Continuarán los retiros con normalidad durante un incidente de seguridad o una crisis de liquidez?

• ¿Se puede acceder a un fondo de protección de inmediato y sin restricciones?

• ¿La próxima versión del software mantendrá los controles probados en la evaluación anterior?

Por lo tanto, la transparencia de las reservas y la seguridad de las transacciones requieren evaluaciones independientes. La PoR se ocupa principalmente del respaldo de activos en un momento determinado. La seguridad de las carteras se ocupa de cómo se solicitan, aprueban, firman, difunden y detienen las transacciones cuando algo sale mal.

Bybit ofrece un ejemplo histórico útil. El exchange contaba con divulgaciones de reservas y herramientas de verificación de usuarios antes de su brecha de seguridad de 2025, pero el incidente implicó un problema diferente relacionado con el flujo de firma. Las pruebas de reservas seguían teniendo valor, pero no funcionaron como escudo contra la manipulación de transacciones.

Bitget se enfrenta ahora a una carga de explicación similar. Una nueva instantánea de reservas podría ayudar a medir el efecto financiero de la pérdida. No sustituiría la necesidad de un informe técnico sobre el servicio comprometido y los controles de autorización que fallaron.

Cómo leer los ratios de reservas sin dejarse engañar

Un ratio de reservas superior al 100 % parece tranquilizador, pero la cifra necesita contexto. Un ratio del 106 % significa que las reservas declaradas para ese activo superaban en torno a un 6 % los saldos correspondientes incluidos en la instantánea. No significa que el exchange tenga un colchón de capital del 6 % frente a cualquier posible pérdida.

Varios detalles determinan la utilidad del porcentaje:

• Alcance de los activos: Un informe que cubre cuatro activos principales no equivale a uno que cubre 19 o 22 activos.

• Alcance de los pasivos: El informe debería explicar qué tipos de cuentas, préstamos, posiciones de margen u otras obligaciones se incluyeron en el cálculo.

• Fecha de la instantánea: Un informe anterior al incidente no puede establecer la situación financiera del exchange después de una pérdida importante.

• Pruebas de las carteras: Los lectores deberían poder ver cómo el exchange demostró el control de las direcciones declaradas.

• Verificación de usuarios: Un ratio destacado es más sólido cuando los clientes pueden verificar de forma independiente que sus saldos se incluyeron.

• Continuidad histórica: Los informes archivados periódicamente facilitan la identificación de cambios abruptos en las reservas o la cobertura.

• Revisión externa: La verificación independiente puede aportar confianza, aunque el revisor, la metodología y el alcance evaluado siguen siendo importantes.

Un porcentaje más alto puede reflejar un excedente real, pero también puede verse influido por un conjunto limitado de pasivos, saldos temporales, movimientos en el precio de los activos o la exclusión de productos que quedan fuera del informe. Comparar porcentajes destacados sin comparar el alcance crea una jerarquía falsa.

Por la misma razón, no debería describirse a un exchange más pequeño que informa sobre cuatro activos como más transparente que uno más grande únicamente porque uno de sus porcentajes sea mayor. También importan la amplitud del informe, la metodología de pasivos, las pruebas de las billeteras, la frecuencia y el proceso de verificación de usuarios.

Dónde encaja Toobit en la comparación

Las divulgaciones públicas de Toobit abordan dos cuestiones distintas. El informe de reservas de septiembre analiza si cuatro activos principales superaban los saldos correspondientes de los usuarios en un momento concreto. Sus páginas de seguridad describen cómo afirma el exchange que se protegen esos activos y las cuentas de los usuarios durante las operaciones normales.

Estas divulgaciones son más útiles cuando se examinan por separado. Un ratio de reservas puede mostrar la cobertura de activos en un momento determinado, mientras que una prueba de Merkle puede ayudar al usuario a comprobar si el saldo de una cuenta se incluyó en el conjunto de pasivos declarado. Ninguna de las dos demuestra que todas las billeteras, sistemas internos o transacciones futuras vayan a permanecer seguras.

Los ratios de reservas de Toobit en septiembre

Ratios de reservas de Toobit para BTC, ETH, USDT y USDC a fecha de1 de septiembre de 2026, UTC, de Toobit, consultado el 25 de septiembre de 2026.

Los cuatro ratios superaban el 100 % en ese momento. Esto significa que las reservas declaradas de cada activo cubierto superaban los saldos correspondientes de los usuarios incluidos en el informe. La cantidad por encima del 100 % variaba según el activo, desde un margen del 2 % para Ether hasta un margen del 6 % para Tether.

Estos porcentajes no deben sumarse ni tratarse como un único ratio de capital de todo el exchange. Cada uno compara la reserva de un activo concreto con el saldo correspondiente de los usuarios incluidos. Por ejemplo, el ratio del 106 % de Tether no dice nada por sí solo sobre los pasivos denominados en otro activo.

El alcance importa tanto como los porcentajes. Este informe cubre cuatro activos de uso generalizado, mientras que las divulgaciones indicadas para Bitget y OKX cubren un número mayor de activos. El informe de Toobit es útil para comprobar las cuatro reservas mencionadas, pero no demuestra la cobertura de todos los tokens o productos disponibles en la plataforma.

Cómo pueden los usuarios verificar la inclusión de sus saldos

Un ratio de reservas publicado sigue siendo una cifra a nivel de empresa hasta que los usuarios pueden comprobar si sus propios saldos se incluyeron en el cálculo de pasivos. La página de Prueba de Reservas de Toobit proporciona una raíz de Merkle y un proceso de verificación para ese fin.

Un árbol de Merkle convierte los registros de cuentas individuales en hashes criptográficos y los combina en un único valor raíz. De este modo, un usuario puede verificar que un saldo formó parte de la instantánea sin exponer la información de las cuentas de los demás clientes.

Raíz de Merkle de Toobit e interfaz de verificación de inclusión de cuentas para su sistema de Prueba de Reservas de Toobit, consultado el 25 de septiembre de 2026.

La herramienta de Merkle aborda una debilidad importante de un simple anuncio de reservas. Ofrece a los usuarios una forma de comprobar si sus cuentas se contabilizaron, en lugar de pedirles que acepten únicamente un porcentaje agregado.

Aun así, esa verificación tiene límites. La inclusión demuestra que un saldo entró en la estructura de pasivos declarada. No demuestra de forma independiente que se incluyeran todos los pasivos, que los activos declarados estuvieran libres de cargas o que el exchange mantenga la misma posición de reservas después de la instantánea.

Una comprobación personal útil debería responder a tres preguntas:

1. ¿Coincide el registro de verificación con la fecha correcta de auditoría?

2. ¿Incluye los activos y saldos que el usuario tenía en esa instantánea?

3. ¿Puede comprobarse la prueba mediante el proceso de verificación proporcionado o una herramienta de código abierto?

Una comprobación de inclusión satisfactoria refuerza la conexión entre la cuenta del usuario y el informe de reservas publicado. No convierte el informe en una auditoría financiera completa.

Los controles que rodean las reservas

La cobertura de reservas y la seguridad de los monederos abordan riesgos diferentes. Una instantánea de reservas puede mostrar si determinados activos cubrían los saldos de usuario correspondientes en un momento concreto. La siguiente pregunta es cómo protege un exchange esos activos, controla el acceso a las transacciones y responde cuando aparece actividad sospechosa.

Toobit agrupa su marco Bee-Safe en seis áreas:

• Prueba de Reservas: Respaldo de activos que los usuarios pueden verificar mediante el sistema de reservas del exchange.

• Infraestructura resiliente: Infraestructura multicloud destinada a respaldar la disponibilidad de la plataforma y la actividad de trading.

• Medidas de protección proactivas: Autenticación multifactor, almacenamiento en frío y auditorías continuas.

• Seguridad de los datos: Arquitectura de confianza cero, cifrado y controles de detección de phishing.

• Privacidad completa: Medidas de protección de datos que incluyen seguridad de conocimiento cero y controles biométricos.

• Defensa activa 24/7: Monitoreo y soporte continuos destinados a detectar y responder ante actividades sospechosas.

El marco Bee-Safe de Toobit, que abarca la Prueba de Reservas, la resiliencia de la infraestructura, las salvaguardas de las cuentas, la seguridad de los datos, la privacidad y el monitoreo activo de Toobit, al 25 de septiembre de 2026.

Estas capas cubren riesgos que un índice de reservas no puede medir. La Prueba de Reservas aborda el respaldo de los activos, mientras que los controles de autenticación y contra el phishing operan a nivel de cuenta. El almacenamiento en frío se ocupa de la custodia, el cifrado protege los datos sensibles y el monitoreo continuo tiene como objetivo identificar actividades anómalas antes de que se propaguen.

El marco muestra qué salvaguardas afirma tener implementadas Toobit, pero la existencia de un control no demuestra que vaya a funcionar perfectamente en todos los incidentes. Su valor práctico depende de cómo se implementen, prueben, revisen de forma independiente y actualicen los controles cuando surjan nuevas vulnerabilidades.

La interpretación equilibrada de la divulgación de Toobit

Toobit ofrece tres capas visibles de transparencia:

1. Índices de reservas a nivel de activos para cuatro activos principales en el informe de septiembre.

2. Inclusión de saldos basada en Merkle que los usuarios pueden verificar frente a la instantánea correspondiente.

3. Controles de seguridad publicados que abarcan el acceso a las cuentas, la custodia, la infraestructura, las pruebas y la preparación para incidentes.

Esta combinación ofrece a los usuarios más elementos que revisar que una declaración general de que los activos están seguros. El anuncio de reservas proporciona cifras históricas fijas, el panel de PoR ofrece una vía de verificación y la página de Seguridad identifica los controles que, según Toobit, protegen las reservas.

Las limitaciones deben seguir siendo visibles junto a esos puntos fuertes. El informe de septiembre abarca cuatro activos, no todos los tokens disponibles en la plataforma. La PoR es una instantánea, no una prueba continua de solvencia. La inclusión en Merkle no revela todos los pasivos corporativos. Los controles de seguridad pueden reducir el riesgo sin eliminar los fallos de software, proveedores, operaciones, personal interno o sistemas de firma.

Por tanto, las pruebas respaldan una conclusión matizada: Toobit ofrece un proceso de reservas práctico y verificable por los usuarios para Bitcoin, Ether, Tether y USD Coin, junto con varios controles de cuentas y custodia descritos públicamente. Los lectores deben evaluar esas pruebas según su propio alcance, en lugar de considerar la vulneración de Bitget como una prueba automática de que otro exchange es más seguro.

Lo que una tabla comparativa no puede captar

Una tabla puede organizar las divulgaciones, pero no puede reproducir la experiencia de utilizar un exchange durante una situación de estrés. La ejecución de retiros, la respuesta del soporte, la comunicación de incidentes, las restricciones regionales, la liquidez y las revisiones de cuentas pueden cambiar más rápido que un informe de reservas.

El acceso legal también difiere según el país. Dos usuarios que abran la misma marca global pueden interactuar con distintas entidades operativas, productos, socios de pago, estructuras de custodia o condiciones contractuales. Un servicio disponible en una jurisdicción puede estar limitado o no estar disponible en otra.

Antes de seleccionar un exchange, los lectores deberían verificar:

1. Si se admiten el activo y la red necesarios.

2. Las comisiones actuales de depósito, trading, conversión y retiro.

3. Los límites de retiro y los requisitos de verificación de la cuenta.

4. La fecha y el alcance de activos de la divulgación de reservas más reciente.

5. Si se puede comprobar la inclusión del saldo individual.

6. El historial de incidentes del exchange y la calidad de sus informes posteriores.

7. Las protecciones de cuenta y los controles de retiro disponibles.

8. Si un pequeño retiro de prueba se completa correctamente.

9. Cuánto capital debe permanecer realmente bajo la custodia del exchange.

Esta última pregunta suele pasarse por alto. Elegir un exchange no exige mantener allí todos los activos indefinidamente. Los traders pueden separar el capital destinado al trading activo de las tenencias a más largo plazo y decidir qué riesgos están preparados para gestionar. La custodia centralizada introduce riesgo de plataforma y de contraparte. La autocustodia elimina al exchange del proceso de firma, pero hace que el propietario sea responsable de las claves privadas, las copias de seguridad, la seguridad de los dispositivos, la planificación sucesoria y los errores irreversibles.

Por tanto, la comparación es un punto de partida para la diligencia debida. Muestra qué afirmaciones pueden comprobarse y dónde persisten las lagunas. No convierte a ningún exchange en un custodio sin riesgo.

La verdadera prueba es lo que ocurre después

El robo en sí ya no está en duda. Las preguntas abiertas son si Bitget puede presentar un registro reproducible de las pérdidas, restablecer los retiros de forma segura, demostrar la disponibilidad del Fondo de Protección y explicar cómo un sistema considerado fiable envió transacciones no autorizadas.

Vale la pena seguir la hipótesis de la RPDC porque dos líneas independientes apuntan en esa dirección: los indicios sobre la infraestructura privada de Bitget y la conexión propuesta por Specter entre la ruta de XRP y el robo de AFX. Ninguna de las dos líneas es lo bastante pública como para cerrar el caso. Un informe posterior sólido debería separar lo que el exchange sabe de lo que sospecha, y una atribución creíble debería permitir a investigadores externos reproducir la cadena.

Hasta entonces, la descripción más honesta es sencilla. Bitget sufrió un incidente importante en una billetera multicadena que involucró alrededor de 351,6 millones de dólares en fondos afectados. Se está investigando un fallo del backend o de la cadena de suministro. Se sospecha de actores vinculados a la RPDC, pero no está confirmado. Los retiros, la pérdida neta final, el uso de los fondos y el control fallido son los hechos que aún pueden cambiar la historia.

Investiga por tu cuenta (DYOR). Este artículo se basa en divulgaciones públicas del incidente y en información on-chain disponible en la fecha de corte indicada. No confirma la identidad del atacante ni la solvencia de Bitget, garantiza la recuperación de los fondos ni recomienda ningún exchange en particular. Antes de tomar una decisión financiera, comprueba el estado más reciente de los retiros, los informes de reservas, la disponibilidad en tu región, las comisiones y los riesgos de custodia.

Cómo comprar criptomonedas en Toobit

Para comprar criptomonedas en Toobit, crea una cuenta o inicia sesión, completa la verificación de identidad cuando sea necesario y abre la página Comprar criptomonedas. Selecciona la criptomoneda que quieres recibir, elige un método de pago disponible e introduce el importe de la compra.

Antes de confirmar la transacción, revisa el tipo de cambio indicado, las comisiones de pago, los límites de compra y el importe final que recibirás. Las divisas admitidas, los métodos de pago, los requisitos de la cuenta y la disponibilidad del producto pueden variar según la ubicación.

Compra criptomonedas en Toobit ahora.

Advertencia de riesgo

Los criptoactivos son muy volátiles y pueden perder una parte sustancial de su valor. Operar y mantener criptomonedas conlleva riesgos, incluidas pérdidas de mercado, incidentes de seguridad e interrupciones que pueden afectar al acceso a los fondos. La Prueba de Reservas y los fondos de protección pueden ofrecer transparencia y protección adicionales, pero no eliminan el riesgo. Las operaciones con apalancamiento conllevan un riesgo adicional y pueden provocar pérdidas rápidas o una liquidación. Ten siempre en cuenta tu situación financiera y tu tolerancia al riesgo antes de operar.