Dragon Farm Honeypot

Reported loss Not disclosed
Ethereum
Honeypot

What happened

Dragon Farm (DRAGON) is an Ethereum ERC-20 token whose transfer and transferFrom functions revert for any transfer whose recipient equals a stored address called newun. transferFrom fills newun with the recipient of the first call made while it is empty, which on a DEX is typically the liquidity pair. After that, buyers receive tokens from the pair, but a sell sends tokens to the pair and reverts with "please wait".

The owner can also change newun with transfernewun. De.Fi's REKT database lists the token as an Exit Scam/Honeypot and describes it as a contract where the 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, who becomes owner: _totalSupply = 1000000000000000000; and balances[owner] = _totalSupply; (10^18 raw units, 10 billion tokens at 8 decimals).
  2. The contract keeps a variable address public newun; that is empty at deployment. transferFrom runs if(from != address(0) && newun == address(0)) newun = to; else require(to != newun, "please wait");, so the first transferFrom made while newun is empty passes and stores its recipient in newun. On a DEX, the router's transferFrom that moves tokens into the pair when liquidity is added would be that first call.
  3. From then on both transfer paths check the recipient: require(to != newun, "please wait"); in transfer and the same else require(to != newun, "please wait"); branch in transferFrom. A sell routes the holder's tokens to the pair with transferFrom, so it reverts. Buys send tokens from the pair to the buyer, whose address differs from newun, so they succeed.
  4. The owner can change the block at any time with function transfernewun(address _newun) public onlyOwner { newun = _newun; }. Pointing newun at an unused address lifts the sell block. Setting it to the zero address re-arms capture, so the next transferFrom stores a new recipient. The code has no renounceOwnership: transferOwnership only sets newOwner, and acceptOwnership requires msg.sender == newOwner.
  5. The source header comment advertises an 8% liquidity fee, a 2% holder fee, a trade limit, burned liquidity LP tokens and ownership renounced to a burn address, but the code contains no fee, reflection or trade-limit logic. The code also gives the owner clearCNDAO, which sends any ETH held by the token contract to the owner: _owner.transfer(address(this).balance);.
  6. What happened: De.Fi's REKT database lists this token as an Exit Scam/Honeypot dated 2021-09-13 with no loss figure. No opened transaction or holder page in this review shows a specific transfernewun call, a failed sell, or a liquidity removal.

Protocol details

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

Evidence

Same attack technique

Browse all hacks →
Ethereum ORAO Network Loss not disclosed Ethereum PLANET Loss not disclosed BNB Chain Fear NFTs Loss not disclosed BNB Chain Arsenal FC Fan Token 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