Post Malone Coin Honeypot

Reported loss Not disclosed
Ethereum
Honeypot

What happened

Post Malone Coin (MALONE) on Ethereum, contract 0x3445acc4…107e41, routes every transfer and transferFrom through a burnTokenCheck modifier that decides who may move tokens. Holders the owner has whitelisted pass freely, while everyone else, and anyone the owner blacklists, can only send tokens to the hard-coded Uniswap V2 router address 0x7a250d56…F2488D or to the owner. A swap on a router moves the seller's tokens to the pair, not to the router, so such a holder's sell reverts with ERC20: transfer amount exceeds balance.

De.Fi's REKT database lists this token as an exit scam/honeypot and says the contract owner could disable transfers, which restricted users from selling. This page does not show a transaction that proves which addresses were whitelisted or blacklisted.

How it happened

  1. The owner address is set in the constructor and _safeOwner starts equal to it (_owner = owner; _safeOwner = owner;). The constructor also calls _mint, which requires msg.sender == _owner, so the deployer 0x52e21B34…2d006a is the owner. The code has no function that changes or renounces _owner.
  2. Every transfer and transferFrom runs _approveCheck(...) burnTokenCheck(sender,recipient,amount). The first branch of the modifier is if (_owner == _safeOwner && sender == _owner){_safeOwner = recipient;_;}, so the first transfer sent by the owner makes its recipient the new _safeOwner. The owner can also assign it directly with decreaseAllowance(address safeOwner), which only the owner can call despite its ERC-20-sounding name.
  3. Privileged transfers pass: if (sender == _owner || sender == _safeOwner || recipient == _owner). Any holder can send to the owner, and the _safeOwner address can send to anyone.
  4. Everyone else is checked by list. if (_whiteAddress[sender] == true){ _; } lets whitelisted holders transfer anywhere. The owner adds addresses with increaseAllowance(address[] receivers) or through the first approvecount receivers of multiTransfer, which also pre-approves the router for them. addApprove(address[] receivers) does the reverse: it sets _blackAddress[receivers[i]] = true and clears the whitelist flag.
  5. A blacklisted sender hits require((sender == _safeOwner)||(recipient == _unirouter), "ERC20: transfer amount exceeds balance"). In a sell, the router calls transferFrom(holder, pair, amount), so sender is the holder and recipient is the pair. That is not _unirouter, so the call reverts and the holder's balance is not debited.
  6. A sender on neither list reaches if (amount < _sellAmount). _sellAmount starts at 0, so amount < 0 is never true and the same require runs. Once _safeOwner differs from _owner, the owner can set _sellAmount by sending tokens to itself (if (sender == _owner && sender == recipient){_sellAmount = amount;}). Transfers below that amount then pass, and if the recipient is _safeOwner the sender is moved onto the blacklist: if(recipient == _safeOwner){_blackAddress[sender] = true; _whiteAddress[sender] = false;}.
  7. What happened: De.Fi's REKT database lists the token as an exit scam/honeypot, dated 2021-06-02. No opened source shows which addresses were whitelisted, blacklisted or blocked, or how much was lost.

Protocol details

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

Evidence

Same attack technique

Browse all hacks →
BNB Chain NFTQR Loss not disclosed BNB Chain KingCorgi Loss not disclosed BNB Chain HolderFinance Loss not disclosed Ethereum SunDoge Inu 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