HuskyMoon Honeypot

Reported loss Not disclosed
BNB Chain
Honeypot

What happened

HuskyMoon (HuskyMoon) is a BNB Smart Chain token whose transferFrom and transfer refuse any transfer to one stored address, newun. newun is filled by the first transferFrom call and the contract owner can change it with transfernewun. If the address that first received tokens through transferFrom is a liquidity pair, every router sell into that pair reverts with "please wait".

De.Fi's REKT database lists the token as an exit scam/honeypot and says the owner could disable the transfer function, and cites an analysis of a similar contract that uses the same newun check.

How it happened

  1. The constructor mints the full supply, 1,000,000,000,000,000 tokens with 18 decimals, to the deployer, who is the Owned owner.
  2. transferFrom begins with if(from != address(0) && newun == address(0)) newun = to; else require(to != newun, "please wait");. The first transferFrom therefore passes and stores its recipient in newun, whoever that is. This is the call a router makes when it pulls tokens from the owner to add liquidity, so in that setup newun ends up being the pool address. The code itself does not name the pool.
  3. From then on, transferFrom(from, newun, amount) always reverts. transfer has the same check (require(to != newun, "please wait");). A sell through a router moves the holder's tokens to the pair with transferFrom, so if the pair is newun the sell reverts. The holder's balance is not debited, because the revert happens before balances[from] = balances[from].sub(tokens).
  4. Transfers out of newun are not blocked, because the check only looks at the recipient. A pair paying a buyer with transfer passes, so purchases can succeed while sells cannot. This is the pattern the cited analysis describes for SafeRocket, not an analysis of HuskyMoon itself.
  5. The owner can change the block at any time with transfernewun(address _newun). Pointing it at an unused address lifts the block, and setting it to address(0) re-arms capture, since the next transferFrom will store its recipient again. The owner can also send the contract's own BNB balance to themselves with clearCNDAO(). Neither a call to these functions nor a failed sell was shown by an opened transaction, so these are what the code allows.
  6. Owned has transferOwnership and acceptOwnership but no renounce function. A read of owner() on 2026-09-30 returned the deployer address 0x8ff6d6a6…c02719.

Protocol details

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

Build your security review skills

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