What happened
This "Toko Token" (TKO) contract on BNB Chain uses a sell-blocking transfer template. Every transfer and transferFrom runs the burnTokenCheck modifier: the owner, the _safeOwner address and owner-whitelisted wallets can move tokens freely, while any other sender is rejected unless the recipient is the hard-coded PancakeSwap V1 router address. A PancakeSwap sale sends tokens to the pair, not the router, so it reverts with a fake ERC20: transfer amount exceeds balance error.
The owner also controls whitelist and blacklist setters disguised as increaseAllowance and addApprove, can repoint _safeOwner through decreaseAllowance, and can mint unlimited tokens through a public _mint. De.Fi's REKT database lists the token as an exit scam/honeypot.
How it happened
- The constructor sets both
_ownerand_safeOwnerto the owner argument and mints the supply to it. - The first transfer the owner makes while
_owner == _safeOwnerreassigns_safeOwner = recipient, giving that recipient unrestricted sending rights; the owner can later change it again withdecreaseAllowance(address safeOwner). _sellAmountstarts at0, so for a holder who is neither whitelisted nor blacklistedamount < _sellAmountis false and the transfer only succeeds ifsender == _safeOwnerorrecipient == _unirouter.- Selling through PancakeSwap moves the holder's tokens to the pair contract, so neither condition holds and the sale reverts with a message that imitates an insufficient balance.
- The owner can whitelist wallets through
increaseAllowanceormultiTransfer, blacklist them throughaddApprove, open a narrow window by transferring to itself (which sets_sellAmount), and mint any amount to itself through_mint.
Protocol details
Build your security review skills
Work through hands-on labs covering real exploit mechanics, review techniques, and defensive patterns.
