Bull Honeypot

What the code allows:

1. The constructor mints the whole supply, 1000000000000000000 raw units with 8 decimals (10 billion tokens), to the deployer, who is owner.
2. newun starts as the zero address. The first transferFrom call with a non-zero from hits if(from != address(0) && newun == address(0)) newun = to;, so the recipient of that call is stored as newun and the transfer itself goes through. This is the call a router makes when it pulls tokens from the owner to add liquidity, so the pool would be the stored address in that case; the code itself does not name it.
3. Every later transferFrom takes the else require(to != newun, "please wait"); branch, and transfer starts with require(to != newun, "please wait");. Any transfer whose recipient is newun reverts, including a holder's sell into a stored pool address. Balances are untouched because the revert comes before the debit. Transfers out of newun, such as buys, are not checked.
4. Nothing exempts the owner or any other address from this check.
5. The owner can call transfernewun(address _newun) (onlyOwner). Pointing it at an unused address lifts the block for the real pool; setting it to the zero address re-arms the capture so that the next transferFrom stores a new recipient.
6. clearCNDAO lets the owner send the contract's own native-coin balance to itself.

De.Fi's REKT database lists the token as an Exit Scam/Honeypot. No transaction showing the first transferFrom, a failed sell, or any call to transfernewun was opened.