SupremeBSCmoon Honeypot

Reported loss Not disclosed
BNB Chain
Honeypot

What happened

SupremeBSCmoon on BNB Chain stores an address called newun. Its transferFrom writes the recipient of the first call into newun while it is unset, and afterwards every transfer or transferFrom whose recipient is newun reverts with "please wait". The cited analysis of this code pattern explains that the first call is the liquidity add, so newun becomes the pool address and holders cannot sell into it.

The source comment advertises a 10% tax and an NFT platform, but the code contains neither. De.Fi's REKT database lists the token as an exit scam/honeypot dated 2021-04-10 and says the owner could disable the transfer function, which restricted users in selling their tokens; it gives no loss figure.

How it happened

  1. The constructor sets _totalSupply = 1000000000000000000000000000000000; and balances[owner] = _totalSupply;, so the deployer holds the whole supply, 10^15 tokens at 18 decimals.
  2. transfer begins with require(to != newun, "please wait");, so a direct transfer to the address in newun reverts.
  3. transferFrom begins with if(from != address(0) && newun == address(0)) newun = to; else require(to != newun, "please wait");. The first call with a non-zero from while newun is unset skips the require and stores its recipient in newun. Per the analysis of this pattern, that first call is the router pulling tokens into the pool when liquidity is added, which makes the pool address newun.
  4. From then on a sell, which reaches the token as a transferFrom with the pool as recipient, fails the require. Buys are transfers out of the pool to the buyer, whose recipient is not newun, so this check does not stop them. Nothing in the require touches transfers out of the pool.
  5. transfernewun(address _newun) is onlyOwner and overwrites newun. Pointing it at an unused address lifts the block; setting it back to the zero address lets the next transferFrom with a non-zero from capture its recipient again. The source shows what the owner can do; it does not show a call to it.
  6. The code has no renounce function. A current-state read on 2026-09-30 lists the deployer 0x4C893672…2D84E2 as owner, and transferOwnership can still change it.

Protocol details

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

Evidence

Same attack technique

Browse all hacks →
BNB Chain SAFEMOUSE Loss not disclosed BNB Chain FairSafeApe Loss not disclosed BNB Chain eGRID Loss not disclosed BNB Chain Zion 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