JetCombat Honeypot

Reported loss Not disclosed
BNB Chain
Honeypot

What happened

JetCombat (JetCombat, contract 0xa032fff2…7bdcdc on BNB Smart Chain) keeps an address newun and rejects every transfer whose recipient equals it. The first transferFrom call sets newun to its recipient, so if that call is the liquidity deposit, newun becomes the trading pair and later sales into the pair revert with "please wait" while buys still work. The owner can also overwrite newun with transfernewun.

De.Fi's REKT database lists JetCombat as an Exit Scam/Honeypot on 2021-04-12 and describes the owner as able to disable transfers so users could not sell.

How it happened

  1. The constructor sets symbol = "JetCombat"; and credits the whole supply to the deployer with balances[owner] = _totalSupply;.
  2. transferFrom runs if(from != address(0) && newun == address(0)) newun = to;. The first call with a non-zero from stores its recipient in newun and skips the check. If that call is the router moving tokens into the pool as liquidity is added, newun is the pair.
  3. Every later transferFrom takes the else require(to != newun, "please wait"); branch. A router sale, which calls transferFrom(holder, pair, amount), reverts while the pair is newun; transfer has the same require(to != newun, "please wait");.
  4. Buys are not affected: the pair pays out with transfer to the buyer, who is not newun.
  5. The owner can change the block with function transfernewun(address _newun) public onlyOwner. Pointing it at an unused address lifts the block; setting it to zero lets the next transferFrom capture a new recipient. The Owned contract has no renounce function.

Protocol details

Classification Token
Protocol Type Exit Scam/Honeypot
Affected asset / contract JetCombat

Build your security review skills

Work through hands-on labs covering real exploit mechanics, review techniques, and defensive patterns.