Thunder Finance Rug Pull

Reported loss $19K
BNB Chain
Rugpull

What happened

Thunder Finance (TNDR) is a BNB Smart Chain token whose verified contract, ThunderFinance, gives the full 110,000 TNDR supply to the deployer and then lets only a hand-picked set of addresses transfer tokens. The comment block at the top of the source promises a 3% transfer tax, a locked team allocation and a liquidity-mining contract, but the contract code contains none of these. De.Fi's REKT database lists the project as an exit scam: the deployer added initial liquidity in bscscan.com transaction 0x01c0187f…5fd19a and removed it in 0x368154f8…99c21c, with a listed loss of 18,558 USD.

Neither transaction page could be opened for this review.

How it happened

  1. The constructor sets owner = msg.sender; and balanceOf[msg.sender] = totalSupply;, so the deployer holds the whole supply. owner is private and there is no function that changes it.
  2. Every transfer, including router-driven transferFrom calls, passes through ensure, which returns early only for if(_from == owner || _to == owner || _from == tradeAddress||canSale[_from]){ return true; }. Any other sender must satisfy require(condition(_from, _value));.
  3. condition begins with if(_saleNum == 0 && _minSale == 0 && _maxSale == 0) return false;. The variables _saleNum, _minSale and _maxSale are declared but never assigned anywhere in the contract, so they stay 0 and condition returns false for every non-exempt sender. Such a holder's transfer reverts unless the recipient is the owner address, which means a sell through a router (transferFrom(holder, pool, amount)) fails for them.
  4. The owner controls who is exempt. approveAndCall(address spender, uint256 addedValue) is owner-only and sets canSale[spender]=true;, and transferownership(address addr) is owner-only and only sets tradeAddress = addr; (it does not transfer ownership). Because tokens leaving the pool also pass ensure, buys work only if the pool address has been given one of these exemptions; the source does not show whether it was.
  5. approveAndCall also runs balanceOf[spender] = addedValue*(10**uint256(decimals));, an overwrite of any address's balance that does not change totalSupply. This is a power the code allows; no transaction opened here shows it being used.
  6. What happened, per De.Fi's listing: the deployer added liquidity and later removed it, leaving 18,558 USD of losses. Who held the liquidity tokens in between is not shown by any source opened.

Protocol details

Classification Exchange (DEX)
Protocol Type Exit Scam/Rugpull
Affected asset / contract TNDR
Protocol links Website @Thunder_Finance

Evidence

Same attack technique

Browse all hacks →
BNB Chain MoltenSwap $122K lost BNB Chain Mars Farm $38K lost Ethereum Focus $10K lost BNB Chain Wallstreetswap Finance $2.9M lost

Build your security review skills

Work through hands-on labs covering real exploit mechanics, review techniques, and defensive patterns.

Start Free Trial Explore attack classes