TAC Exploit Results in Major Losses Following Cosmos EVM Vulnerability Chain
Just two days after MANTRA demonstrated that halting a chain could contain the fallout from an attack, TAC experienced a similar exploit, but their response came too late to stem the losses.
On August 22, a threat actor capitalized on the same Cosmos EVM vulnerabilities that previously struck MANTRA, with 2,985,651,403.40 TAC siphoned from what Rarma identified as the network’s bonded-token pool.

Cosmos Labs subsequently verified the link between the incidents. Within just 95 seconds, the majority of the stolen tokens were bridged to BNB Chain.
TAC’s chain was paused at 23:58:11 UTC, over four hours after the exploit was initiated at 19:46:37 UTC.
By that point, most of the assets were already on another network, outside the scope of TAC’s validators.
SlowMist estimated the value of the loss at around $7.5 million.
The same security issue, the same ecosystem, two days apart—but with very different outcomes.
TAC attributed the root error to external code, clarifying that no new tokens were minted, and said it was cooperating with security specialists and exchanges to trace the outflow.
As of September 1, TAC had not disclosed whether it anticipated recovering any of the compromised funds.
If a previously effective countermeasure failed the second time, what changed?
Credit: MANTRA, Rarma, Slowmist, TAC, Daniele Berardinelli, Kiichain, Oraichain, Nesa, Arkham
TAC issued its first public comment on the day the exploit occurred, providing minimal details. The team stated an investigation was underway into a Cosmos EVM vulnerability affecting TAC supply only, and that a temporary chain halt with validators was imminent.
No perpetrator was named, nor was the specific exploit pathway or amount involved mentioned.
The chain stoppage was executed at block 24,671,475.
TAC then remained silent for approximately 36 hours.
Their next update arrived early on August 24, selectively clarifying: It was a drain, not a mint; 2,985,651,403 TAC left a single account; and the vulnerability was blamed on code outside TAC’s control.
A post-incident analysis and relaunch strategy were promised for the following day.
Neither was published on time. TAC provided a later rationale for the delay, but not immediately.
Instead, later on August 24, Rarma released an independent forensic analysis that filled in many gaps left by TAC’s official statements.
Rarma detailed the contract call, specified which pool was drained, and measured the bridge-out time at 95 seconds—information absent from TAC’s communications.
It was an external researcher who first outlined the transaction-level details, before TAC provided its own technical breakdown.
When protocol teams leave critical explanations to outside parties, whose narrative guides community understanding?
Not Unique to TAC
TAC’s total supply was static on August 22. The exploit, which affected about 28% of the supply, originated from a vulnerability in code not maintained by TAC.
The vulnerability traces to the shared cosmos/evm repository.
A patch titled “Guard StateDB balance subtraction against underflow” was submitted on May 13 and merged two days later.
Daniele Berardinelli, an independent researcher, posted a July walkthrough of the underflow problem, noting it had already been reported via HackerOne.
Backporting to production release branches only began August 13, through PR #1253 and PR #1254, both merged August 19.
Release notes for v0.7.2 mentioned only “important security fixes”.
On August 22, KiiChain, victim to the same bug family, provided a detailed technical analysis of the issue.
Cosmos Labs has since released a comprehensive postmortem confirming TAC was targeted using the same vulnerability sequence as MANTRA, while TAC has not yet published its own technical account.
TAC has not independently confirmed these details.
What TAC has acknowledged: The vulnerability is in code they do not own, and the attacker withdrew funds from a single account.
The transactional breakdown comes from Rarma’s analysis.
TAC has not supplied its own incident report, though Cosmos Labs has confirmed the chain of events matched MANTRA's exploit.
A MsgCreateVestingAccount operation sent one utac to a contract managed by the attacker, used only once in TAC’s chain history, seven seconds ahead of the theft.
That vesting account then delegated one wei via the staking precompile, echoing the underflow trigger described in KiiChain’s report](https://x.com/KiiChainio/article/2091721027583709214).
Cosmos Labs’ postmortem confirmed that the underflow was only the first component of the exploit.
The attacker next transferred the inflated balance, approximately 2^256 tokens, to a victim account, such as a multisig or the zero address.
This caused a secondary overflow: the victim’s balance was reset to zero, while the attacker acquired the prior balance.
The attack was neutral in terms of net supply, but the attacker ended up with actual tokens from the victim’s account.
Cosmos Labs’ report lays out this two-step process.
Rarma observed a key difference: while MANTRA’s exploit had a hardcoded victim address, TAC’s version accepted victim and beneficiary parameters via calldata, making it more flexible.
This refinement indicates the exploit was adapted for broader use.
No change in total supply was observed. Across 4,976 blocks before the halt, supply remained constant, with mints and burns perfectly offset.
The breakdown occurred in staking: Rarma noted validator records still claimed 2,985,651,403 TAC as bonded.
But the pool meant to collateralize that amount was empty, exposing a full on-chain deficit.
If the vulnerability existed in shared code and the affected pool remains unnamed by TAC, how reassuring is the claim that this was “not TAC-specific”?
Distribution of Stolen Assets
The sequence of the exploit and subsequent cross-chain transfers is traceable via TAC’s explorer: The drain itself, then two major bridge transactions, one moving about 500 million TAC and the other 2.486 billion TAC, both routed from TAC Chain to BNB Chain via LayerZero.
Together, these account for nearly the entire amount Rarma identified leaving the bonded pool.
Exploit Transaction: 0xae4e9b708ecef134a18aef8a1da9b4d24aa2a0e87f98d02695beae588cda46fc
Bridge Transfer 1 (500M TAC): 0xa0581dbd3bd988ae28b7f397f83623d11b1870c05230e2dc04f27c9e581174c4
Bridge Transfer 2 (2.486B TAC): 0xce24d86fe536b5e04616795aa5cb923e5d3f7e2305be61c2ecdfd9c904b89e7c
Bridge Transfer 3 (49.9M TAC to TON): 0xe7ec92b8a6c19d94863e6c4bf3ad49428006e50549dd5387665f665be077b2d7
Attacker TAC Chain Address: 0xecb0af97644d2c28c58369c663007a1b77c77c84
Same Address on BNB Chain: 0xecb0af97644d2c28c58369c663007a1b77c77c84
TAC’s August 24 statement noted only that they are “working with SEAL 911 and exchanges to address the outflows.”
No further information on asset movement since then has been publicly provided.
An August 26 update, explaining the awaited postmortem was delayed per Cosmos Labs’ request, gave no new information on wallet freezes, possible bounties, or any recovery estimates.
By the time Rarma completed a 25-hour trace, the stolen tokens had not been swapped, mixed, or sent to exchanges. The same address that received the assets on TAC Chain held them openly on BNB Chain.
Cosmos Labs’ August 28 postmortem provides the most detailed public recount: About 1.2085 billion TAC were swapped for around 950,293 USDT across nearly 80 transactions on BNB Chain.
Further movements included 115 million TAC bridged back to TAC Chain (with 65.1 million currently frozen in the attacker’s wallet), and about 49.9 million TAC sent to TON and liquidated.
As of publication, roughly 1.662 billion TAC remained unsold on BNB Chain.
Cosmos Labs indicated that exchange accounts used by the attacker have been frozen pending further investigation.
TAC has not revealed whether any of the stolen funds might be recovered.
This stands in contrast to the MANTRA attack.
MANTRA’s incident was confined to a single chain: No assets crossed bridges, though 94.7% reached exchange deposit addresses before the chain was stopped.
In TAC’s case, the halt occurred after most of the funds were already bridged out. Any future recovery will rely on negotiations, exchange cooperation, or law enforcement, as the chain’s own validators cannot reverse the loss.
TAC has yet to comment publicly on any recovery plan beyond their stated collaboration with SEAL 911 and exchanges.
If nearly three billion tokens moved across a bridge in under two minutes, with over a billion still unsold after a full day, was that strategic, cautious, or simply a lack of alternatives?
Still Awaiting a TAC Postmortem
TAC was neither the first nor last chain affected in this spree.
Rarma’s analysis places TAC within a broader set of coordinated incidents.
Oraichain halted on August 9 following unauthorized ORAI minting through a cross-chain EVM path, a different exploit vector compared to the vesting-account drains that followed.

MANTRA’s disruption occurred August 20. TAC and KiiChain were both compromised on August 22.
Nesa reported an incident on August 24, also tied to the Cosmos EVM stack.
KiiChain lost 148,326,583.15 KII over 18 withdrawals the same day TAC was struck.
Unlike TAC, most stolen KII never left the chain: 54.4% remained in attacker-held wallets, with KiiChain planning to move these tokens to recovery wallets once the chain resumed.
KiiChain published a technical incident report within days, naming the exploit mechanism and identifying the loss as avoidable.
Cosmos Labs’ August 28 postmortem confirmed MANTRA, TAC, and KiiChain were impacted by the same vulnerability chain: An unsigned-integer underflow in Cosmos EVM balance logic, triggered by a crafted vesting account and staking precompile call.
Compared to MANTRA and KiiChain, TAC’s disclosures appear notably limited.
Other affected chains have published detailed technical explanations and loss figures.
TAC has issued only three brief statements and a follow-up explaining its delayed postmortem.
There is at least an upstream cause for this delay. Cosmos Labs publicly acknowledged an “ongoing security incident” on August 24, two days after TAC and KiiChain were attacked.
On August 25, Cosmos Labs advised all chains running affected versions to halt operations immediately, nearly a week after the patched release, which was not accompanied by a public warning.
An August 26 update stated that many chains had been patched, without specifying which networks or the extent of losses.
Cosmos Labs’ postmortem was made public on August 28. TAC’s promised report is still pending.
If two other chains exploited in the same way have already detailed their incidents, what is TAC waiting for before publishing its own account?
A halt only prevents further losses if it is enacted in time.
The main point of failure in this incident traces to a shared codebase.
An integer underflow fix was merged months before making it to a release branch, and was then deployed without an alert that the vulnerability was actively being exploited.
MANTRA acted within 14 minutes of the exploit’s initiation.
KiiChain managed to freeze over half the stolen KII before halting its chain.
TAC’s halt came about four hours after the stolen funds had already been bridged to another network, resulting in a loss estimated at $7.5 million.
TAC’s contemporaries have since provided their communities with detailed postmortems that TAC itself has yet to match.
TAC has told its users that the bug was not specific to TAC, that overall supply is unaffected, and that its postmortem is delayed at Cosmos Labs’ request.
The pool from which the assets were extracted, as identified by outside researchers, has yet to be named or described by TAC.
Cosmos Labs has reported on the movement of the stolen funds, including about 1.66 billion TAC still unsold on BNB Chain, but TAC has not published any own recovery estimate.
If a chain halt works as intended but fails to prevent major losses, what was its actual purpose?
Get new scam files the moment we publish them — usually 2–3 emails a week.