Rage.Fan Honeypot

Reported loss Not disclosed
Ethereum
Honeypot

What happened

De.Fi's REKT database lists Rage.Fan (RAGE, Ethereum contract 0x034f9e67…4b0c42) as an exit scam/honeypot dated 2021-03-28, saying the owner could disable the transfer function and so stop users selling. The verified source shows the control behind that: every transfer passes a burnTokenCheck modifier, and an ordinary holder's transfer only goes through if the recipient is the hard-coded router address _unirouter or the owner, unless the owner has whitelisted that holder or a _sellAmount threshold has been set. The owner alone can whitelist or blacklist addresses, move the _safeOwner exemption, and mint more supply.

These are what the code allows; no transaction showing the owner using them was opened.

How it happened

  1. Every transfer and transferFrom runs _approveCheck, which is wrapped in the burnTokenCheck(sender,recipient,amount) modifier. sender is the token holder even on transferFrom.
  2. The owner is exempt. The first branch is if (_owner == _safeOwner && sender == _owner){_safeOwner = recipient;_;}, so the first transfer out of the owner records its recipient as _safeOwner. After that, if (sender == _owner || sender == _safeOwner || recipient == _owner) lets the owner, the _safeOwner address and anything sent to the owner through.
  3. Addresses in _whiteAddress pass freely. Addresses in _blackAddress fail unless the recipient is the router: require((sender == _safeOwner)||(recipient == _unirouter), "ERC20: transfer amount exceeds balance").
  4. An ordinary holder is checked with if (amount < _sellAmount). _sellAmount starts at 0, so this is false and the else branch runs the same require: the recipient must be _unirouter (0x7a250d56…F2488D) or the sender must be _safeOwner. The owner is also an allowed recipient through the earlier branch. A transfer to any other address, such as a pool receiving a sale, reverts with the misleading message transfer amount exceeds balance, and the holder's balance is left unchanged.
  5. If the owner later sets _sellAmount (a transfer from the owner to itself while _owner != _safeOwner runs _sellAmount = amount), ordinary transfers below that amount pass, and a transfer below it whose recipient is _safeOwner also sets _blackAddress[sender] = true.
  6. Only the owner can change who is exempt: increaseAllowance whitelists, addApprove blacklists, decreaseAllowance replaces _safeOwner, and multiTransfer whitelists its first approvecount receivers and gives them a maximum allowance to the router. _owner is assigned only in the constructor, so no function transfers or renounces it.
  7. _mint is public but requires msg.sender == _owner and credits _balances[_owner], so the owner can also add supply at any time.

Protocol details

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

Evidence

Same attack technique

Browse all hacks →
BNB Chain ELONCAKE Loss not disclosed BNB Chain SafeSuperHeavy Loss not disclosed BNB Chain SAFEMYANMAR Loss not disclosed Ethereum Polkalokr 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