Skip to main content
• 6 min read

TAC Bridge Exploit: $2.8M Lost on TON-Side
Cross-Chain Layer, Later Routed Through White-Hat Recovery

TAC disclosed a TON-side cross-chain layer exploit that moved about $2.8 million across USDT, BLUM, and tsTON. The bridge remained paused for forensic work, unaffected assets were scoped, and later reporting said the incident moved into a white-hat recovery path after a 10% bounty offer.

AUTOSEC.DEVAUTOSEC.DEV
TAC Bridge Exploit: $2.8M Lost on TON-Side Cross-Chain Layer, Later Routed Through White-Hat Recovery
  • Incident Date: May 12, 2026; publicly confirmed on May 14, 2026
  • Target: TAC cross-chain layer / bridge liquidity on the TON side
  • Target Overview: TAC is an EVM-focused blockchain layer built to connect Ethereum-compatible applications and liquidity with the TON and Telegram ecosystem. The affected incident was publicly scoped to the TON side of TAC's cross-chain layer rather than the broader TAC token, TON, or Ethereum-bridged ERC-20 asset set.
  • Total Loss: ~$2.8 million across USDT, BLUM, and tsTON
  • Attack Vector: TON-Side Bridge Exploit / Cross-Chain Asset Validation Risk / Bridge Liquidity Accounting Exposure

Incident Review & Technical Details​

1. Attack Path​

  1. Bridge Activity Was Interrupted After Security Alerts: Public reporting said TAC first disclosed a live bridge security issue on May 12, 2026, after reports from security partners. The bridge was paused while the team investigated the affected flow.
  2. TON-Side Cross-Chain Layer Was Confirmed as the Exploit Surface: TAC later stated that an external attacker exploited the TON side of its cross-chain layer. The disclosed loss was approximately $2.8 million.
  3. Affected Assets Were Scoped: The public loss basket involved USDT, BLUM, and tsTON. TAC stated that the TAC token, TON, and ERC-20 tokens bridged from Ethereum were not affected.
  4. Forensic and Remediation Work Continued Under Pause: TAC said the bridge would remain paused while the team performed forensic analysis, remediation, and additional disclosure preparation.
  5. Tracing and Blocking Efforts Were Launched: TAC said it was working with law enforcement, SEAL 911, and security partners to trace and block the stolen funds.
  6. User-Make-Whole Plan Was Announced: TAC said it planned to restore bridge liquidity and compensate users through a legally structured sale of TAC token reserves from the foundation treasury.
  7. White-Hat Return Path Was Offered: Follow-up reporting said TAC offered the attacker a 10% white-hat bounty if the funds were returned to a designated multisig address, with no legal action against parties associated with the relevant ETH/BSC, ZEC, and TON addresses.
  8. Incident Was Later Reported as White-Hat Recovery: Later news coverage said the attacker accepted the recovery path, with the bounty valued at roughly 13 ETH plus 300 ZEC, and that TAC treated the matter as a white-hat incident after the returned funds were routed to the specified wallets.

2. Impact Scope​

  • Direct Losses: Approximately $2.8 million in USDT, BLUM, and tsTON was moved through the affected cross-chain path.
  • Affected Component: The disclosed exploit surface was the TON side of TAC's cross-chain layer / bridge.
  • Unaffected Assets: TAC publicly scoped TAC, TON, and all ERC-20 tokens bridged from Ethereum as unaffected.
  • Bridge Availability: The bridge remained paused during the investigation, remediation, and liquidity-restoration process.
  • Recovery Status: Public reporting indicated a white-hat recovery path after TAC offered a 10% bounty and the attacker returned the remaining funds to the designated wallets.
  • Disclosure Gap: As of the reviewed public materials, TAC had not yet published a complete code-level post-mortem that identifies the exact vulnerable function, validation branch, or message-handling invariant that failed.

3. Root Cause Assessment​

The most cautious public assessment is that the incident was a bridge-layer validation and accounting failure on the TON-side flow. A precise root cause should remain pending until TAC publishes a full post-mortem with affected contracts, transactions, and code-level analysis.

Key risk patterns to examine:

  • Cross-Chain Asset Mapping: Bridges must bind source asset, destination representation, amount, sender, recipient, nonce, and chain ID into one verified transfer record. Any mismatch can turn message acceptance into unauthorized asset release.
  • Native TON Jetton Handling: TON-side assets and EVM-side assets have different execution and token semantics. Bridge adapters must prevent malformed Jetton flows, stale message proofs, incorrect asset identifiers, or unsafe liquidity accounting from crossing trust boundaries.
  • Message Verification and Replay Controls: Cross-chain systems need strict uniqueness, finality, replay protection, and proof verification before releasing liquidity or minting representations.
  • Bridge Liquidity Segmentation: If one asset path or one side of the bridge fails, the blast radius should be capped by per-asset limits, route-level circuit breakers, and isolated liquidity pools.
  • Operational Pause Dependency: The bridge pause limited further damage, but emergency response is a last line of defense. The primary invariant should be that invalid cross-chain messages cannot move assets even before human operators intervene.

The core invariant should be strict: a TON-side bridge message must not release or account for any asset unless the corresponding source-side state transition is proven, fresh, non-replayed, correctly mapped, and bounded by per-route liquidity controls.

4. Mitigation and Response​

Recommended actions for TAC-style cross-chain layers and TON/EVM bridge systems:

  • Keep affected bridge routes paused until a complete post-mortem, patch diff, and independent review are complete.
  • Publish affected contract addresses, relevant transaction hashes, bridge route IDs, token mappings, and recovery wallet addresses.
  • Enforce canonical asset mapping for USDT, BLUM, tsTON, TON, TAC, and ERC-20 representations across every supported route.
  • Require source-chain finality, proof freshness, nonce uniqueness, and replay protection before any destination-side liquidity release.
  • Add per-token and per-route circuit breakers for unusual outflows, message-volume spikes, or liquidity movements that exceed normal bridge behavior.
  • Separate TON-native Jetton handling from EVM ERC-20 handling so differences in token standards cannot leak into shared accounting assumptions.
  • Use independent watchers to compare source-side lock/burn events with destination-side mint/release events in real time.
  • Run fork-based incident replay tests once full transaction data is available, then convert the exploit path into regression tests.
  • Commission an external bridge security review focused on cross-chain message verification, bridge accounting, route isolation, and emergency pause controls.

AUTOSEC.DEV Solution: Building a 360-Degree Defense​

TAC's incident shows why cross-chain systems need more than isolated smart contract review. Bridge safety depends on the full path: source-chain event validation, destination-chain execution, token-standard adapters, liquidity accounting, and operational monitoring.

  1. Cross-Chain Protocol Audit: AUTOSEC.DEV reviews bridge adapters, message verification, replay controls, finality assumptions, canonical asset mapping, and liquidity-release logic across both source and destination chains.
  2. TON / EVM Integration Review: We examine Jetton and ERC-20 handling, route configuration, accounting conversion, decimals, token identity binding, and signer or relayer assumptions that can diverge between ecosystems.
  3. Bridge Invariant Testing: We build fork tests and fuzz harnesses for invalid messages, replayed transfers, wrong token mappings, stale nonces, liquidity over-release, and route-specific circuit breaker failures.
  4. Incident Response (IR): AUTOSEC.DEV supports rapid exploit scoping, transaction reconstruction, stolen-fund tracing, affected-user accounting, emergency pause guidance, and post-incident hardening for active bridge incidents.

Service Content​

Reference​