SafeWaifu Honeypot
What happened
SafeWaifu (WAIFU, 0xccceb834…d72bcf) stores an address in a variable called newun and refuses every transfer to it with the message "please wait". The first transferFrom call made while newun is empty sets newun to that call's destination. If that call is the router pulling tokens into a liquidity pool, as a liquidity add normally does, later sells into the pool revert.
The owner can also reassign newun with transfernewun. De.Fi's REKT database lists the token as an exit scam/honeypot, stating that the contract owner could disable the transfer function and restrict users from selling.
How it happened
- The constructor sets name
SafeWaifu, symbolWAIFU, 18 decimals and a supply of 10000000000000000000000000000 raw units, all credited to the deployer (balances[owner] = _totalSupply;). transferFrombegins withif(from != address(0) && newun == address(0)) newun = to;. The first call whilenewunis unset skips the check and stores its destination asnewun. A liquidity add by a router is atransferFrominto the pool, so the pool would be captured if that call comes first; the code itself does not name the pool.- From then on
transferFromrunselse require(to != newun, "please wait");andtransferrunsrequire(to != newun, "please wait");. Neither function exempts any sender, so every attempt to send tokens tonewunreverts, including a holder's sale ifnewunis the pool. - The check tests only the destination, so tokens leaving the pool to a buyer pass unless the buyer is
newun. transfernewun(address _newun)isonlyOwnerand can setnewunto any address. An unused address lifts the block. Setting it to the zero address re-arms the capture, because the nexttransferFromwith a non-zerofromstores its destination again.clearCNDAO()isonlyOwnerand sends the contract's own BNB balance to the caller.
Protocol details
Build your security review skills
Work through hands-on labs covering real exploit mechanics, review techniques, and defensive patterns.