TAC Mainnet Security Incident

Network: TAC mainnet (tacchain_239-1) · Incident date: August 22, 2026 · Status: network halted, recovery in preparation

‍

About this report

Purpose and status. This report reflects our understanding of the incident as at September 1, 2026. It sets out the sequence of events and the causal links between them as we have established them. It is a factual account. It is not an allegation against any person or organisation, and it is not an admission of liability by any entity. Details of the recovery and of the operational plan may change as the work progresses, within the objectives set out below.

Entities. The TAC network is operated by an independent set of validators. The TAC Foundation holds the treasury reserves referred to in the recovery plan. Other functions within the TAC ecosystem, including development and maintenance of the node software and the bridge contracts, and the issuance of $TAC, are carried out by separate legal entities. References in this report to "TAC" describe the network and its ecosystem collectively. Where this report describes a decision, an obligation, or the use of assets, it does so in respect of the entity responsible for that function, and no statement should be read as the assumption of any liability by any other entity.

A note on how sales are counted. Where this report gives a number of swaps, it counts the swap instructions issued by the attacker, not the individual on-chain events each instruction produced. One instruction may execute as several fills at a venue, and on TON it generates several messages. Analyses that count fills, transfers or actions will therefore report higher numbers for the same activity. The amounts and the proceeds are unaffected, and those are the figures reconciled in this report.

The attacker. References to "the attacker" mean the person or persons who control the on-chain addresses from which the transactions described in this report were sent. Their identity has not been established. Where this report describes an address as associated with the incident, that association is based on on-chain analysis and is not a legal determination.

Forward-looking statements. This report describes the incident and the principles and objectives guiding the recovery. It is published for information, to keep the community and our partners aligned with the recovery plan. Within the principles set out below, timing, sequencing and implementation details may change as technical work and coordination with third parties develop. Nothing in this report creates a contractual entitlement in favour of any holder, delegator, or other person.

‍

Summary

At 19:46:37 UTC on August 22, 2026, a single transaction moved the entire staking bonded pool - the account that holds all $TAC delegated to validators - to an address controlled by an attacker. The amount was 2,985,651,403.40 TAC, approximately 28.6% of the total supply. Following coordination with validators representing a supermajority of voting power, block production was halted at 23:58:11 UTC at block 24,671,475.

This was a drain, not a mint. No new tokens were created. Total supply is unchanged. The staking pool's balance was reduced and the attacker's increased by the same amount.

Only $TAC was affected. All other assets on TAC are intact.

Within 95 seconds of the drain, the full amount was bridged to BNB Chain. Of it, 1,208,329,197 TAC was sold across 55 swaps for 950,293 USDT; 1,662,322,353 TAC remains held on BNB Chain in addresses associated with the attacker; and 115,000,000 TAC was bridged back to TAC, of which 49,900,000 was sent onward to TON and sold for 55,481 USDT, and 65,100,989 remained on TAC and was frozen by the halt. In total the attacker realised approximately 1,005,774 USDT in stablecoins.

The vulnerability is in the shared Cosmos EVM module, not in code specific to TAC. Cosmos Labs has publicly confirmed that a security incident affected users of that module and advised chains in contact with it to halt. According to Cosmos Labs' own post-mortem, at least six networks running the module were exploited through the same chain of defects over several days. What was known to us and when, including a report we sent upstream seven weeks before the incident, is set out in full under "How the vulnerability reached us".

The root cause has been identified, reproduced against the live mainnet binary on an isolated network, and fixed. Replaying the exploit against the patched build causes the transaction to revert, leaving balances and total supply unchanged.

What this means for you

If you staked $TAC. Your delegation is currently unbacked, because the pool holding delegated tokens was emptied. The recovery plan provides for staking balances to be restored to the amounts recorded immediately before the incident. No action is required from you.

If you hold $TAC on TAC. The network is halted. No transfers, transactions, staking or unstaking are possible until validators complete the upgrade and block production resumes. Balances other than the staking pool were not touched by the attack.

If you hold $TAC on BNB Chain. Do not trade it. Bridging between BNB Chain and TAC is disabled in both directions, and work on how these holdings are treated in the recovery is under way. We will announce the outcome separately. There is nothing else you need to do now.

If you hold $TAC on TON or Ethereum. Nothing is required from you. What is described below in respect of BNB Chain concerns the bridged $TAC token there only, and holdings on TON and Ethereum are not affected by it.

If you hold assets other than $TAC on TAC. They are unaffected.

Do you need to contact us? No. There is no claim process, no form to fill in, and nothing to register for.

What we will never do. We will never ask you to connect a wallet, claim tokens on an external site, or send funds in order to receive anything. The only official channels are the TAC account on X and the official TAC Telegram channel. Treat every other channel as fraudulent.

Key figures

¹ The 2,985,651,550 TAC bridged out exceeds the 2,985,651,403.40 taken from the pool by 146.60 TAC. That difference is the balance of the gas the attacker had bridged in beforehand, net of fees.

² Of the 115,000,000 bridged back, 49,900,000 went onward to TON and 65,100,989 remained on TAC, a total of 115,000,989. The 989 TAC difference is funds forwarded from a second address, net of network fees.

Timeline of the attack

All times UTC on August 22, 2026.

Root cause

TAC runs an Ethereum-compatible layer on top of a Cosmos chain. Each account therefore has two records of its balance: one held by the chain itself, and one used by the Ethereum-compatible layer. Three separate defects in the shared Cosmos EVM module had to combine for this attack to work. Two of them were identified by our engineering team and reported upstream in July. The third was not known to us.

1. The wrong balance was used. When a user stakes through the Ethereum-compatible layer, the staking itself happens on the Cosmos-based chain, and the change is then copied across into the Ethereum-compatible layer's record. In the affected versions of the module, that record was always adjusted against the account's spendable balance, even where the chain had in fact staked tokens that were locked under a vesting schedule - tokens that unlock over time and cannot be freely spent before then. Staking a locked token therefore recorded a deduction against a spendable balance of zero.

2. The deduction had no lower limit. The attacker's contract staked such tokens, applying that deduction in the Ethereum-compatible layer's record. Instead of failing, the result rolled over: going below zero continued from near the highest number the system can represent, an integer underflow. The attacker's contract was left holding a balance of approximately 2^256 tokens, created out of nothing and larger than the network's entire supply.

3. The guard on protocol-controlled accounts did not cover this path. In the affected version, the module did have a filter for protocol-controlled accounts, but it sat in the path used when the chain's own modules change a balance. A direct transfer of value inside the Ethereum-compatible layer never reaches that path. At the end of the transaction, the chain mints or burns to bring its own ledger into line with the second layer, and that step applies no such filter. The staking pool's balance could therefore be set to any value, and the real tokens behind it destroyed to match.

Combined, the first two defects gave the attacker's contract a balance it had never been given. That balance was sent to the staking pool as an ordinary transfer, in an amount equal to the maximum minus the pool's own balance, so the pool's balance passed the top of the range and came back to zero. The same transaction moved the pool's former amount to the attacker's address. At commit, the chain burned that amount from the pool and credited the same amount to the attacker, and the two cancelled out. This is why the incident is a drain, not a mint: the transaction changed exactly two balances by the same amount in opposite directions.

None of these defects is reachable from an ordinary wallet, because a normal account cannot spend more than it holds. The attacker worked around that by preparing an account with a vesting schedule in advance and deploying the exploit contract onto it.

Cosmos Labs' advisory describes this chain of defects for the general case, in which the account drained is an ordinary account holding a large balance. The first and second defects set out above are the two halves of the underflow it describes, and the step in which the attacker overflows the victim account's balance is the combination described above. Our third defect has no counterpart in that description: the first two are sufficient on their own to drain an ordinary account, and the absence of a guard on protocol-controlled accounts became relevant only because the account drained here was the staking pool, which is controlled by the protocol rather than by a user. The two descriptions are consistent; ours is narrower, because this incident required a condition the general case does not.

The full technical description is now published upstream. On August 28, Cosmos Labs released advisory GHSA-7g4w-cg88-2cq2 and an accompanying post-mortem setting out the mechanism, the affected versions, and the patched releases.

How the vulnerability reached us

The defect is in shared upstream code. Cosmos Labs has publicly confirmed that a security incident affected users of the Cosmos EVM module, that its teams responded, and that it advised chains in contact with it to halt. This is the sequence as we experienced it.

May 15. As Cosmos Labs has since disclosed, a guard addressing the underflow was merged to the main branch of cosmos/evm, following a bug bounty report assessed at the time as not threatening funds on production networks. It was not backported to the release branches, because a state-breaking change requires a coordinated upgrade across a validator set and is not typically shipped in a patch release. It was therefore not present in any release available to us in June or July.

June 30. We upgraded our stack to cosmos/evm v0.6.0 and immediately found that delegating from a vesting account produced an error.

July 1. Our engineering team traced the error to two defects in the shared module and sent a written analysis directly to a cosmos/evm maintainer. The report was not acknowledged.

July 2. We ported that upstream guard into our own fork. On our assessment of the code path, it would have prevented this attack had it been running on mainnet. On the information available to us at the time, the observable effect of the two defects we had identified was a failed transaction rather than any movement of funds. The change was classified accordingly and scheduled for the September coordinated upgrade, on the same reasoning that had kept it out of the upstream release branches: a state-breaking change alters how every node computes the chain's state, so it can only be deployed at an agreed block height across the entire validator set, in a scheduled upgrade window. It was therefore not running on mainnet on August 22.

August 12. Cosmos Labs sent a confidential advisory to chains running the module. It concerned a different vulnerability. It did not reference the defects we had reported in July, and it did not identify the staking path used against us ten days later. The interim measure it recommended, disabling permissionless ERC20 registration, has been disabled on TAC since launch.

August 14–16. Access to the private patch repository was granted and we began integrating the fix. Chains were asked to roll the remediation out as a compiled binary distributed to validators rather than as publicly visible source changes, to reduce the risk of exploitation while upgrades were in flight. The public patch date was set at 11:00 EST on August 21.

August 19. Patched releases appeared in the public cosmos/evm repository: v0.6.2 at 23:01:27 UTC and v0.7.2 at 23:01:54 UTC. TAC was running the 0.6.x line.

August 20. At 07:16 UTC, as Cosmos Labs later documented, a public pull request in a third-party fork of cosmos/evm described the vulnerability and its exploitation path in detail and identified which released tags remained vulnerable. Twelve hours later, at 19:06 UTC, MANTRA Chain was exploited and halted its mainnet.

August 21. Cosmos Labs notified chains of the releases by secure email at 03:36 UTC and through the shared Slack channel at 09:33 UTC, recommending an upgrade to v0.6.2 or v0.7.2.  

The notification recommended an upgrade to those releases and did not identify the path used against us the following day. On the assessment we made at the time, we did not consider TAC to be exposed to an exploitable vector, and the upgrade was scheduled through our normal coordinated process rather than treated as an emergency. No upgrade was deployed and no halt was carried out before the exploit.  

August 22. TAC was exploited at 19:46 UTC - 40 hours after the first notification from Cosmos Labs, and 68 hours after the patched releases first appeared publicly. A state-breaking upgrade has to be reviewed, built reproducibly, and adopted at a common block height across an independent validator set; that is not achievable on either timescale. KiiChain was exploited hours later. At 23:45 UTC, Cosmos Labs advised chains to halt immediately rather than attempt coordinated upgrades.

August 25. Cosmos Labs publicly acknowledged the incident.

August 28. Cosmos Labs published the advisory and its own post-mortem.

What this sequence shows

A defect in a shared module has to reach every chain running it, in a form each of those chains can act on, faster than an attacker can weaponise it. That did not happen here, for us or for the other networks affected. No single team owns this problem: maintaining infrastructure at this scale means having no reliable contact with many of the operators running it, and an incident is the worst possible moment to establish that contact.

The remedy is procedural rather than attributive. It needs a published escalation path for inbound reports, an acknowledgement guarantee so a reporter knows a finding has been received, and a mechanism to reach every operator at once where severity requires it. Cosmos Labs has committed to all three, and we will support that work.

For a defect of this severity, the fastest protection available to a chain is to stop producing blocks. A patch has to be reviewed, built and rolled out across a validator set; a halt takes minutes. In our view, an explicit halt recommendation reaching every operator simultaneously should be the default first step for incidents of this class. Cosmos Labs reached the same conclusion during the incident and has committed to publishing standards for when that recommendation applies.

Monitoring and detection

Two controls were in place, and both operated as designed. An automated check compares custody held on TAC against the mirrored supply on the BNB Chain and Ethereum legs, and alerting on large bridge transfers was active.

Neither could have prevented this incident. The attacker locked genuine TAC and issued a correctly backed mirror token, so the conservation property being monitored was never broken: a solvency check cannot detect a theft that preserves solvency. And 32 seconds elapsed between the drain and the first bridge transfer. No control that ends in a human decision closes an interval of that length.

Following the May 2026 bridge incident, supply-conservation invariants were implemented. They functioned correctly, but monitor a different conservation property from the one this attack exploited.

What removes this class of attack is not faster detection but the patch described below, which prevents the sequence from executing.  

Impact

Staking. The bonded pool went from 2,985,651,403.40 TAC to zero. Delegations are currently unbacked.

Supply. Total $TAC supply is unchanged. The attacker gained control of existing tokens rather than issuing new ones. No inflation resulted from the incident.

Other assets. The impact was limited to $TAC. No other asset on TAC was affected.

Network. The network has been halted since block 24,671,475. All 7,772 transactions from 218 senders submitted in the four hours preceding the halt have been preserved. Recovery can be performed as a targeted state edit rather than a rollback, and no legitimate transaction will be reversed or removed.

Market. The attacker sold entirely on decentralised exchanges on BNB Chain. Across 55 swaps, the realised price of those sales fell from $0.00231 to $0.00016, a decline of approximately 93% driven principally by the attacker's own selling. A further 1,662,322,353 TAC remains unsold in the attacker's addresses on BNB Chain.

While the bridge remained operational, arbitrage transmitted the decline on BNB Chain decentralised exchanges to centralised venues, which in practice supplied the attacker with continuous exit liquidity. On centralised venues, $TAC traded at $0.002540 before the attack and at $0.001728 by 22:00 UTC. A low of $0.000367 was reached the following afternoon, after the attacker's selling had ended, reflecting the exhaustion of on-chain liquidity. Once the bridge was stopped, the arbitrage channel closed and pricing on decentralised and centralised venues decoupled.

‍

Where the funds went

Native $TAC never leaves the TAC network. Both bridges lock it, and the BNB Chain mirror token and the TON jetton are escrow-backed representations of tokens that remain on TAC.

This total exceeds the 2,985,651,403.40 taken from the pool by 1,135.60 TAC. That difference is the gas the attacker bridged in beforehand together with 1,000 TAC forwarded from the second address, net of bridge and network fees. It did not originate from the staking pool.

Of the cash proceeds, 950,000 USDT was deposited to a centralised exchange across nine addresses between 21:32 and 22:24 UTC, and 55,480 USDT moved through addresses on TON. The difference between these amounts and the 1,005,774 USDT realised remains as residual balances in addresses controlled by the attacker.

The movement of the funds has been reconstructed on-chain in full and reconciled against the amount taken from the pool, with support from SEAL 911 and ICL (Cosmos Labs). Addresses associated with the incident were reported to Elliptic, Chainalysis, AML Bot, Scorechain and Crystal Intelligence for labelling, and the reconstruction has been shared with law enforcement.

A criminal complaint has been filed with law enforcement in the relevant jurisdiction, and a crime reference number has been issued. Formal law-enforcement requests have been submitted through official channels to the centralised exchanges and swap services identified in the traced fund path. We will not comment further on investigative steps while they are in progress.

Response and remediation

What has been done

• Block production was halted at block 24,671,475, following coordination with validators representing a supermajority of voting power.  
• Bridge execution was stopped on every leg: the TAC-to-TON CrossChainLayer at 20:42 UTC, the TAC sequencer at 20:56 UTC, and subsequently the TON-to-TAC direction together with the $TAC OFT adapters on BNB Chain and Ethereum. Bridging $TAC from BNB Chain to TAC is not currently possible for any party, including the attacker.  
• Cross-chain tracing was completed and reconciled on-chain against the amount taken from the pool.  
• Exchanges were notified and suspended $TAC deposits and withdrawals.  
• SEAL 911, Elliptic, Chainalysis, AML Bot, Scorechain and Crystal Intelligence were engaged, and addresses associated with the incident were flagged.  
• The exploit was reproduced against the live mainnet binary on an isolated network, and the fix was verified against that reproduction.  
• A criminal complaint was filed with law enforcement, a crime reference number was issued, and formal requests were submitted to the exchanges and swap services in the traced fund path.

The fix

The patch adds three independent layers of defence. Each stops this attack on its own, and all three are deployed together.

• Only spendable tokens are copied across. When a staking change is copied into the Ethereum-compatible layer's record, only the spendable portion is carried over. This removes the root cause, and legitimate delegation of vesting tokens continues to work.  
• A lower-limit check on deduction. If a deduction would take a balance below zero, the operation is rejected, and the transaction reverts rather than rolling over to the top of the range.  
• A guard on protocol-controlled accounts. Accounts controlled by the protocol, such as the staking pool, can no longer have their balance overwritten at the end of a transaction by the record kept in the Ethereum-compatible layer. Even if a balance that does not exist were created, the pool's real tokens could not be destroyed.

Validation. The exploit sequence was reproduced against the live mainnet binary on an isolated network and then run against the patched build. On the patched build, delegating vesting-locked tokens behaves as an ordinary delegation and creates no balance that the account does not hold. Because that balance never comes into existence, the attempt to inflate the pool fails an ordinary balance check, and the entire transaction reverts, leaving the pool and total supply unchanged.

Recovery plan

Recovery will be executed as a targeted state edit - a one-off correction to specific account balances at the block where the network stopped - rather than as a rollback, which would erase every transaction after a chosen point. A rollback was the standard remediation suggested to us, and it does not fit TAC's topology: it would have erased 7,772 legitimate transactions from 218 addresses unconnected to the attack, and it would have left the $TAC bridged to BNB Chain, TON and Ethereum without matching backing on our side.

The plan is governed by three principles.

Staking balances are restored. The plan provides for the bonded pool to be restored to 2,985,651,403.40 TAC and for delegators to be returned to the balances recorded immediately before the incident. Execution depends on adoption of the patched binary by validators and on the successful resumption of block production. No action is required from delegators.

Assets held in addresses associated with the incident are recovered. The 65,100,989 TAC held on TAC was frozen by the halt and will be removed at the state edit. The 1,662,322,353 TAC held on BNB Chain is addressed separately, as set out below.

The remaining shortfall is covered from treasury reserves. The balance of 1,258,228,061.40 TAC is the portion of the drained pool that was disposed of into the market and cannot be recovered on-chain. It is to be covered in full from the treasury reserves of the TAC Foundation. In total the attacker disposed of 1,258,229,197 TAC; the difference of 1,135.60 TAC did not originate from the pool.

The state edit will not reverse or reduce the balances of third parties who acquired $TAC on the open market. Those proceeds entered a public market within minutes, and the sold portion cannot be recovered on-chain without affecting purchasers acting in good faith. We will not pursue that route.

These measures are undertaken voluntarily, in the interests of the network and its users. They are not an admission of liability by any entity, and they do not create any contractual entitlement in favour of any holder, delegator or other person.

$TAC on BNB Chain

Bridging $TAC between BNB Chain and TAC is disabled in both directions, and the $TAC OFT adapter on BNB Chain is stopped. While that is the case, $TAC held on BNB Chain cannot be redeemed against the escrow on TAC.

1,662,322,353 TAC is held on BNB Chain in addresses associated with the incident. Work on how $TAC on BNB Chain is treated in the recovery is under way with the venues and infrastructure partners involved. It is not settled, and it will be announced separately, with the mechanism, the timing, and what holders need to do.

Until then, do not trade $TAC on BNB Chain. The terms on which those holdings are treated are undetermined, and trading now carries a risk of loss.

Lessons learned

Arithmetic on balances must fail closed. A deduction that cannot be satisfied has to return an error. It must never pass below zero and continue from the top of the range.

Copying a balance between two records is a trust boundary. Any discrepancy, an account that was skipped or an ordering difference, has to be validated.

An alert cannot outrun a single transaction. Thirty-two seconds separated the drain from the first bridge transfer. A defence against a failure at that speed has to sit in the execution path itself, not in the monitoring around it.

Large bridge transfers need limits. 2.99 billion TAC, ten times the adapter's entire prior custody, left over the bridge in two transactions 63 seconds apart. No single window should be able to carry a transfer of that size. Per-window and per-adapter caps are being implemented as part of the bridge work set out under "Next steps".

Pause capability has to be uniform across bridges. Execution on the TAC-to-TON CrossChainLayer was disabled at 20:42 UTC while the attack was still in progress, which closed the route out of TAC and left an 84.8M TAC transfer undelivered. The LayerZero OFT adapter has no equivalent fast-pause function; disabling it requires a multi-signature action that cannot be completed on the timescale of this attack. Every bridge in the system needs a pause path that can be executed in seconds.

A functional defect and a security defect can be the same defect. We identified two defects in July and assessed their observable effect as a failed transaction. We did not recognise that the underflow they produced could be used to create a balance. Anything on the boundary between the chain's ledger and the Ethereum-compatible layer is now assessed as a security issue by default, whatever the visible symptom.

A report sent is not a report received. Our July analysis was sent directly to a maintainer of the shared module and was not acknowledged. We have since adopted a standing rule: a security-relevant finding in third-party code that is not acknowledged within a defined period is escalated through the published disclosure channel of the relevant project, to the security contacts of other operators running the same code, and internally to our security lead. Coordinated disclosure across a shared dependency depends on the receiving side as much as on the reporting side. Our process now assumes no acknowledgement by default.

Next steps

• Publish the recovery plan: the coordinated upgrade height, the complete process for BNB holders, and timing for re-enabling bridges. Operational detail required for execution is shared directly with the venues and infrastructure partners involved.  
• Complete the coordinated validator upgrade and resume block production on the patched binary.  
• Execute the state edit and restore staking balances.  
• Re-enable exchange deposits and withdrawals in coordination with our venue partners.  
• Implement per-window and per-adapter transfer limits and a fast-pause path on every bridge leg.  
• Publish the full technical detail of the vulnerability now that the upstream fixes are public.  
• Continue working with the venues that received the proceeds, and with law enforcement.  
• Complete registration for upstream private security notifications, and extend that registration to our bridge and exchange partners.

We will continue to publish updates through to the restart. The only official channels are the TAC account on X and the official TAC Telegram channel. We will never ask you to connect a wallet, claim tokens on an external site, or send funds in order to receive anything.

Acknowledgements

We thank the validators who coordinated the halt at short notice; SEAL 911, Elliptic, Chainalysis, AML Bot, Scorechain and Crystal Intelligence for their work on tracing; the exchanges and infrastructure providers that suspended $TAC markets and flagged flows on request; and the other affected networks for sharing information while their own incidents were live. We also thank our community for its patience while the network is halted.

Appendix: addresses and transactions

Addresses are listed on the basis of on-chain analysis of the transactions described in this report. Their inclusion is not a legal determination as to the identity or conduct of any person.