PepeSocks Honeypot

Reported loss Not disclosed
BNB Chain
Honeypot

What happened

PepeSocks (PEPE) is a token on BNB Smart Chain (420-token on-chain supply) whose transfers pass through a burnTokenCheck modifier. Unless the sender is the owner or the stored _safeOwner, is whitelisted by the owner, or is sending to the owner, a transfer succeeds only if it goes to the hard-coded _unirouter address or its amount is below _sellAmount (which is 0 until the owner sets it). Everything else reverts with "ERC20: transfer amount exceeds balance", whatever the holder's real balance.

The owner can also whitelist, blacklist, change _safeOwner and mint. De.Fi's REKT database lists the token as an Exit Scam/Honeypot dated 2021-03-05, saying the owner could disable the transfer function and so restrict selling. The code shows what the owner can do; it does not show which addresses were whitelisted or blacklisted.

How it happened

  1. The constructor sets _owner = owner; _safeOwner = owner; and mints the initial supply to the owner. _unirouter is hard-coded as 0x7a250d56…F2488D and _sellAmount starts at 0.
  2. transfer and transferFrom call _approveCheck, which carries the burnTokenCheck modifier. While _owner == _safeOwner, a transfer from the owner passes and moves _safeOwner to its recipient. After that, a transfer passes if the sender is _owner or _safeOwner, or the recipient is _owner.
  3. Otherwise a sender in _whiteAddress passes. A sender in _blackAddress passes only if recipient == _unirouter (the sender == _safeOwner half of that check cannot be true here, since _safeOwner already passed in step 2).
  4. A sender in neither list passes if amount < _sellAmount, and if the recipient is then _safeOwner the sender is moved to the blacklist. With _sellAmount at 0 this never holds, so the else branch runs: require((sender == _safeOwner)||(recipient == _unirouter), "ERC20: transfer amount exceeds balance"). An ordinary holder can therefore only send to _unirouter or _owner; any other recipient, including a pair contract that is not one of them, reverts the transaction and the holder keeps their tokens.
  5. The owner steers this with functions whose names suggest allowances: increaseAllowance(address[]) whitelists and un-blacklists, addApprove(address[]) blacklists and un-whitelists, decreaseAllowance(address safeOwner) sets _safeOwner, and multiTransfer whitelists the first approvecount receivers and sets their allowance to _unirouter to the maximum. _mint(address,uint256) is public and owner-only and credits _balances[_owner], so the owner can raise the supply. _sellAmount is set only by an owner transfer to itself that reaches the second branch (if (sender == _owner && sender == recipient){_sellAmount = amount;}).
  6. What happened: De.Fi's REKT database lists PEPE as a honeypot. The proof tweet could not be opened and no transaction was examined, so which addresses were whitelisted, blacklisted or blocked is not established.

Protocol details

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

Evidence

Same attack technique

Browse all hacks →
Ethereum Kylin Network Loss not disclosed BNB Chain Slime.Finance Loss not disclosed BNB Chain OxSocks Loss not disclosed BNB Chain RobotSwap 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