La red principal permanecía detenida en el bloque 17.449.398. Según la actualización de estado de MANTRA, el equipo tomó una instantánea completa del estado de la cadena antes de detenerla, con el objetivo de conservar la información necesaria para las tareas de reparación y recuperación.

¿Cómo afectó el incidente al token MANTRA?

La interrupción golpeó rápidamente al token nativo de MANTRA. Los datos de mercado citados mostraron una caída aproximada del 18,5%, desde unos 0,005060 dólares hasta un mínimo intradía cercano a 0,004126 dólares. Al mismo tiempo, el volumen de negociación aumentó casi un 600%, hasta alrededor de 24 millones de dólares, una señal de la intensa actividad de los operadores tras conocerse el exploit y la pérdida de funcionalidad de la red.

La caída se produjo aunque, en algunos casos, la compraventa en plataformas centralizadas continuó activa. Sin embargo, con la red de MANTRA desconectada, las transferencias en cadena y los depósitos y retiros desde los exchanges quedaron suspendidos o restringidos. En la práctica, esto separó la posibilidad de negociar el activo de la capacidad de moverlo a través de la blockchain.

¿Cuántas carteras fueron afectadas y qué dijo MANTRA sobre los fondos?

MANTRA afirmó que el exploit afectó a dos direcciones de cartera antes de que el equipo lograra contenerlo. El proyecto también aseguró que no se vieron afectados directamente fondos de usuarios, exchanges o socios externos.

No obstante, esa afirmación representa la evaluación comunicada por el proyecto durante el incidente, no el resultado de una auditoría independiente ya concluida. La diferencia es importante: decir que los fondos de usuarios estaban a salvo refleja lo reportado por MANTRA, mientras que un informe posterior y una revisión externa deberían ofrecer una explicación más completa de la vía de ataque, los activos implicados y los controles que fallaron o funcionaron.

¿Qué medidas tomó el equipo para contener la amenaza?

La respuesta se centró en impedir que siguiera moviéndose valor mientras los investigadores aislaban la vulnerabilidad. MANTRA:

• pausó los validadores y los puntos de acceso RPC públicos;
• congeló las transacciones y el resto de la actividad de la cadena;
• suspendió las operaciones de los puentes, así como los depósitos y retiros en exchanges; y
• tomó una instantánea completa del estado de la red antes de detenerla.

Después, el equipo identificó la causa raíz, revisó los vectores de ataque conocidos y preparó la versión v8.4.0, un lanzamiento con parches destinado a corregir la vulnerabilidad de Cosmos EVM. La actualización se probó mediante un ensayo en la red de pruebas DuKong, mientras la red principal seguía fuera de línea a la espera de las revisiones finales de seguridad.

¿Cómo debía funcionar el reinicio?

El plan de MANTRA contemplaba un reinicio coordinado de los validadores, en lugar de que cada operador volviera a poner su nodo en línea por separado. Los validadores recibieron instrucciones de seguir el procedimiento oficial de actualización y esperar al upgrade programado de la red principal. El proyecto dijo que las pruebas del reinicio habían sido satisfactorias, aunque la cadena todavía esperaba las comprobaciones finales de seguridad y la preparación coordinada de los validadores en la última actualización disponible.

La secuencia es especialmente relevante en una red de prueba de participación que ha sido detenida: volver a activar los nodos antes de completar el parche, la validación y la coordinación podría reintroducir la vulnerabilidad o generar un estado inconsistente de la cadena. Por eso, las actualizaciones condicionaron la recuperación a la reparación y a las revisiones, no simplemente a reanudar la producción de bloques.

Por qué los usuarios deben desconfiar de las estafas de recuperación

Una caída de la red crea un terreno fértil para los suplantadores, que pueden contactar a los titulares con instrucciones falsas de recuperación. Los mensajes no solicitados que pidan una frase semilla, una clave privada, la “validación” de una cartera o el envío de fondos a una dirección de recuperación deben considerarse sospechosos.

Un reinicio legítimo de la red no debería exigir que el usuario revele sus credenciales de cartera ni que envíe activos a una dirección controlada por un supuesto representante de soporte. La opción más segura es consultar las actualizaciones oficiales de estado de MANTRA y sus instrucciones verificadas, en lugar de seguir enlaces o mensajes directos recibidos durante la interrupción.

¿Cómo encaja el parón en el historial reciente de MANTRA?

El incidente llegó en un momento delicado para el proyecto. En abril de 2025, el antiguo token OM sufrió un desplome superior al 90%, al pasar de aproximadamente 6,30 dólares a menos de 0,50 dólares, según los reportes publicados en ese momento. MANTRA atribuyó aquel episodio a liquidaciones forzadas en exchanges, aunque otros observadores cuestionaron esa explicación.

Más tarde, el proyecto pasó de OM a MANTRA mediante una división de tokens de 1:4 sin efecto dilutivo en el bloque 13.000.000: cada OM se convirtió en cuatro tokens MANTRA y la oferta total aumentó proporcionalmente.

Inveniam Capital Partners también anunció planes para adquirir MANTRA y sus entidades afiliadas, con la intención de combinar la infraestructura de datos para mercados privados de Inveniam con la infraestructura regulada de blockchain y activos tokenizados de MANTRA. Ese contexto corporativo no modificó el problema técnico inmediato: la atención del mercado se concentró en si la red parcheada podía reiniciarse de forma segura y en cuándo volverían a habilitarse las transferencias desde y hacia los exchanges.

Qué vigilaba el mercado a continuación

Las señales clave eran claras:

1. Un reinicio seguro de la red principal: la versión v8.4.0 debía superar la revisión final de seguridad y desplegarse mediante el proceso coordinado de validadores.
2. La recuperación de la operativa en exchanges: los depósitos y retiros debían reanudarse una vez que la cadena fuera considerada segura.
3. Un informe técnico detallado: usuarios y mercados necesitaban una explicación clara de la vía del exploit, las dos direcciones afectadas, las medidas correctivas y los controles previstos para evitar una repetición.

Hasta que se cumplieran esos hitos, el riesgo principal no era la volatilidad habitual del token. Era la fiabilidad de la propia red y la capacidad de MANTRA para recuperar tanto sus operaciones como la confianza después de otra prueba importante para su seguridad y credibilidad.

La red principal permanecía detenida en el bloque 17.449.398. Según la actualización de estado de MANTRA, el equipo tomó una instantánea completa del estado de la cadena antes de detenerla, con el objetivo de conservar la información necesaria para las tareas de reparación y recuperación.

¿Cómo afectó el incidente al token MANTRA?

La interrupción golpeó rápidamente al token nativo de MANTRA. Los datos de mercado citados mostraron una caída aproximada del 18,5%, desde unos 0,005060 dólares hasta un mínimo intradía cercano a 0,004126 dólares. Al mismo tiempo, el volumen de negociación aumentó casi un 600%, hasta alrededor de 24 millones de dólares, una señal de la intensa actividad de los operadores tras conocerse el exploit y la pérdida de funcionalidad de la red.

La caída se produjo aunque, en algunos casos, la compraventa en plataformas centralizadas continuó activa. Sin embargo, con la red de MANTRA desconectada, las transferencias en cadena y los depósitos y retiros desde los exchanges quedaron suspendidos o restringidos. En la práctica, esto separó la posibilidad de negociar el activo de la capacidad de moverlo a través de la blockchain.

¿Cuántas carteras fueron afectadas y qué dijo MANTRA sobre los fondos?

MANTRA afirmó que el exploit afectó a dos direcciones de cartera antes de que el equipo lograra contenerlo. El proyecto también aseguró que no se vieron afectados directamente fondos de usuarios, exchanges o socios externos.

No obstante, esa afirmación representa la evaluación comunicada por el proyecto durante el incidente, no el resultado de una auditoría independiente ya concluida. La diferencia es importante: decir que los fondos de usuarios estaban a salvo refleja lo reportado por MANTRA, mientras que un informe posterior y una revisión externa deberían ofrecer una explicación más completa de la vía de ataque, los activos implicados y los controles que fallaron o funcionaron.

¿Qué medidas tomó el equipo para contener la amenaza?

La respuesta se centró en impedir que siguiera moviéndose valor mientras los investigadores aislaban la vulnerabilidad. MANTRA:

• pausó los validadores y los puntos de acceso RPC públicos;
• congeló las transacciones y el resto de la actividad de la cadena;
• suspendió las operaciones de los puentes, así como los depósitos y retiros en exchanges; y
• tomó una instantánea completa del estado de la red antes de detenerla.

Después, el equipo identificó la causa raíz, revisó los vectores de ataque conocidos y preparó la versión v8.4.0, un lanzamiento con parches destinado a corregir la vulnerabilidad de Cosmos EVM. La actualización se probó mediante un ensayo en la red de pruebas DuKong, mientras la red principal seguía fuera de línea a la espera de las revisiones finales de seguridad.

¿Cómo debía funcionar el reinicio?

El plan de MANTRA contemplaba un reinicio coordinado de los validadores, en lugar de que cada operador volviera a poner su nodo en línea por separado. Los validadores recibieron instrucciones de seguir el procedimiento oficial de actualización y esperar al upgrade programado de la red principal. El proyecto dijo que las pruebas del reinicio habían sido satisfactorias, aunque la cadena todavía esperaba las comprobaciones finales de seguridad y la preparación coordinada de los validadores en la última actualización disponible.

La secuencia es especialmente relevante en una red de prueba de participación que ha sido detenida: volver a activar los nodos antes de completar el parche, la validación y la coordinación podría reintroducir la vulnerabilidad o generar un estado inconsistente de la cadena. Por eso, las actualizaciones condicionaron la recuperación a la reparación y a las revisiones, no simplemente a reanudar la producción de bloques.

Por qué los usuarios deben desconfiar de las estafas de recuperación

Una caída de la red crea un terreno fértil para los suplantadores, que pueden contactar a los titulares con instrucciones falsas de recuperación. Los mensajes no solicitados que pidan una frase semilla, una clave privada, la “validación” de una cartera o el envío de fondos a una dirección de recuperación deben considerarse sospechosos.

Un reinicio legítimo de la red no debería exigir que el usuario revele sus credenciales de cartera ni que envíe activos a una dirección controlada por un supuesto representante de soporte. La opción más segura es consultar las actualizaciones oficiales de estado de MANTRA y sus instrucciones verificadas, en lugar de seguir enlaces o mensajes directos recibidos durante la interrupción.

¿Cómo encaja el parón en el historial reciente de MANTRA?

El incidente llegó en un momento delicado para el proyecto. En abril de 2025, el antiguo token OM sufrió un desplome superior al 90%, al pasar de aproximadamente 6,30 dólares a menos de 0,50 dólares, según los reportes publicados en ese momento. MANTRA atribuyó aquel episodio a liquidaciones forzadas en exchanges, aunque otros observadores cuestionaron esa explicación.

Más tarde, el proyecto pasó de OM a MANTRA mediante una división de tokens de 1:4 sin efecto dilutivo en el bloque 13.000.000: cada OM se convirtió en cuatro tokens MANTRA y la oferta total aumentó proporcionalmente.

Inveniam Capital Partners también anunció planes para adquirir MANTRA y sus entidades afiliadas, con la intención de combinar la infraestructura de datos para mercados privados de Inveniam con la infraestructura regulada de blockchain y activos tokenizados de MANTRA. Ese contexto corporativo no modificó el problema técnico inmediato: la atención del mercado se concentró en si la red parcheada podía reiniciarse de forma segura y en cuándo volverían a habilitarse las transferencias desde y hacia los exchanges.

Qué vigilaba el mercado a continuación

Las señales clave eran claras:

1. Un reinicio seguro de la red principal: la versión v8.4.0 debía superar la revisión final de seguridad y desplegarse mediante el proceso coordinado de validadores.
2. La recuperación de la operativa en exchanges: los depósitos y retiros debían reanudarse una vez que la cadena fuera considerada segura.
3. Un informe técnico detallado: usuarios y mercados necesitaban una explicación clara de la vía del exploit, las dos direcciones afectadas, las medidas correctivas y los controles previstos para evitar una repetición.

Hasta que se cumplieran esos hitos, el riesgo principal no era la volatilidad habitual del token. Era la fiabilidad de la propia red y la capacidad de MANTRA para recuperar tanto sus operaciones como la confianza después de otra prueba importante para su seguridad y credibilidad.