EASYFEEDBACK Honeypot

Reported loss Not disclosed
BNB Chain
Honeypot

What happened

EASYFEEDBACK (EASYF) is a BNB Smart Chain token (contract 0xdc154e08…53d456) with a hidden destination block in its transfer and transferFrom functions. The first transferFrom call made while the newun variable is empty stores its recipient in newun, and from then on every transfer to that address reverts with "please wait". If that first recipient is the trading pair, which is the first-liquidity pattern described by a 2021 write-up of identical code in other tokens, buys still work but sales into the pair fail.

The owner can reset the stored address with transfernewun. De.Fi's REKT database lists the token as an Exit Scam/Honeypot and states that the contract owner could disable the transfer function, which restricted users in selling their tokens.

How it happened

  1. The constructor mints the whole supply to the deployer: _totalSupply = 1000000000000000000; with decimals = 9 (1,000,000,000 tokens), balances[owner] = _totalSupply;. The public variable newun starts as 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 with a non-zero from while newun is empty passes without any check and stores its to as newun. Router-based add-liquidity moves tokens with transferFrom, so the pair is the likely first recipient; the source alone does not show which address was stored.
  3. After capture, the else branch applies to every later transferFrom: require(to != newun, "please wait"). A sale through a router is transferFrom(holder, pair, amount), so if newun is the pair it reverts for every holder and the holder's balance is not debited.
  4. transfer has the same rule: require(to != newun, "please wait");. It has no exemption for the owner, so the owner cannot send to newun either. Before capture, newun is zero, so only transfers to the zero address are blocked.
  5. Transfers out of the pair are not blocked: a buy is transfer from the pair to the buyer, whose address is not newun; liquidity removal pays tokens from the pair to the LP holder in the same way.
  6. The owner can change the stored address with transfernewun(address _newun). Setting it to the zero address re-arms the capture on the next transferFrom; pointing it at an address nobody sends to lifts the block; pointing it at the pair restores it.
  7. clearCNDAO() sends any BNB held by the contract to the owner, and transferOwnership / acceptOwnership allow handing the owner role to another address.
  8. What happened is known only from the listing: De.Fi's REKT database classifies the token as an Exit Scam/Honeypot and gives no loss figure. A security write-up dated 2021-04-11 quotes the same two transferFrom lines for other tokens and says the first add-liquidity transaction sets newun to the liquidity pool address, after which sells fail with "please wait". It names SafeBinance and SafeRocket, not EASYFEEDBACK, and no transaction for this token was opened.

Protocol details

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

Evidence

Same attack technique

Browse all hacks →
BNB Chain BSCSportsBet Loss not disclosed BNB Chain SpaceX Token Loss not disclosed BNB Chain CocoBee Loss not disclosed BNB Chain AstroCum 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