StudToken Honeypot
What happened
De.Fi's REKT database lists StudToken (STUD, BNB Smart Chain contract 0x52573494…cab0af) as an Exit Scam/Honeypot, noting that the contract owner could restrict holders from selling. The verified source has an owner-only switch, setPanCakeSwapReciever, that flags an address as a no-sell destination. Every transfer into a flagged address reverts with "Error: Can not sell this token", so a sale into a flagged pool fails.
How it happened
- The constructor mints the supply to the deployer:
_transferTO(msg.sender, 30000000000e18);, which is 30 billion tokens at 18 decimals. - The owner can flag any address:
function setPanCakeSwapReciever(address _recipient, bool _feeless) public onlyOwner { ... PanCakeSwapReciever[_recipient] = _feeless; }. Nothing in the code restricts which address it is, so it can be a liquidity pool. - Every
transferandtransferFromruns_transfer, which callscalculateFeesBeforeSend(sender, recipient, amount). That function containsif(PanCakeSwapReciever[recipient]){ revert("Error: Can not sell this token"); }. - The revert undoes the whole call, including the earlier
_balances[sender] = _balances[sender].sub(...)line, so the seller's balance is untouched and the sale simply fails. The check looks at the recipient only, so any transfer into a flagged address fails regardless of who sends it; the owner has no exemption in this function. - The flag can be turned off again with the same function and
false.renounceOwnershipexists inOwnable, which would freeze the flag at its current value.
The code shows what the owner can do; no opened transaction shows setPanCakeSwapReciever being called or which address was flagged.
Protocol details
Build your security review skills
Work through hands-on labs covering real exploit mechanics, review techniques, and defensive patterns.