What happened
De.Fi's REKT database lists SHOPEEPAY (BNB Smart Chain contract 0x1dc7e2f8…af62f5) as an Exit Scam/Honeypot, noting that the contract owner could restrict holders from selling. In the verified source, transfer has no restriction, but transferFrom reverts unless the token's _from address is on an allow list. Swaps that have a router pull a seller's tokens go through transferFrom, so a holder who is not on the list cannot sell that way.
The list is edited by one hard-coded address rather than by the owner variable set in the constructor.
How it happened
- The constructor gives the whole supply to the deployer and lists only the deployer:
balances[msg.sender] = totalSupply;andallow[msg.sender] = true;. transfercarries no list check, so tokens can leave the pool to buyers:require(balances[msg.sender] >= _value);is the only gate besides the zero-address check.transferFromcarries the trap:require(allow[_from] == true);. Any holder whose address is notallow-listed, including every ordinary buyer, has the call revert when a router or other spender tries to move their tokens.- Only one address can change the list:
modifier onlyOwner() {require(msg.sender == address(1080614020421183795110940285280029773222128095634));_;}. That decimal literal converts to 0xbd486897…439192, which differs from the deployer 0x8BB6AF6c…81c221.addAllow(address holder, bool allowApprove)lets it list or delist any holder. Theownervariable is not used by the modifier, sotransferOwnershipdoes not change who holds this power. - The same address can call
mint(address miner, uint256 _value), which runsbalances[miner] = _value;. That overwrites a balance (up or down) without changingtotalSupplyor emitting aTransferevent.
No opened source shows that the hard-coded address actually called addAllow or mint; the code shows what it can do.
Protocol details
Build your security review skills
Work through hands-on labs covering real exploit mechanics, review techniques, and defensive patterns.
