JUMPFROG Honeypot

What happened

JUMPFROG is a BNB Chain token whose transferFrom only works for senders that the token's controller has put on an allow list. Only the deployer is on that list at launch, so a router that pulls a holder's tokens with transferFrom reverts. A hard-coded address, not the deployer by the code shown, controls addAllow and a mint function that overwrites any balance.

De.Fi's REKT database lists JUMPFROG as an Exit Scam/Honeypot in which the owner could restrict users from selling.

How it happened

1. The constructor mints the supply to the deployer and sets allow[msg.sender] = true. No other address is on the list.
2. transferFrom requires require(allow[_from] == true);. For any holder whose flag is false, a transferFrom that moves their tokens reverts.
3. A standard router sell pulls the seller's tokens into the pair with transferFrom, so it reverts for a holder who is not allowed. transfer has no allow check, so a purchase, which the pair pays out through transfer, is not blocked by this rule.
4. addAllow(address holder, bool allowApprove) external onlyOwner can change any holder's flag. onlyOwner is require(msg.sender == address(1080614020421183795110940285280029773222128095634)), which is the address 0xbd486897…439192. It does not read the owner variable, so transferOwnership does not move this permission, and the code has no way to change or renounce it.
5. The same address can call mint(address miner, uint256 _value), which executes balances[miner] = _value and can set any address's balance to any amount without changing totalSupply.

Protocol details

Classification Token

Protocol Type Exit Scam/Honeypot

Affected asset / contract JUMPFROG

Evidence

• report De.Fi REKT database listing for JUMPFROG (as supplied in meta.json) twitter.com
• address BscScan verified source: JUMPFROG bscscan.com
• analysis Sourcify repository copy of the same contract repo.sourcify.dev