PigMOON Honeypot

1. The constructor mints the whole supply to the deployer: balances[owner] = _totalSupply; with _totalSupply = 1000000000000000000000000000000000.
2. transferFrom begins with if(from != address(0) && newun == address(0)) newun = to;. While newun is unset, the first transferFrom whose sender is non-zero writes its recipient into newun. A liquidity add through a router is a transferFrom into the pair, so the pair can end up stored there; the code does not name the pair, and the linked write-up describes this capture of the pool address.
3. Once newun is set, every later transferFrom takes the else require(to != newun, "please wait"); branch, and transfer runs require(to != newun, "please wait");. A router sell moves tokens with transferFrom(holder, pair, amount), so with the pair stored in newun it reverts, while a buy (the pair calling transfer to the buyer) does not touch the check.
4. The owner can change the blocked address at any time with function transfernewun(address _newun) public onlyOwner. Pointing it at an unused address lifts the block for everyone; setting it to the zero address makes the next transferFrom capture a new recipient. Ownership has no renounce function, only transferOwnership and acceptOwnership.
5. PigMOON.clearCNDAO() sends the contract's own BNB balance to the owner. This is separate from the token block, and the code does not show that any BNB was ever sent to the contract.

What the code allows is shown above. De.Fi's REKT database lists the token as a honeypot; no transaction opened for this draft shows the owner calling transfernewun or any holder's failed sell.