MoonWhale Honeypot
What happened
De.Fi's REKT database lists MoonWhale (MOONWHALE) as an Exit Scam/Honeypot on BNB Smart Chain and says the owner could disable the transfer function, restricting users from selling. In the verified code, transfer is unrestricted but transferFrom, the call a router uses to pull tokens from a seller, requires allow[_from] == true. Only the deployer is whitelisted in the constructor, and only a hard-coded address can add other holders to the whitelist, so ordinary holders can receive tokens but cannot sell through an approval-based swap.
How it happened
- The constructor gives the whole supply to the deployer and whitelists it:
balances[msg.sender] = totalSupply;andallow[msg.sender] = true;. transferhas no whitelist check, so tokens can leave the deployer or a pool by plain transfer. A buyer can therefore receive tokens.transferFromadds a whitelist check on the account being debited:require(allow[_from] == true);. A holder who is not whitelisted can still callapprove, but anytransferFromspending that holder's balance reverts, which is the path a router uses when a holder sells.- Whitelisting is controlled by
addAllow(address holder, bool allowApprove) external onlyOwner, and the modifier ismodifier onlyOwner() {require(msg.sender == address(1080614020421183795110940285280029773222128095634));_;}. That constant is the address 0xbd486897…439192 in hex form, not theownervariable, and it differs from the deployer 0x6fca8885…AA2765. The code does not show who controls it. - Because
onlyOwnerignores theownervariable,transferOwnershiponly rewrites that variable and does not move the whitelist power, and there is norenounceOwnership. mint(address miner, uint256 _value)is also restricted to that address and setsbalances[miner] = _value;. It overwrites the balance and does not touchtotalSupply.
Protocol details
Build your security review skills
Work through hands-on labs covering real exploit mechanics, review techniques, and defensive patterns.