MANTRA Chain Restores Mainnet After Security Halt, Code Changes Raise Questions

MANTRA Chain restored mainnet block production on version 8.4.0 at approximately 05:30 UTC on August 22, six days after a chain‑wide halt triggered by a security incident.

Incident summary

The chain announced that no rollback or state change occurred during the downtime, user balances were unchanged and token holders did not need to take any action. The team marked the incident as resolved on August 24 and said a post‑mortem would be published in the coming days, but no such report was linked on the status page or official announcement channel as of August 27.

Undisclosed details

MANTRA’s public statement noted that the incident affected two MANTRA‑managed wallets and that no user, exchange or partner funds were impacted. However, the announcement did not disclose wallet addresses, transaction hashes, amounts transferred or the technical steps of the exploit.

Code changes during recovery

Node operators are advised to verify the exact build they are running. The release page points to commit 5c08d7bd9e2619952707dae1258d2a30bf024721, and the tag was re‑pushed during the recovery process. The changelog shows an intermediate EVM fork bump from v0.6.0‑v8‑mantra‑3 to v0.6.0‑v8‑mantra‑4, followed by a final go.mod update that replaces a dependency with the chain’s v0.6.2‑v8‑mantra‑1 fork. The final upgrade handler blocklists one address and disables three Cosmos vesting‑account creation messages via a circuit breaker. These modifications constitute the deployed mitigation, but the underlying attack path remains undisclosed.

Relation to prior ICS20 advisory

A March advisory from Cosmos Labs highlighted a critical precompile flaw in the ICS20 module, noting that affected chains had mitigated or upgraded and naming MANTRA among remediation collaborators. The advisory’s timeline ends with the March disclosure, leaving the August incident outside its documented scope.

What remains to be clarified

• Exact wallet addresses and transaction hashes involved.
• Amounts transferred and the specific exploit steps.
• Whether the incident exploited the previously reported ICS20 flaw.

Developers and users can verify the restart, the final code version, and the stated impact, but further transparency is needed to fully assess the incident’s cause and containment.