MoonGold Honeypot

Reported loss Not disclosed
BNB Chain
Honeypot

What happened

MoonGold blocks sells through a variable named newun that transferFrom fills automatically. The first transferFrom call from a non-zero address while newun is empty stores that call's recipient in newun, and from then on every transfer and transferFrom to that address reverts with "please wait". When the stored address is the liquidity pair, buys (which send tokens out of the pair) still work, but a holder's sell, which sends tokens into the pair, reverts.

De.Fi's REKT database lists MoonGold as an exit scam/honeypot on BNB Smart Chain and states that the contract owner could disable the transfer function, which restricted users in selling their tokens. The code does not show which address newun held on chain or whether liquidity was later withdrawn.

How it happened

  1. The constructor sets the deployer as owner and gives it the whole supply: balances[owner] = _totalSupply; (1,000,000,000,000,000 tokens with 18 decimals). newun starts as the zero address.
  2. transfer refuses any recipient equal to newun: require(to != newun, "please wait");.
  3. transferFrom contains the capture logic: if(from != address(0) && newun == address(0)) newun = to; else require(to != newun, "please wait");. The first call with newun empty skips the require and stores to; later calls hit the else branch. A router adding liquidity calls transferFrom with the pair as recipient, so the pair address would be stored then; the source does not say that this happened for this token.
  4. Once newun equals the pair, a buy works because the pair sends tokens to the buyer (to is the buyer), and holder-to-holder transfers work. A sell via transfer or a router's transferFrom has the pair as to, so it reverts with "please wait". There is no owner exemption, so the owner's own transfers to that address revert as well.
  5. The owner can change the value with function transfernewun(address _newun) public onlyOwner { newun = _newun; }. Setting it to the zero address re-arms the capture on the next transferFrom, and only pointing it at an address that is not used as a recipient lifts the block.
  6. clearCNDAO() (onlyOwner) sends the contract's own BNB balance to the owner, which does not touch pool liquidity. The source file header says the token and liquidity are burned before listing and the footer says the tokens are for testing purposes, but the code contains no liquidity burn.
  7. What happened on chain (the newun value, sells that failed, liquidity removed) is not shown by the source; the honeypot label comes from De.Fi's listing and a blog post that explains this same mechanism in other tokens.

Protocol details

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

Evidence

Same attack technique

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