Deflagration Honeypot
What happened
Deflagration (DEF) is a BNB Smart Chain token whose transferFrom function only works for holders that appear in an allow mapping. At deployment only the deploying address is added to that mapping, and the only function that can add more addresses, addAllow, is restricted to one address hard-coded in the onlyOwner modifier. A sale through a DEX router relies on transferFrom pulling tokens from the seller, so a holder who is not on the list cannot sell that way.
De.Fi's REKT database lists the token as an exit scam/honeypot and says the owner could disable the transfer function, which restricted users from selling.
How it happened
- The constructor sets
allow[msg.sender] = truefor the deployer only; every other address starts withallow[holder] == false. transferhas no such check, so plain wallet-to-wallet sends and the pool paying out tokens on a purchase are not gated by it.transferFrombegins withrequire(allow[_from] == true);, and the allowance and balance checks come before it. A router selling a holder's tokens callstransferFromwith the holder as_from, so the call reverts for any holder not on the list.- The list can only be edited by
addAllow(address holder, bool allowApprove) external onlyOwner. The modifier isrequire(msg.sender == address(1080614020421183795110940285280029773222128095634));, which is the hard-coded address 0xbd486897…439192, not theownerstorage variable set in the constructor. The deployer was 0xBCaC1D3E…aB01ED, a different address. - The same hard-coded address can also call
mint(address miner, uint256 _value), which setsbalances[miner] = _valuewithout changingtotalSupply. - The verified source shows these controls only; this draft does not establish which addresses were ever on the list, whether
addAllowormintwas called, or how much value holders lost.
Protocol details
Build your security review skills
Work through hands-on labs covering real exploit mechanics, review techniques, and defensive patterns.