A 36-Hour Drain: How TMXTribe Lost $1.4 Million to an Unaudited Contract Loop
TMXTribe, an Arbitrum-based perpetuals platform built as a fork of GMX, lost roughly $1.4 million to an exploit that ran for about 36 hours before the funds were bridged out and laundered. The protocol had no completed security audit, and the vulnerable contract was never verified on-chain. Despite being visibly active during the incident — offering the attacker a bounty and repeatedly deploying and upgrading contracts — the team never triggered an emergency pause.
01A simple loop, not a sophisticated attack

Researchers who examined the incident, including Defimon Alerts, CertiK Alert, Extractor by Hacken, and QuillAudits, converged on the same conclusion: this wasn't a flash-loan attack, an oracle manipulation, or a re-entrancy bug. It was a repeatable four-step sequence that the protocol's own logic failed to catch:
- Mint and stake TMX LP tokens using USDT.
- Swap the deposited USDT for USDG, the protocol's internal stablecoin.
- Unstake the LP tokens.
- Sell or otherwise drain the USDG obtained.
The attacker then repeated this cycle over and over. Because the underlying contract governing minting, staking and swapping was unverified and lacked balance checks or circuit breakers, nothing in the system stopped the loop from running indefinitely.
Defimon Alerts was first to flag trouble on January 5th, reporting that the GMX fork had apparently been hacked on Arbitrum. CertiK Alert followed within hours, identifying the unverified contract's flawed LP staking and swap logic as the point of failure. QuillAudits later reiterated a point security researchers have made repeatedly: contracts that aren't verified can't be properly reviewed, and code that can't be reviewed can't be trusted.
02Following the stolen funds
The main exploiter wallet, 0x763a67E4418278f84c04383071fC00165C112661 — tagged "Tribe Perpetual Exploiter" on Arbiscan — ran the drainage loop across the 36-hour window. Its initial funding transaction, dated January 3rd, is recorded at 0xaa789bba4dbf761f427de69277fcdeaaa75894f219e2bb44c6fcf40eb68d95d8. Over roughly the next 48 hours, the address executed 502 transactions, steadily working through TMXTribe's liquidity.
Internal transaction data shows a consistent pattern: convert drained assets into ETH, batch the proceeds, then prepare them for bridging. Notable batches include 94.13 ETH (about $309,451), 62.57 ETH (about $205,704), 57.47 ETH (about $188,945), and 47.05 ETH (about $154,697).
A second address, 0x16Ed3AFf3255FDDB44dAa73B4dE06f0c2E15288d, ran the identical mint-swap-unstake-drain sequence in parallel, effectively operating a second exploitation channel alongside the primary one.
From Arbitrum, the funds moved to Ethereum via Across Protocol in three bridging transactions:
- 260 WETH (~$821,000): 0xa060241eaee611c801c043fd38bac7e0d979e76106b64c2ad431f628a4a64e16
- 3.419912 WBTC (~$312,000): 0xf003f6f833dca32dff39697f3bcee4875b7e45d61cf3ba9cd5bab66011ed3e60
- 15.939846 WETH (~$50,000): 0x6a845d0971b9c4255797530d93257318cfa8bcd04d680490c15b9573316c0d0d
Once on Ethereum, just under $1.2 million reached the exploiter's address, which then deposited the ETH into Tornado Cash, severing the on-chain trail. The address's balance now sits at approximately 0.00664 ETH (roughly $21) — everything beyond that has been mixed and is no longer traceable. Extractor by Hacken tracked this bridging-then-mixing sequence in real time.
03Present, but not pausing
While the funds were mid-transit to Ethereum and Tornado Cash, TMXTribe did take one visible action: it sent an on-chain message to the exploiter offering a standard whitehat-style deal — keep 20%, return the remaining 80%. That offer is permanently recorded in transaction 0xb31a0e8b0ed3a370493f6f63c01600cee62e1d4df2af159c9ff22fc2d8adccf4. The exploiter never responded.
The wallet that sent the bounty message, 0x33392e39325013e81874ca7b76326858ec179543, was also busy elsewhere: deploying and upgrading contracts throughout the exploitation window. The recorded sequence, all on January 5th unless noted:
- 7:02 AM UTC — new contract deployed (tx), immediately followed by an upgrade transaction (tx) targeting contract 0x3AfdbeF553d5c92817da37096bb2e47daeEF951d.
- 10:49 AM — another contract deployed (tx), followed by two more upgrades to the same target contract (tx1, tx2).
- 12:08 PM — another contract deployment (tx) and upgrade (tx).
- 1:46 PM — the bounty message to the exploiter is sent (tx).
- 1:57–1:58 PM — another contract created (tx) with two upgrades (upgrade 1, upgrade 2).
- 2:16 PM — another deployment (tx) and upgrade (tx).
- 2:19 PM — another deployment (tx) and upgrade (tx).
- 3:06 PM — a deployment (tx) and upgrade (tx), followed by a second deployment (tx) and upgrade (tx), also at 3:06 PM.
- January 7th, 7:50–7:51 AM UTC — another contract created (tx), with two further upgrades (upgrade 1, upgrade 2).

Throughout this window, the team's wallet remained demonstrably active — deploying, upgrading, sending an on-chain bounty offer — yet at no point executed a pause or circuit breaker. Extractor by Hacken summarized it plainly: the exploit ran for roughly 36 hours and TMX took no action to contain it. That wallet reportedly remains active even after the incident.
04Silence after the fact
TMXTribe's public communication has been essentially nonexistent. As of four days after the exploit, there had been no post-mortem, no compensation plan, and no acknowledgment from the @TMXdex account, which has continued posting without mentioning the $1.4 million loss.
The separate @TMXTribe account was found deleted as of January 6th, then reappeared on January 7th with a single tweet containing a link flagged as likely phishing by IPQualityScore.
05Summary
TMXTribe combined several red flags before any funds were lost: an unverified core contract, no completed audit, and a GMX-derived codebase that apparently didn't inherit GMX's security practices. Once the exploit began, the team's on-chain activity — contract deployments, upgrades, and a bounty offer sent while stolen funds were already mid-bridge — shows they were engaged with the situation in some capacity, but never used that access to pause the protocol. Days later, no formal statement, compensation plan, or explanation had been issued, leaving only the transaction history as a record of what happened.
Get new scam files the moment we publish them — usually 2–3 emails a week.