FairSatoshi Honeypot
What happened
FairSatoshi (0x97dc4d9d…154422) is a BNB Smart Chain token whose transferFrom only works for holders that appear in an allow mapping. The mapping is false for every address except the deployer, so an approval-based sale such as a router swap reverts for ordinary holders, while plain transfer calls still work. The only address that can add holders to the mapping is a hard-coded address, not the owner variable.
De.Fi's REKT database lists the token as an exit scam/honeypot, stating that the contract owner could disable the transfer function and restrict users from selling.
How it happened
- The constructor sets
owner = msg.sender;, gives the whole supply to the deployer withbalances[msg.sender] = totalSupply;and whitelists only that address withallow[msg.sender] = true;. transferhas no whitelist check, so a holder can still send tokens straight to another address.transferFrom, the function a DEX router calls to pull tokens from a seller, containsrequire(allow[_from] == true);.allowisfalsefor every ordinary holder, so the call reverts.- The
onlyOwnermodifier isrequire(msg.sender == address(1080614020421183795110940285280029773222128095634)), which is the hard-coded address 0xbd486897…439192. That address can calladdAllow(address holder, bool allowApprove)to switch any holder on or off. It is different from the deployer address, andtransferOwnershiponly rewrites the unusedownervariable, so it does not move this power. - The same hard-coded address can call
mint(address miner, uint256 _value), which runsbalances[miner] = _value;. This overwrites any balance without changingtotalSupply. - The header comment advertises a 2% liquidity lock, 2% holder distribution and burnt LP. The code contains no fee, reflection or liquidity logic, and no function to change the hard-coded address.
Protocol details
Build your security review skills
Work through hands-on labs covering real exploit mechanics, review techniques, and defensive patterns.