MANTRA Chain evitó comprometerse con un plan de recuperación de fondos en el informe completo del incidente que publicó el 28 de agosto. La publicación presentó en cambio un repaso formal de lo ocurrido el 20 y 21 de agosto, cuando un atacante drenó aproximadamente 720,9 millones de MANTRA, con un valor de unos 3,6 millones de dólares, del proyecto.

La divulgación asignó formalmente un valor en dólares al ataque de una semana de antigüedad, que el proyecto insiste en que fue causado por una falla de código no relacionada directamente con su propio código. MANTRA confirmó que las autoridades ya están involucradas y que habrá novedades sobre los esfuerzos de recuperación de fondos. El proyecto también señaló que actualizará sus cifras de oferta circulante cuando tenga un panorama más claro de los tokens atrapados en las billeteras del hacker y de la posibilidad de recuperarlos.

¿Qué causó el exploit de MANTRA?

Según el análisis posterior de MANTRA Chain, el exploit se originó en el módulo compartido cosmos/evm que la cadena utiliza para ejecutar contratos de estilo Ethereum sobre el Cosmos SDK.

La versión afectada no verificaba que una cuenta pudiera cubrir una llamada antes de aprobar sustracciones del saldo de esa cuenta. Las sustracciones seguían ejecutándose porque el código utilizaba enteros sin signo, que no pueden descender de cero. En lugar de ello, el valor se desbordaba hacia un número enorme.

Este modo de falla, conocido como subdesbordamiento de enteros o wraparound, es una clase de error reconocida desde hace tiempo en el código de blockchain. En el ecosistema Ethereum, un desbordamiento aritmético similar en el contrato ERC-20 del token Beauty Chain (BEC) en 2018 permitió a un atacante generar saldos enormes de tokens, y estos incidentes fueron una motivación clave para la aritmética verificada que Solidity 0.8+ habilita por defecto. El caso de MANTRA muestra que la misma clase de falla puede surgir en los módulos tipo puente que las cadenas basadas en Cosmos SDK usan para interoperar con contratos de estilo Ethereum.

MANTRA aclaró que no se comprometió ninguna de sus claves de validadores, controles de gobernanza ni firmantes multisig, e insistió en que la falla que el atacante explotó no provenía de su propio código. MANTRA escribió que "The attacker required no privileged access" (el atacante no necesitó acceso privilegiado), señalando que un contrato desplegado sin permisos y una billetera autofinanciada fueron suficientes para llevar a cabo el ataque.

¿Cuánto perdió MANTRA?

Según MANTRA, el atacante extrajo unos 600 millones de MANTRA de su burn address (dirección de quema) y otros 120,9 millones de tokens de un multisig inactivo de la era génesis vinculado a una antigua campaña de incentivos.

MANTRA subrayó el matiz técnico del impacto del ataque, insistiendo en que no se acuñaron tokens nuevos. En cambio, el exploit liberó aproximadamente 720,9 millones de tokens que estaban fuera de la oferta circulante y se consideraban económicamente inertes, devolviéndolos a circulación.

El informe también señaló la cadencia programática de los movimientos de tokens, ya que las transacciones parecían ejecutarse en tamaños fijos y a intervalos cortos, en lugar de procesarse manualmente.

MANTRA no detectó las transacciones en tiempo real

Por su propia admisión, el equipo de MANTRA no detectó ninguna transacción maliciosa durante las primeras cuatro horas de la brecha. El proyecto atribuyó la omisión a la falta de monitoreo continuo de una dirección de quema que debía contener tokens inamovibles. Esta brecha es habitual en los análisis posteriores de la industria, donde las direcciones de quema y las billeteras de tesorería suelen tratarse como inertes y vigilarse menos que las billeteras calientes activas, aunque a menudo albergan algunos de los mayores saldos de un protocolo.

En las horas previas a que el equipo notara las señales de alerta, el atacante ejecutó dos transacciones y trasladó la mayor parte del botín fuera de la cadena antes de que los validadores detuvieran la red a las 23:13 UTC, 14 minutos después del segundo drenaje. La billetera del atacante aún contenía 37,96 millones de tokens cuando la cadena se detuvo.

La red permaneció fuera de línea durante 30 horas y 13 minutos, hasta las 05:26 UTC del 22 de agosto, cuando los validadores coordinaron un reinicio con la versión corregida v8.4.0.

El episodio culmina 18 meses dramáticos para un proyecto que aún intenta reconstruir la confianza. El antiguo token OM de MANTRA se desplomó más del 90% en una sola sesión de abril de 2025, borrando más de 5.000 millones de dólares en valor, como informó Cryptopolitan en su momento. Incluso Inveniam Capital Partners, que invirtió 20 millones de dólares en MANTRA en 2025, reconoció los problemas pasados cuando acordó en junio adquirir el proyecto.

Cuando se produjo la detención, el token cayó un 18,5% hasta un mínimo histórico cercano a 0,004126 dólares antes de recuperarse, según datos de CoinGecko. Con las autoridades ya involucradas y las perspectivas de recuperación sin resolver, las preguntas pendientes para quienes siguen a MANTRA son el destino de los 37,96 millones de tokens que aún permanecían en la billetera del atacante al detenerse la cadena, si la administración respaldada por Inveniam ajusta las divulgaciones de oferta y con qué rapidez se lanzan las próximas actualizaciones de módulos programadas del proyecto.