BRONZE MOON Honeypot

Reported loss Not disclosed
BNB Chain
Honeypot

What happened

BRONZE MOON (BRONZEMOON, contract 0x2c5dfa69…617649 on BNB Smart Chain) keeps an address newun and rejects every transfer whose recipient equals it. The first transferFrom call sets newun to its recipient, so if that call is the liquidity deposit, newun becomes the trading pair and later sales into the pair revert with "please wait" while buys still work. The owner can also overwrite newun with transfernewun.

De.Fi's REKT database lists BRONZEMOON as an Exit Scam/Honeypot on 2021-04-12 and describes the owner as able to disable transfers so users could not sell.

How it happened

  1. The constructor sets symbol = "BRONZEMOON" and credits the whole supply to the deployer with balances[owner] = _totalSupply;.
  2. transferFrom runs if(from != address(0) && newun == address(0)) newun = to;. The first call with a non-zero from stores its recipient in newun and skips the check. If that call is the router moving tokens into the pool as liquidity is added, newun is the pair.
  3. Every later transferFrom takes the else require(to != newun, "please wait"); branch. A router sale, which calls transferFrom(holder, pair, amount), reverts while the pair is newun; transfer has the same require(to != newun, "please wait");.
  4. Buys are not affected: the pair pays out with transfer to the buyer, who is not newun.
  5. The owner can change the block with function transfernewun(address _newun) public onlyOwner. Pointing it at an unused address lifts the block; setting it to zero lets the next transferFrom capture a new recipient. The Owned contract has no renounce function.

Protocol details

Classification Token
Protocol Type Exit Scam/Honeypot
Affected asset / contract BRONZEMOON

Build your security review skills

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