ELON INU Honeypot

Reported loss Not disclosed
BNB Chain
Honeypot

What happened

ELON INU (ELONINU) is a BEP-20 token on BNB Smart Chain, deployed from 0xcCf00dD3…Ce81bA at contract address 0xca33eb8a…f19d30. All 10 billion tokens are minted to a hard-coded owner address, 0x961266bD…2f5516, in the constructor. The token's transfer and transferFrom functions contain a variable, newun, that records the first address to receive tokens through transferFrom and then rejects every later transfer to that address with the message "please wait".

Because a trading pool receives tokens whenever someone sells, this blocks selling once the pool address has been captured, while buying (tokens leaving the pool) is not checked. De.Fi's REKT database lists the token as an Exit Scam/Honeypot in which the contract owner could disable the transfer function, restricting users from selling. The listing gives no loss figure and no transaction hashes.

How it happened

  1. The constructor sets symbol = "ELONINU", name = "ELON INU" and _totalSupply = 10000000000e18, and assigns the whole supply to balances[owner]; the owner address is hard-coded as owner = 0x961266bD90AE587b68e58e1EDCA131Bdd82f5516.
  2. transferFrom runs if(from != address(0) && newun == address(0)) newun = to; else require(to != newun, "please wait");. The first transferFrom with a non-zero sender therefore stores its recipient in newun without any check. A router-based liquidity add moves the owner's tokens to the pool with transferFrom, so the pool can become newun this way (the code allows this; the on-chain newun value was not read).
  3. From then on every transferFrom whose recipient equals newun reverts, because the else branch requires to != newun. A sell through a router calls transferFrom(seller, pool, amount), so it fails for every holder. transfer has the same guard: require(to != newun, "please wait");.
  4. Buys are not affected by this check: the pool pays buyers with transfer(buyer, amount), and the guard only tests the recipient against newun. Holders can therefore acquire tokens that they cannot sell back through the pool.
  5. The owner can call transfernewun(address _newun) (onlyOwner) to overwrite newun. Setting it to address(0) makes the next transferFrom recipient be captured again, so the block re-arms; only pointing it at an address that is not the pool lifts it. There is no function that changes the owner except transferOwnership/acceptOwnership, and no renounceOwnership.
  6. clearCNDAO() (onlyOwner) sends the contract's own BNB balance to the owner, and the contract has a payable fallback. This does not touch holders' tokens or the pool.
  7. What happened on chain is not established here: no sell transactions, liquidity removal or owner calls were opened. Only De.Fi's REKT database listing states that selling was restricted.

Protocol details

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

Evidence

Same attack technique

Browse all hacks →
BNB Chain E-Coin Loss not disclosed BNB Chain Rainicorn Loss not disclosed BNB Chain XSPACE Loss not disclosed BNB Chain AnimalHouse Finance 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