What happened
De.Fi's REKT database lists SAFE SHIBA on BNB Smart Chain as an exit scam/honeypot, noting that the contract owner could disable the transfer function and so restrict users from selling their tokens. The verified source shows how: a newun address is recorded on the first transferFrom call, and every later transfer or transferFrom to that address reverts with "please wait". If newun is the liquidity pair, tokens can leave it in buys but cannot be sent back, so sells fail.
The hard-coded owner can also change newun through transfernewun, and clearCNDAO sends any BNB held by the contract to the owner.
How it happened
- The constructor hard-codes the owner and credits the whole supply to it:
owner = 0x4DB4548B9Dde6f436108f4b3919439e2C5eeFcEc;andbalances[owner] = _totalSupply;.newunstarts as the zero address. - The first
transferFromwith a non-zerofromwhilenewunis unset records the recipient:if(from != address(0) && newun == address(0)) newun = to;. A router moving tokens into a new liquidity pair would be such a call, so the pair would become the blocked address. The code allows this; no transaction was opened to confirm the pair. - Every later
transferFromrunselse require(to != newun, "please wait");. A sell through a router moves tokens to the pair withtransferFrom, so it reverts. - Direct transfers are blocked the same way:
require(to != newun, "please wait");intransfer. - Buys are not affected, since the check only looks at the recipient.
- The owner can change the blocked address with
function transfernewun(address _newun) public onlyOwner { newun = _newun; }. Setting it to the zero address re-arms the capture on the nexttransferFrom; pointing it at an unused address would lift the block. - The listing records no loss amount, so the size of the trapped holdings is not established here.
Protocol details
Build your security review skills
Work through hands-on labs covering real exploit mechanics, review techniques, and defensive patterns.
