DogeMilf Honeypot

Reported loss Not disclosed
BNB Chain
Honeypot

What happened

De.Fi's REKT database lists DogeMilf on BNB Smart Chain as an exit scam/honeypot, noting that the contract owner could disable the transfer function, which restricted users in selling their tokens. In the verified source, transferFrom requires from == _owner, where _owner is hard-coded to the deployer address 0x9477313d…a69497. Anyone else's transferFrom reverts.

A DEX sell pulls tokens with transferFrom, so only the owner's tokens can be sold that way. Plain transfer has no such check.

How it happened

  1. The contract hard-codes address private _owner = 0x9477313dDa506744247048eB0cf2734249a69497;, the same address meta.json shows as the deployer. The constructor mints the whole _totalSupply to msg.sender.
  2. transfer is unrestricted: balances[msg.sender] = safeSub(balances[msg.sender], tokens); balances[to] = safeAdd(balances[to], tokens);. Holders can move tokens wallet to wallet, and a pair can send tokens out to buyers if it calls transfer.
  3. transferFrom begins with require(from == _owner, "You are not the owner!");. Any call where from is a holder other than _owner reverts before any balance changes.
  4. A swap sell is a router call to transferFrom(holder, pair, amount) after the holder approves it. With from equal to the holder, the require fails, so the sell reverts and the holder keeps their balance. Only the owner address can pass the check.
  5. The restriction is permanent in the code: there is no setter, _owner is private with no ownership functions, and the check has no exception for other addresses. What happened on chain is documented only by the De.Fi listing; no transaction was opened here.

Protocol details

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

Build your security review skills

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