What happened
JaguarMOON (JAMOON) on BNB Smart Chain keeps an address in a variable called newun and rejects every token transfer sent to it. transfer reverts when the recipient is newun, and transferFrom does the same once newun is set. A DEX sell moves tokens from the seller to the liquidity pair through transferFrom, so if newun holds the pair address the sale reverts with the message "please wait".
newun is filled in automatically by the first transferFrom call made while it is empty, and the owner can also set it with transfernewun. De.Fi's REKT database lists JaguarMOON as an Exit Scam/Honeypot dated 2021-05-04 and describes it as a token whose owner could disable the transfer function, restricting users from selling.
How it happened
- The constructor mints the whole
_totalSupplytoowner, which is the deployer:balances[owner] = _totalSupply;. newunstarts as the zero address. The firsttransferFromwith a non-zerofromstores its recipient without any check:if(from != address(0) && newun == address(0)) newun = to;. The code does not say who that first recipient is; a router-based liquidity add would send tokens to the pair throughtransferFrom, which is the pattern a public write-up of this template describes.- From then on,
transferFromreverts for any recipient equal tonewun:else require(to != newun, "please wait");. Plaintransfercarries the same check:require(to != newun, "please wait");. - A DEX swap that sells the token pulls it from the seller into the pair with
transferFrom. Ifnewunis the pair, that call reverts, so the sale fails while transfers between ordinary wallets still work. - The owner can change the target at any time with
function transfernewun(address _newun) public onlyOwner. Setting it to the zero address re-arms the capture on the nexttransferFrom; pointing it at an unused address lifts the block. Nobody else can call it.
Protocol details
Build your security review skills
Work through hands-on labs covering real exploit mechanics, review techniques, and defensive patterns.
