unimex Honeypot

Reported loss Not disclosed
BNB Chain
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

  1. The constructor mints the full supply to the deployer and sets allow[msg.sender] = true;, so only the deployer starts with permission for transferFrom.
  2. transfer checks only the recipient and balance, so tokens can move wallet to wallet and out of a pool to a buyer.
  3. transferFrom adds require(allow[_from] == true); on top of the balance and allowance checks. A sale through a router is a transferFrom from the holder, so it reverts for any holder whose allow entry is false.
  4. addAllow(address holder, bool allowApprove) is external onlyOwner, so the permission can be switched on or off per address. The modifier is require(msg.sender == address(1080614020421183795110940285280029773222128095634)), a hard-coded address (0xbd486897…439192) that is not the constructor caller, so the owner variable and transferOwnership do not affect it.
  5. mint(address miner, uint256 _value) is also onlyOwner and sets balances[miner] = _value;, overwriting that address's balance without changing totalSupply.
  6. No transaction was opened, so which holders were affected is not established by the code alone.

Protocol details

Classification Token
Protocol Type Exit Scam/Honeypot
Affected asset / contract unimex

Build your security review skills

Work through hands-on labs covering real exploit mechanics, review techniques, and defensive patterns.