HappyMoon Honeypot

Reported loss Not disclosed
BNB Chain
Honeypot

What happened

HappyMoon is a BEP-20 token on BNB Smart Chain whose transfer and transferFrom functions revert for any transfer whose recipient equals a stored address called newun. transferFrom fills newun with the recipient of the first call made while it is empty, which on a DEX is typically the liquidity pair created when liquidity is added. After that, buys still work but any sell, which sends tokens to the pair, reverts with "please wait".

The owner can also change newun with transfernewun. De.Fi's REKT database lists the token as an Exit Scam/Honeypot and describes it as a contract where the owner could disable the transfer function, which restricted users in selling their tokens.

How it happened

  1. The constructor mints the whole supply to the deployer, who becomes owner: _totalSupply = 10000000000000000000000000000000; and balances[owner] = _totalSupply; (10^31 raw units, 10 trillion tokens at 18 decimals).
  2. The contract keeps a variable address public newun; that is empty at deployment. transferFrom runs if(from != address(0) && newun == address(0)) newun = to; else require(to != newun, "please wait");, so the first transferFrom made while newun is empty passes and stores its recipient in newun. On a DEX, the router's transferFrom that moves tokens into the pair when liquidity is added would be that first call.
  3. From then on both transfer paths check the recipient: require(to != newun, "please wait"); in transfer and the same else require(to != newun, "please wait"); branch in transferFrom. A sell routes the holder's tokens to the pair with transferFrom, so it reverts. Buys send tokens from the pair to the buyer, whose address differs from newun, so they succeed. Any holder or the owner moving tokens to the pair is blocked the same way.
  4. The owner can change the block at any time with function transfernewun(address _newun) public onlyOwner { newun = _newun; }. Pointing newun at an unused address lifts the sell block. Setting it to the zero address re-arms capture, so the next transferFrom stores a new recipient. There is no renounceOwnership; transferOwnership only hands the role to another address.
  5. The code also gives the owner clearCNDAO, which sends any BNB held by the token contract to the owner: _owner.transfer(address(this).balance);. Removing liquidity is not blocked by newun, because the pair sends tokens out to the remover, and the recipient is then not newun.
  6. What happened: De.Fi's REKT database lists this token as an Exit Scam/Honeypot dated 2021-09-20 with no loss figure. No opened transaction or holder page in this review shows a specific transfernewun call, a failed sell, or a liquidity removal.

Protocol details

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

Evidence

Same attack technique

Browse all hacks →
BNB Chain InfinitySwap Loss not disclosed Ethereum Flamingo Boys Loss not disclosed BNB Chain MoonGold Loss not disclosed BNB Chain VibeSwap 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