SAFEORACLE Honeypot

What happened

SAFEORACLE is a BEP-20 token whose transferFrom reverts unless the token holder is on an allow list that starts with only the deployer. Selling through a DEX router uses transferFrom, so non-listed holders cannot sell, while transfer carries no such check. A hard-coded address, not the stored owner, controls addAllow and mint.

The source header advertises "100% ANTI RUG SYSTEM" and "100% Liquidity Burn"; the code contains no liquidity logic. De.Fi's REKT database lists the token as an exit scam/honeypot in which the contract owner could disable the transfer function and restrict users from selling.

How it happened

1. The constructor gives the whole supply to the deployer and whitelists only that address: balances[msg.sender] = totalSupply; allow[msg.sender] = true;.
2. transferFrom includes require(allow[_from] == true);, so for any holder not on the list the call reverts. A router sale pulls tokens from the holder with transferFrom.
3. transfer has no allow check, so a pair sending tokens out to a buyer with transfer is not stopped by this rule. The code does not show which address was the pair.
4. modifier onlyOwner() {require(msg.sender == address(1080614020421183795110940285280029773222128095634));_;} hard-codes the controller, 0xbd486897…439192 in hexadecimal. transferOwnership only rewrites the unused owner variable.
5. That address can call addAllow(address holder, bool allowApprove) to change any holder's flag, and mint(address miner, uint256 _value), which runs balances[miner] = _value;, overwriting a balance without changing totalSupply.
6. What happened: the code does not show any call to addAllow or mint. Only De.Fi's REKT database listing supports the honeypot classification.

Protocol details

Classification Token

Protocol Type Exit Scam/Honeypot

Affected asset / contract SAFEORACLE

Evidence

• report @Token_Sniffer incident report twitter.com
• address BscScan verified source, SAFEORACLE bscscan.com
• analysis Sourcify match, chain 56 repo.sourcify.dev