Por qué CZ instó a Bybit a pausar los retiros tras el hackeo de Safe{Wallet} de $1.46 mil millones
Puntos clave
- •Un ataque de phishing en la interfaz de firma de Safe{Wallet} permitió el robo de $1.46 mil millones de la billetera fría multisig de Ethereum de Bybit el 21 de febrero de 2025, el mayor exploit a nivel de exchange registrado.
- •Changpeng Zhao recomendó públicamente que Bybit suspendiera temporalmente los retiros, describiendo la medida como un protocolo de contención de crisis para ganar tiempo y evaluar la exposición, no como una señal de insolvencia.
- •Bybit mantuvo los retiros abiertos y procesó el 99.994% de más de 350,000 solicitudes de retiro en 10 horas, completando todas las solicitudes en menos de 12 horas.
- •La firma de rastreo blockchain TRM Labs informó que al menos $160 millones de los fondos robados se movieron por canales ilícitos en 48 horas, y más de $400 millones fueron movidos para el 26 de febrero.
- •El FBI vinculó el ataque a hackers norcoreanos, y la brecha atrajo nueva atención sobre la capa de interfaz de usuario de las billeteras multisig como vulnerabilidad junto a los contratos inteligentes on-chain.

Changpeng Zhao instó públicamente a Bybit a pausar los retiros el 21 de febrero de 2025, horas después de que un ataque de phishing en la interfaz de Safe{Wallet} drenara $1.46 mil millones de una sola billetera fría multisig de Ethereum, el mayor exploit a nivel de exchange registrado. Su razonamiento fue directo: cuando el alcance de una brecha aún se desconoce, limitar los flujos de salida compra tiempo para evaluar la exposición y evita que un posible contagio agrave una pérdida ya catastrófica.
Qué ocurrió en el hackeo de Bybit
El ataque tuvo como objetivo la billetera fría multisig de Ethereum de Bybit el 21 de febrero de 2025. Según la cronología oficial del incidente publicada por Bybit, un ataque de phishing contra la interfaz de Safe{Wallet} alteró la lógica del contrato inteligente de la billetera, lo que permitió al atacante redirigir una transferencia rutinaria y drenar el saldo completo de la billetera.
La billetera comprometida contenía 401,347 ETH, 90,375 stETH, 15,000 cmETH y 8,000 mETH, con un valor conjunto de $1.46 mil millones al momento del exploit. No se reportó ningún otro fondo de usuarios ni billetera de Bybit comprometida más allá de esa única billetera fría.
Poco después de que se conociera la noticia del exploit, CZ publicó una recomendación para que Bybit suspendiera temporalmente los retiros, presentando la sugerencia como un protocolo estándar de contención de crisis y no como una señal de insolvencia generalizada. CoinDesk informó que CZ también ofreció su asistencia, una señal de que la recomendación provenía de una postura de apoyo a la industria y no de un comentario competitivo. El consejo planteó una de las preguntas centrales del incidente: si un exchange bajo ataque debe detener los flujos de salida o mantenerlos en marcha.
Por qué CZ recomendó pausar los retiros
El fundamento de la contención
La lógica central detrás de una pausa temporal de retiros tras un exploit es la gestión asimétrica de riesgos. En las consecuencias inmediatas de un compromiso de contrato inteligente, rara vez se conoce la superficie de ataque completa: si otras billeteras comparten la misma infraestructura de firma, si hay vectores de phishing adicionales activos o si el atacante conserva algún tipo de acceso privilegiado. Una pausa crea una ventana para auditar la arquitectura de custodia antes de que más fondos salgan del exchange. Bajo esa óptica, la pausa no es un juicio sobre la solvencia, sino herramienta para ganar tiempo de investigación.
La recomendación de CZ reflejó un manual bien establecido en la seguridad de exchanges: primero contener, segundo investigar, tercero reanudar con confianza. Una pérdida de $1.5 mil millones ya es significativa; unos cientos de millones adicionales drenados durante un aumento incontrolado de retiros mientras el equipo de seguridad aún mapea la brecha agrava el daño y reduce las opciones de recuperación. Esa aritmética, según el planteamiento de CZ, es lo que hace que las primeras horas sean las más determinantes.
Bybit optó por mantener los retiros abiertos
Bybit tomó un camino distinto. En lugar de pausar, el exchange mantuvo los retiros abiertos y los procesó a gran escala, gestionando finalmente el 99.994% de más de 350,000 solicitudes de retiro en 10 horas, con todas las solicitudes completadas en menos de 12 horas. Ese rendimiento operativo fue el principal contraargumento de Bybit: demostrar solvencia mediante el desempeño en lugar de afirmaciones.
La tensión entre ambos enfoques es la verdadera lección de gestión de riesgos. Una pausa protege al exchange de vectores de ataque residuales, pero corre el riesgo de desencadenar la dinámica de pánico bancario que busca prevenir; mantener los retiros demuestra solvencia, pero deja al exchange expuesto si la evaluación inicial de la brecha estaba incompleta. Ninguna opción está libre de riesgos, y por eso la decisión depende de la rapidez con que el equipo de seguridad pueda dimensionar el exploit.
Para los usuarios que siguen un incidente activo en un exchange, la señal más confiable es la calidad de las comunicaciones oficiales más que la política de retiros en sí. Los exchanges que divulgan el componente específico comprometido, los pasos de aislamiento tomados y un cronograma para una auditoría de terceros demuestran el tipo de transparencia operativa que reduce la asimetría de información que impulsa la presión de retiros. La detallada cronología del incidente de Bybit es un caso de estudio de ese enfoque.
Los fondos robados se movieron en cuestión de horas
El rastreo blockchain posterior al incidente reforzó la rapidez con la que se mueven los fondos robados una vez que un exploit tiene éxito. TRM Labs informó que al menos $160 millones se habían movido por canales ilícitos dentro de las 48 horas posteriores al exploit, y más de $400 millones habían sido movidos para el 26 de febrero. El FBI vinculó públicamente el ataque a hackers norcoreanos esa misma fecha, en línea con el patrón establecido del Grupo Lazarus de blanqueo rápido entre cadenas diseñado para superar las congelaciones de exchanges y las respuestas de listas negras.
Este ritmo subraya por qué la ventana de contención a la que se refirió CZ se mide en horas, no en días, y por qué pausar los retiros en exchanges que mantienen liquidez de puentes o comparten infraestructura de custodia puede afectar las probabilidades de recuperación en el stack de DeFi también. Las implicaciones en los flujos de exchange del blanqueo rápido a gran escala son un contexto relevante para quien monitorea riesgos on-chain.
Nuevo escrutinio sobre las interfaces de billeteras multisig
El incidente también renovó el escrutinio sobre las interfaces de usuario de las billeteras multisig como superficie de ataque. El vector de phishing de Safe{Wallet} utilizado aquíuntó a la interfaz de firma y no al contrato inteligente subyacente, una distinción importante para las evaluaciones de riesgo de protocolos: la lógica del contrato era sólida, pero la capa orientada al usuario fue comprometida. Los marcos de gobernanza y los estándares de custodia en DeFi necesitan cada vez más considerar los ataques a la capa de interfaz junto con las vulnerabilidades on-chain, una inquietud directamente relevante para cualquier protocolo que dependa de Safe o de una infraestructura multisig similar para la gestión de tesorería. La atención regulatoria sobre estas brechas ya ha sido señalada en los desarrollos regulatorios de cripto más amplios a lo largo de 2025.
En conjunto, el episodio muestra que la política de retiros es un medio y no un fin: sea cual sea el camino que tome un exchange en las primeras horas de una brecha, los factores decisivos son la rapidez con que su equipo de seguridad puede dimensionar el exploit y la claridad con que comunica sus hallazgos. Los indicadores que vale la pena seguir de aquí en adelante son los que marcaron los primeros días del incidente: el movimiento adicional de los fondos robados según lo contabilizan las empresas de rastreo, y las actualizaciones de la cronología oficial del incidente de Bybit.