AstroPig Honeypot

What the code allows:

1. The constructor mints the whole supply to the deployer: balances[owner] = _totalSupply; with _totalSupply = 5000 * 10**5 * 10**3 and decimals = 3, which is 500,000,000 tokens. newun is never assigned in the constructor, so it starts as the zero address.
2. transferFrom begins with if(from != address(0) && newun == address(0)) newun = to; followed by else require(to != newun, "please wait");. The first transferFrom call with a non-zero from therefore stores its recipient in newun and skips the check. Which address that was on-chain is not shown by the source.
3. From then on, transferFrom(from, to, tokens) with to == newun reverts with "please wait" before balances[from] is debited, and transfer does the same through require(to != newun, "please wait");. Nothing exempts the owner or any other sender. A sale that moves tokens into the address stored in newun (for example a swap pair) fails; transfers to other addresses still work.
4. The owner can change the block at any time with function transfernewun(address _newun) public onlyOwner { newun = _newun; }. Pointing it at an unused address lifts the block for the old recipient. Setting it back to the zero address re-arms the capture, because the next transferFrom with a non-zero from would store that call's recipient in newun again.
5. clearCNDAO() is onlyOwner and sends the contract's own BNB balance to the owner: _owner.transfer(address(this).balance);. The contract accepts BNB through its payable fallback, function() external payable {}. The source has no renounce function; ownership moves only through transferOwnership followed by acceptOwnership by the new address.

De.Fi's REKT database classifies the token as an Exit Scam/Honeypot and says the owner could disable transfers so holders could not sell. The source alone does not show which address newun held, whether transfernewun was called, or any failed sale, and no transaction is cited.