Sushi Finance Honeypot
What happened
Sushi Finance (SUSHI) is a BEP-20 token on BNB Smart Chain whose transfer functions reject any transfer to a stored address called newun. That address is set automatically by the first transferFrom call and can also be set by the owner, so once it points at the liquidity pair, sells routed to the pair revert with "please wait". De.Fi's REKT database lists the token as an Exit Scam/Honeypot and says the contract owner could disable the transfer function, which restricted users in selling their tokens.
De.Fi gives no loss figure.
How it happened
- The contract declares
address public newun;, which is the zero address after deployment. transfercontainsrequire(to != newun, "please wait");, so no transfer can go to thenewunaddress.transferFrombegins withif(from != address(0) && newun == address(0)) newun = to;. The first call made whilenewunis unset succeeds and stores its recipient asnewun. A blog post on this code pattern says that call is the one that adds liquidity on PancakeSwap, which makesnewunthe liquidity pair.- Every later
transferFromrunselse require(to != newun, "please wait");. A router sell pulls the holder's tokens to the pair withtransferFrom, so it would revert ifnewunis the pair. Buys send tokens out of the pair and are not blocked by this check. - The owner can change the block with
function transfernewun(address _newun) public onlyOwner. Settingnewunto the zero address makes the nexttransferFromstore a new recipient; pointing it at an unused address lifts the block. The source does not show whether or when the owner called it. - De.Fi's REKT database lists the token as Exit Scam/Honeypot. No transaction or loss amount was opened, so what holders actually lost 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.