UnoRe Honeypot

Reported loss Not disclosed
Ethereum
Honeypot

What happened

UnoRe (UNO) is an Ethereum token whose transfer and transferFrom both run through a burnTokenCheck modifier that the owner can steer. In the verified source, a holder who is not whitelisted can only send tokens to the _unirouter address or to _owner; a transfer to any other recipient reverts with "ERC20: transfer amount exceeds balance", and the owner can whitelist or blacklist addresses and change _safeOwner. De.Fi's REKT database lists the token as an Exit Scam/Honeypot dated 2021-04-24, saying the owner could disable the transfer function, which restricted users in selling their tokens.

The listing gives no loss amount, and the code alone does not show whether any holder was blocked.

How it happened

  1. The constructor sets _owner = owner; and _safeOwner = owner;, then mints the initial supply to the owner. _mint is public and only checks require(msg.sender == _owner, ...), so the owner can mint more to itself. No function in the contract changes _owner afterwards.
  2. Every transfer and transferFrom goes through _approveCheck, which carries the burnTokenCheck modifier. While _owner == _safeOwner, the owner's first outgoing transfer runs if (_owner == _safeOwner && sender == _owner){_safeOwner = recipient;_;}, so _safeOwner becomes that transfer's recipient. The code does not show who that recipient is.
  3. Senders that pass freely: _owner, _safeOwner, any sender sending to _owner (if (sender == _owner || sender == _safeOwner || recipient == _owner)), and any address with _whiteAddress[sender] == true.
  4. Every other holder reaches if (amount < _sellAmount). _sellAmount is initialised to 0, so this is false for every amount and execution falls to require((sender == _safeOwner)||(recipient == _unirouter), "ERC20: transfer amount exceeds balance");. The transfer succeeds only if the recipient is the _unirouter address 0x7a250d56…F2488D (or _owner, handled in step 3); any other recipient reverts, and the holder's balance is not debited. A blacklisted sender hits the same require. Whether a liquidity pair is one of the allowed recipients is not shown by the code.
  5. The owner controls who is exempt: increaseAllowance(address[]) sets _whiteAddress = true and _blackAddress = false, addApprove(address[]) does the reverse, multiTransfer whitelists the first approvecount recipients and approves the router for them, and decreaseAllowance(address safeOwner) reassigns _safeOwner. An owner self-transfer (if (sender == _owner && sender == recipient){_sellAmount = amount;}) can set _sellAmount; once it is above 0, holder transfers below that amount pass, and if the recipient equals _safeOwner the sender is added to _blackAddress.

Protocol details

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

Evidence

Same attack technique

Browse all hacks →
Ethereum 1MILNFT Loss not disclosed Ethereum German Shepherd Loss not disclosed Ethereum Monkey Island Loss not disclosed Ethereum Safe Sex 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