TeamRocket Honeypot

Reported loss Not disclosed
BNB Chain
Honeypot

What happened

TeamRocket (on-chain name $TeamRocket, BNB Chain contract 0xa260ca4e…280bff) is a BEP-20 token whose _approve function keeps real allowances only for one hard-coded address, 0xBbE84f65…eed195, which is also the deploying address and the owner. For every other holder _approve writes an allowance of zero, so any transferFrom for a non-zero amount, which is what a router uses to sell, reverts on the allowance check. De.Fi's REKT database lists the token as an Exit Scam/Honeypot, stating that the contract owner could disable the transfer function, which restricted users in selling their tokens; no sell transaction, pool address or loss figure was opened to confirm what happened on-chain.

The owner can also call an uncapped mint.

How it happened

  1. The constructor credits the entire supply, 8723563500000000000 base units at 7 decimals (872,356,350,000 tokens), to the deployer with _balances[msg.sender] = _totalSupply;.
  2. _approve is the function every approval path goes through. It branches on a literal address: if (owner == address(0xBbE84f65D89A1d083470f771869F4e67f0eed195)) { _allowances[owner][spender] = amount; stores the requested value, but else { _allowances[owner][spender] = 0; stores zero and emits Approval(owner, spender, 0) for everyone else.
  3. A holder who approves a router therefore gets an allowance of zero, because approve calls _approve(_msgSender(), spender, amount).
  4. A sell goes through the router's transferFrom(holder, pair, amount). In this contract transferFrom calls _transfer(sender, recipient, amount) first and then _approve(sender, _msgSender(), _allowances[sender][_msgSender()].sub(amount, "BEP20: transfer amount exceeds allowance")). The stored allowance is 0, so sub reverts for any amount above zero and the whole call, including the balance move, is rolled back. The holder keeps the tokens but cannot sell them through a router.
  5. A purchase uses transfer from the pool to the buyer, which calls _transfer and does not read allowances, so buying is not affected. transferFrom for the hard-coded address behaves normally because its allowances are stored.
  6. The exemption is tied to the literal address, not to owner(): renounceOwnership exists but would not remove it. The owner can also create tokens with function mint(uint256 amount) public onlyOwner, which has no cap. The source does not show whether mint or a pool deposit was ever used.

Protocol details

Classification Token
Protocol Type Exit Scam/Honeypot
Affected asset / contract TEAM ROCKET

Evidence

Same attack technique

Browse all hacks →
BNB Chain ElonSperm Loss not disclosed Ethereum PiggyBank Community Token Loss not disclosed BNB Chain HOGtoken Loss not disclosed Ethereum GAMEE Loss not disclosed

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