unimex Honeypot
What happened
unimex is a BNB Smart Chain token whose transferFrom requires allow[_from] == true, a mapping that is set only for the deployer in the constructor and for other addresses through an owner-only addAllow. A holder who is not in the mapping cannot have tokens pulled by a router or pair, which is how a sale executes, while plain transfer carries no such check. De.Fi's REKT database lists the token as an exit scam/honeypot, stating that the contract owner could disable the transfer function, which restricted users in selling their tokens.
How it happened
- The constructor mints the full supply to the deployer and sets
allow[msg.sender] = true;, so only the deployer starts with permission fortransferFrom. transferchecks only the recipient and balance, so tokens can move wallet to wallet and out of a pool to a buyer.transferFromaddsrequire(allow[_from] == true);on top of the balance and allowance checks. A sale through a router is atransferFromfrom the holder, so it reverts for any holder whoseallowentry is false.addAllow(address holder, bool allowApprove)isexternal onlyOwner, so the permission can be switched on or off per address. The modifier isrequire(msg.sender == address(1080614020421183795110940285280029773222128095634)), a hard-coded address (0xbd486897…439192) that is not the constructor caller, so theownervariable andtransferOwnershipdo not affect it.mint(address miner, uint256 _value)is alsoonlyOwnerand setsbalances[miner] = _value;, overwriting that address's balance without changingtotalSupply.- No transaction was opened, so which holders were affected is not established by the code alone.
Protocol details
Build your security review skills
Work through hands-on labs covering real exploit mechanics, review techniques, and defensive patterns.