SafeCookie Honeypot

What happened

SafeCookie's transfer and transferFrom revert with "please wait" whenever the recipient equals a stored address called newun. That address is set automatically by the first transferFrom call that has a non-zero sender, and the owner can overwrite it at any time with transfernewun. Whichever address newun points at can no longer receive tokens through these functions, so if it is a liquidity pair, holders cannot sell into it.

De.Fi's REKT database lists SafeCookie as an exit scam/honeypot in which the owner could disable the transfer function, restricting users from selling.

How it happened

1. The constructor mints the whole supply to the deployer: balances[owner] = _totalSupply;.
2. transfer starts with require(to != newun, "please wait");, so no transfer can end at the newun address.
3. In transferFrom, if(from != address(0) && newun == address(0)) newun = to; else require(to != newun, "please wait"); locks in the recipient of the first non-zero-sender transferFrom as newun. That first call itself succeeds.
4. The write-up at cryptot3ddybear.gitlab.io describes the same pattern: when the first transferFrom is the liquidity add, the pair becomes newun, buyers can still receive tokens from it, and sells that send tokens back to the pair revert. This record's code does not show which address ended up in newun.
5. The owner can change newun with transfernewun(address _newun). Setting it to address(0) lets the next transferFrom capture a new recipient; pointing it at an unused address lifts the block.
6. A reverted sell does not debit the holder: the balances[from].sub(tokens) line runs after the require, so the tokens stay in the holder's wallet but cannot be sold into the blocked address.

Protocol details

Classification Token

Protocol Type Exit Scam/Honeypot

Affected asset / contract SafeCookie

Evidence

• report @Token_Sniffer incident report twitter.com
• report De.Fi REKT database listing (proof: Token Sniffer tweet 1381346761566916614, not retrievable) twitter.com
• address BscScan code page for 0x1766fed4b4ad09c5a31afe6e7c58607a537b4b97 bscscan.com
• analysis Sourcify copy of the same contract repo.sourcify.dev
• analysis Scam explained: BSC stealthy LP block cryptot3ddybear.gitlab.io