MANTRA-post-mortem wijst exploit van $3,6 miljoen toe aan integerbug in cosmos/evm
Belangrijkste punten
- •Een aanvaller ontvreemdde tijdens het incident van 20-21 augustus ongeveer 720,9 miljoen MANTRA-tokens ter waarde van zo'n $3,6 miljoen.
- •De exploit ontstond door een integer-underflowfout in het gedeelde cosmos/evm-module dat saldi niet controleerde voordat er van werd afgetrokken.
- •De aanvaller gebruikte een zonder toestemming ingezet contract en een zelf gefinancierde portefeuille, had geen bevoorrechte toegang nodig, en er werden geen validatorsleutels of governance-controles gecompromitteerd.
- •Het MANTRA-team miste de verdachte transacties de eerste vier uur omdat het burn-adres geen monitoring vierentwintig uur per dag had.
- •De politie is betrokken, het netwerk lag 30 uur en 13 minuten stil voordat het herstartte op de gepatchte v8.4.0-release, en de portefeuille van de aanvaller bevatte bij het stilleggen nog 37,96 miljoen tokens.

MANTRA Chain heeft in het volledige incidentpost-mortem dat het op 28 augustus publiceerde nagelaten om zich te committeren aan een plan voor het herstel van fondsen. De publicatie bood in plaats daarvan een formele terugblik op het incident van 20-21 augustus, waarbij een aanvaller ongeveer 720,9 miljoen MANTRA ter waarde van zo'n $3,6 miljoen uit het project ontvreemdde.
De onthulling kende formeel een dollarwaarde toe aan de aanval van een week oud, die volgens het project werd veroorzaakt door een programmeerfout die niet direct verband hield met eigen code. MANTRA bevestigde dat de politie nu betrokken is en dat updates over de pogingen tot fondsherstel volgen. Het project zei ook de circulerende voorraad bij te werken zodra er een helderder beeld is van de tokens die vastzitten in portefeuilles van de hacker en van de mogelijkheden tot herstel.
Wat veroorzaakte de MANTRA-exploit?
Volgens het MANTRA Chain-post-mortem ontstond de exploit in het gedeelde cosmos/evm-module dat de keten gebruikt om Ethereum-stijl contracten boven op de Cosmos SDK te draaien.
De getroffen versie controleerde niet of een account een aanroep kon dekken voordat het aftrekkingen van het saldo van dat account goedkeurde. De aftrekkingen bleven doorgaan omdat de code unsigned integers gebruikte, die niet onder nul kunnen komen. In plaats daarvan sloeg de waarde om naar een enorm getal.
Deze foutmodus, bekend als integer underflow of wraparound, is een allang erkende klasse van bugs in blockchaincode. In het Ethereum-ecosysteem liet een vergelijkbare rekenkundige overflow in 2018 in het ERC-20-contract achter de Beauty Chain (BEC)-token een aanvaller enorme tokensaldi genereren; dergelijke incidenten waren een belangrijke aanleiding voor de checked arithmetic die Solidity 0.8+ standaard inschakelt. Het geval van MANTRA laat zien dat dezelfde klasse van fouten kan optreden in de brugachtige modules die Cosmos-SDK-ketens gebruiken om met Ethereum-stijl contracten samen te werken.
MANTRA verduidelijkte dat geen van de validatorsleutels, governance-controles of multisig-ondertekenaars waren gecompromitteerd, en hield vol dat de fout die de aanvaller benutte niet van eigen bodem kwam. MANTRA schreef dat "The attacker required no privileged access", waarbij het opmerkte dat een zonder toestemming ingezette contract en een zelf gefinancierde portefeuille voldoende waren om de aanval uit te voeren.
Hoeveel verloor MANTRA?
Volgens MANTRA haalde de aanvaller ongeveer 600 miljoen MANTRA uit het burn-adres en nog eens 120,9 miljoen tokens uit een sluimerende multisig uit de genesis-periode die gekoppeld was aan een oude incentivecampagne.
MANTRA benadrukte het technische karakter van de impact van de aanval en hield vol dat er geen nieuwe tokens waren gemint. In plaats daarvan bracht de exploit ongeveer 720,9 miljoen tokens, die buiten de circulerende voorraad lagen en als economisch inactief golden, opnieuw in omloop.
Het rapport wees ook op het programmatische patroon van de tokenverplaatsingen: transacties leken zich in vaste omvang op korte tussenpozen af te spelen in plaats van handmatig te worden verwerkt.
MANTRA miste de transacties in realtime
Na eigen bekentenis van het MANTRA-team werden er in de eerste vier uur van het incident geen verdachte transacties opgemerkt. Het project schreef het misser toe aan het ontbreken van monitoring van het burn-adres vierentwintig uur per dag, terwijl dat adres juist onroerbare tokens moest vasthouden. Dit soort gat komt vaker voor in post-mortems in de sector, waar burn-adressen en treasury-portefeuilles vaak als inactief worden beschouwd en minder nauwlettend worden gevolgd dan actieve hot wallets, ook al bevatten ze vaak enkele van de grootste saldi van een protocol.
In de uren voordat het team de alarmsignalen opmerkte, voerde de aanvaller twee transacties uit en verplaatste het grootste deel van de buit off-chain, voordat validators het netwerk stillegden om 23:13 UTC, 14 minuten na de tweede afvoer. De portefeuille van de aanvaller bevatte bij het stilleggen van de keten nog 37,96 miljoen tokens.
Het netwerk bleef 30 uur en 13 minuten offline tot 05:26 UTC op 22 augustus, toen validators in samenwerking een herstart uitvoerden op de gepatchte v8.4.0-release.
De episode vormt het sluitstuk van een dramatische 18 maanden voor een project dat nog steeds probeert het vertrouwen te herstellen. De voormalige OM-token van MANTRA zakte in één sessie in april 2025 met meer dan 90% en wiste meer dan $5 miljard aan waarde uit, zoals Cryptopolitan destijds berichtte. Zelfs Inveniam Capital Partners, dat in 2025 $20 miljoen in MANTRA stak, erkende eerdere problemen toen het in juni toestemde het project over te nemen.
Toen de stillegging aanvankelijk plaatsvond, zakte de token 18,5% naar een recordlaagte van rond $0,004126 voordat deze herstelde, volgens gegevens van CoinGecko. Nu de politie betrokken is en de herstelvooruitzichten onopgelost blijven, zijn de openstaande vragen voor MANTRA-waarnemers het lot van de 37,96 miljoen tokens die bij het stilleggen nog in de portefeuille van de aanvaller zaten, of het door Inveniam ondersteunde management de voorraadopenbaarmakingen bijstelt, en hoe snel de volgende geplande module-updates van het project verschijnen.