Rocket Inu Honeypot

Reported loss Not disclosed
Ethereum
Honeypot

What happened

De.Fi's REKT database lists Rocket Inu (RINU), an Ethereum token at 0xa3d813ee…8e6bca, as an Exit Scam/Honeypot dated 2021-04-21 and says the contract owner could disable the transfer function, which restricted users in selling their tokens. The verified source shows how: every transfer and transferFrom runs through a burnTokenCheck modifier that lets the owner, a changeable _safeOwner address and owner-whitelisted addresses move tokens freely, while any other holder can only send tokens to the hard-coded _unirouter address or to the owner. Anything else reverts with ERC20: transfer amount exceeds balance, so a sale into a pool address outside those exceptions fails and the holder's balance is not debited.

The source also declares a beneficiary string and a releaseTime = 6 constant under a comment about liquidity locked for six months, but no code in the file uses them to lock anything. The code allows the gating; the source alone does not show which addresses the owner whitelisted or blacklisted, or what any holder lost, and De.Fi gives no loss figure.

How it happened

  1. The constructor sets _owner = owner; _safeOwner = owner;, so the deployer-supplied owner address is both owner and the privileged _safeOwner.
  2. Every transfer and transferFrom calls _approveCheck, which carries the burnTokenCheck modifier. While _owner == _safeOwner, the first transfer whose sender is the owner passes and runs _safeOwner = recipient, moving the privileged slot to whatever address received it.
  3. After that, a transfer passes if sender == _owner || sender == _safeOwner || recipient == _owner, or if the sender is in _whiteAddress.
  4. Every other sender hits if (amount < _sellAmount){ ... }else{require((sender == _safeOwner)||(recipient == _unirouter), "ERC20: transfer amount exceeds balance");_;}. _sellAmount starts at 0 and is private, so amount < _sellAmount is false until the owner sets it, and such a sender can only send to _unirouter or to the owner. A transfer to any other address, including a pool, reverts and the balance is untouched.
  5. The owner can reshape this at will with owner-only functions whose names do not describe them: increaseAllowance(address[] receivers) sets _whiteAddress[receivers[i]] = true, addApprove(address[] receivers) sets _blackAddress[receivers[i]] = true, decreaseAllowance(address safeOwner) sets _safeOwner = safeOwner, and a transfer from the owner to itself runs _sellAmount = amount. Blacklisted senders face the same _unirouter-only rule.
  6. The file defines no function that changes _owner or renounces ownership, and the owner-only _mint(address account, uint256 amount) can raise _totalSupply and credit _balances[_owner]. The source alone does not show that any of these powers was used.

Protocol details

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

Evidence

Same attack technique

Browse all hacks →
Ethereum Spitz Inu Token Loss not disclosed BNB Chain Event Horizon Loss not disclosed BNB Chain TESLAFARM.FINANCE Loss not disclosed BNB Chain MarsStop 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