SafePOODLE Honeypot

Reported loss Not disclosed
BNB Chain
Honeypot

What happened

SafePOODLE (SAFEPOODLE) is a token on BNB Smart Chain at 0x545466b8…21aaab. Its transferFrom function requires allow[_from] == true, and the constructor sets that flag only for the deployer. Any other holder is blocked from transferFrom, the call a DEX router uses to pull tokens for a sale, unless the privileged account adds them with addAllow.

Plain transfer has no such flag. De.Fi's REKT database lists the token as an Exit Scam/Honeypot and says the contract owner could disable the transfer function, which restricted users in selling their tokens. No sale or liquidity transaction was opened, so how many holders were affected and how much was lost is not established.

How it happened

  1. The constructor, called by the deployer, sets balances[msg.sender] = totalSupply; and allow[msg.sender] = true;. No other address is given allow status at deployment.
  2. transferFrom contains require(allow[_from] == true); in addition to the balance and allowance checks. For a holder whose allow entry is false, every transferFrom that spends that holder's tokens reverts, even when the holder has approved the spender: approve sets allowed[msg.sender][_spender] = _value; normally, so the approval looks successful.
  3. A sale through a DEX router needs the router to call transferFrom on the holder's tokens, so it reverts for non-listed holders. transfer has only require(_to != address(0)); require(balances[msg.sender] >= _value);, so direct sends, and any pool payout made with transfer, are not affected.
  4. The onlyOwner modifier is require(msg.sender == address(1080614020421183795110940285280029773222128095634));, which is the fixed address 0xbd486897…439192. It is a different address from the deployer 0xe9F9CEa0…41139B that received the allow flag. transferOwnership only rewrites the unused owner variable, so the fixed address keeps these powers whatever owner holds.
  5. That fixed address can call addAllow(address holder, bool allowApprove) to set allow[holder] for any account, and mint(address miner, uint256 _value), which executes balances[miner] = _value;. This overwrites the target's balance with any chosen value, up, or down to zero, and does not change totalSupply.
  6. What happened: De.Fi's REKT database lists this token as an Exit Scam/Honeypot dated 2021-04-24. No transaction was opened showing a failed sale, an addAllow call, a mint call or a liquidity removal, so none is claimed.

Protocol details

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

Evidence

Same attack technique

Browse all hacks →
BNB Chain Atmosphere Loss not disclosed Ethereum Golden Retriever Loss not disclosed Ethereum Shibazilla Loss not disclosed Ethereum Jigstack.org Loss not disclosed

Build your security review skills

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

Start Free Trial Explore attack classes