What happened
PurpleGoat (PURPL) is a BNB Smart Chain token whose code can refuse every transfer to one chosen address. The transferFrom function stores the recipient of the first call that runs while newun is unset, and from then on reverts any transfer to that address with "please wait". On a DEX, selling means sending tokens to the liquidity pair, so if newun holds the pair's address, holders can still receive tokens on a buy but cannot sell them.
The owner can also set newun to any address through transfernewun. De.Fi's REKT database lists PURPL as an exit scam / honeypot where the contract owner could disable the transfer function, which restricted users in selling their tokens.
How it happened
- The contract declares
address public newun;and the owner-only setterfunction transfernewun(address _newun) public onlyOwner { newun = _newun; }. - In
transferFrom, the first call made whilenewunis unset runsif(from != address(0) && newun == address(0)) newun = to;. That call succeeds and records its recipient asnewun. A write-up of the same code pattern says this recipient is the liquidity pair when the first liquidity is added. - Every later
transferFromtakes theelse require(to != newun, "please wait");branch, andtransferalso starts withrequire(to != newun, "please wait");. A transfer whose recipient isnewunreverts, so no balances change. - A DEX sell pulls the holder's tokens to the pair with
transferFrom, so ifnewunis the pair the sell reverts. Buys send tokens from the pair to the buyer, whose address differs fromnewun, so they are not affected by this check. - The owner can call
transfernewunto pointnewunat another address. Setting it to the zero address re-arms the capture on the nexttransferFrom; setting it to an unused address lifts the block. The code has norenounceOwnership, only a two-steptransferOwnership/acceptOwnership.
Protocol details
Evidence
Build your security review skills
Work through hands-on labs covering real exploit mechanics, review techniques, and defensive patterns.
