Este es el tipo de error que mantiene a los equipos de protocolo despiertos por la noche. Un exploit de 5 millones de dólares en ZKSwap, habilitado por una sola declaración dejada en el lugar equivocado. Aquí hay un análisis profundo de cómo sucedió y cómo la monitorización en cadena podría haberlo detenido. 🧵

1/ El 9 de julio, GMX fue hackeado por 42 millones de dólares. Pero algo más sucedió ese día y casi nadie lo notó: el puente de ZKSwap fue drenado silenciosamente por 5 millones de dólares. ¿La parte interesante? No hubo ningún exploit sofisticado involucrado. Solo una función crítica que no hizo... nada.

2/ ZKSwap es un zk-rollup construido sobre Ethereum. Como muchos rollups, utiliza un puente para mover activos entre L1 y L2. Como medida de seguridad, el puente incluye un "Modo Éxodo", una forma para que los usuarios recuperen fondos sin necesidad del operador. En teoría, es una gran idea. En la práctica…

3/ El Modo Exodus permite a los usuarios demostrar manualmente que poseían tokens en el último estado L2 verificado. Es un mecanismo de respaldo: sin confianza, autocustodia, no interactivo. Pero la implementación de ZKSwap tenía un defecto fatal: la función responsable de verificar las pruebas no verificaba nada. Literalmente.

4/ Aquí está el código que debería haber detenido el ataque 👇 A primera vista, parece un verdadero verificador de zk-proof. Pero mira de cerca la primera línea: return true; Eso es todo. No se ejecuta nada más.

5/ ¿El resultado? Cada "prueba" de retiro (sin importar cuán falsa) pasó la validación. El contrato aceptó afirmaciones arbitrarias sobre los saldos de tokens... y los acreditó como si fueran reales. Convirtió un mecanismo de respaldo sin confianza en un grifo desprotegido.

6/ El atacante no necesitaba exploits sofisticados: solo llamadas repetidas a exit() con datos inventados. Eludieron las verificaciones de saldo, retiraron a través de múltiples tokens y abusaron de la lógica débil del anulador para evitar la detección. Todo mientras el contrato decía: ✅

7/ Esto no era un caso extremo y oscuro. Esta era la lógica central para la recuperación de activos, completamente abierta. Y debido a que el Modo Exodus rara vez se activa, el camino roto pasó desapercibido... durante meses.

8/ Aquí está lo que debería haber activado las alarmas: • Modo Exodus activado después de una larga inactividad • Docenas de solicitudes de retiro ocurriendo todas a la vez • Aumento repentino en los cambios de balancesToWithdraw Todo esto era visible y podría haberse detenido con un monitoreo en cadena en tiempo real.

9/ ¿Entonces, cuál es la lección? • El código de emergencia sigue siendo código de producción • Los caminos de respaldo no ayudan si no funcionan • La monitorización en tiempo real no es opcional, es crítica para la supervivencia