RUSHMOON Honeypot

Reported loss Not disclosed
BNB Chain
Honeypot

What happened

De.Fi's REKT database lists RUSHMOON (RUSH) on BNB Smart Chain as an exit scam / honeypot, stating that the contract owner could disable the transfer function, which restricted users in selling their tokens. The verified source at 0xd730f82d…c68709 shows a different but related mechanism. The first transferFrom call after deployment stores its recipient in newun, and from then on any transfer to that address reverts with please wait.

The owner can change newun with transfernewun. The token has 8 decimals and a supply of 10000000000000000 raw units (100,000,000 tokens). The deployment transaction is 0x49620e3b…c67aeb, sent by 0x2D583209…4A72cc, the owner address the contract reported when read on 2026-09-30.

How it happened

  1. The constructor sets symbol = "RUSH", name = "RUSHMOON", mints _totalSupply = 10000000000000000 (8 decimals) to the owner, and leaves address public newun at the zero address.
  2. transferFrom begins with if(from != address(0) && newun == address(0)) newun = to; else require(to != newun, "please wait");. The first transferFrom after deployment, by any caller, passes and records its recipient as newun. A router-based liquidity add is a transferFrom into the pair, so it would record the pair, but the code alone does not show which address was captured.
  3. transfer contains require(to != newun, "please wait");, and every later transferFrom takes the else branch with the same check. No sender is exempt, the owner included, so no one can send tokens to the newun address.
  4. A swap that sells tokens moves them from the holder to the pair with transferFrom. If the pair is the stored newun, that call reverts with please wait. Tokens leaving that address (buys) are not checked, because the checks look only at the recipient. A write-up on the same newun code pattern in other tokens (SafeRocket, SafeBinance) describes it as stopping swaps back to BNB.
  5. transfernewun(address _newun) is onlyOwner. Setting it to the zero address makes the next transferFrom capture a new recipient, so the block is re-armed; pointing it at an unused address lifts the block for the former address. There is no renounceOwnership; transferOwnership and acceptOwnership move ownership.
  6. What the code allows is separate from what happened: no transaction was opened showing which address newun held or who failed to sell, so the outcome rests on De.Fi's listing.

Protocol details

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

Evidence

Same attack technique

Browse all hacks →
BNB Chain NFT ECO Loss not disclosed Ethereum LIGMA Loss not disclosed BNB Chain FULLMOON Loss not disclosed Ethereum Kwikswap 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