Puntos clave de la noticia:
- Zano afirma que un atacante explotó Gateway Addresses para acuñar 36,9 millones de ZANO y 1,8 cuatrillones de fUSD antes de un rollback mensual.
- El atacante creó 18,4 millones de ZANO el 29 de agosto, repitió el exploit el 25 de septiembre y después generó la supply de fUSD.
- Solo una pequeña parte llegó al mercado, mientras Zano intenta restaurar balances mediante fondos de desarrollo, aportes y coordinación con exchanges.
Zano reveló la magnitud del exploit de Gateway Address que obligó al proyecto a borrar un mes de historial. En una actualización oficial, el equipo dijo que el atacante creó 36,9 millones de ZANO no autorizados y 1,8 cuatrillones de fUSD, un activo Freedom Dollar emitido sobre la red de privacidad. Los activos acuñados se comportaban como monedas legítimas, haciendo imposible eliminarlos selectivamente una vez incorporados al ledger. Eso explica por qué los desarrolladores recurrieron a un rollback pese al impacto sobre transacciones legítimas.
— Zano (@zano_project) October 1, 2026
El exploit de Gateway Address pasó casi un mes sin ser detectado
El exploit comenzó el 29 de agosto, un día después de que el atacante registrara una Gateway Address y pagara 100 ZANO. Una primera transacción creó unos 18,4 millones de ZANO, seguida por otros 18,4 millones el 25 de septiembre y después por la enorme emisión de fUSD. La primera emisión no autorizada permaneció sin detectar casi un mes, lo que explica por qué el rollback de Zano retrocedió hasta el periodo anterior al Hard Fork 6.
Zano indicó que los outputs falsificados eran indistinguibles de ZANO ordinarios y podían gastarse. Eso impedía invalidar solo las monedas del atacante sin modificar historial válido. Según la información publicada, una pequeña fracción llegó al mercado porque la liquidez en exchanges limitó cuánto podía venderse. La diferencia entre la cantidad acuñada y la realmente monetizada es clave, porque la supply no autorizada fue enorme aunque el impacto sobre el mercado resultara mucho menor.
El equipo decidió reiniciar la blockchain desde el bloque 3.833.000, eliminando activos no autorizados y transacciones legítimas del periodo afectado. Las transferencias liquidadas en otras blockchains no pueden revertirse, dejando trabajo de recuperación para exchanges y usuarios. El rollback priorizó restaurar la supply prevista a costa de la finality de las transacciones, un trade-off también presente en emisiones de tokens no autorizadas y recuperaciones de emergencia.
Zano afirmó que tests asistidos por IA, auditorías internas y programas de bug bounty no detectaron la vulnerabilidad antes del exploit. El proyecto trabaja para restaurar balances mediante su fondo de desarrollo, aportes del equipo y contribuciones comprometidas, mientras los exchanges deberían repetir retiros revertidos por el rollback. Corregir la vulnerabilidad técnica es solo una parte de la recuperación, porque deben reconciliarse balances y recuperar la confianza tras intervenir el ledger, un desafío presente en la recuperación posterior a exploits.
