PirateElon Honeypot

What happened

PirateElon is a BNB Smart Chain token whose transferFrom accepts calls only when the token owner is the from address. De.Fi's REKT database lists it as an exit scam/honeypot and states that the owner could disable the transfer function, which restricted users in selling their tokens. In the code there is no switch: the restriction is permanent and hard-coded.

Plain transfer between wallets is unrestricted, but a sale through a router that pulls tokens with transferFrom from a holder fails.

How it happened

1. The constructor sets the supply to the deployer: balances[msg.sender] = _totalSupply;. A hard-coded address is stored as the owner: address private _owner = 0xCd2Bb8358e739b4dDb4ccE55eDFd222bc7Df2E24;, which equals the deployer address in the deploy transaction.
2. transfer has no restrictions: it subtracts from msg.sender and adds to to.
3. transferFrom starts with require(from == _owner, "You are not the owner!");. For any other holder it reverts, whatever allowance the holder has granted.
4. A router-based sale calls transferFrom(holder, pair, amount). For a holder other than _owner that call reverts, so the holder cannot sell into a pool. The owner address can move tokens through transferFrom.
5. There is no setter for _owner and no function that changes the check, so the code contains no way to lift the restriction. Whether any holder tried to sell, and the amounts involved, are not shown by the source.

Protocol details

Classification Token

Protocol Type Exit Scam/Honeypot

Affected asset / contract PirateElon

Evidence

• address BscScan verified source, PirateElon (CodeWithJoe) bscscan.com
• analysis De.Fi REKT database entry for PirateElon (proof link: Token Sniffer, 403 when fetched) tokensniffer.com
• analysis Sourcify repository, chain 56 repo.sourcify.dev