delta.theta Honeypot

What the code allows:

1. The constructor sets the deployer as owner and credits it the whole supply: balances[owner] = _totalSupply;.
2. transferFrom begins with if(from != address(0) && newun == address(0)) newun = to; else require(to != newun, "please wait");. While newun is the zero address, the first transferFrom call stores its recipient in newun and skips the require. Which address that is depends on who makes that first call; if it is the liquidity-adding transfer into a DEX pair, the pair address is stored.
3. After that, transfer (require(to != newun, "please wait");) and transferFrom both revert for any recipient equal to newun. A holder selling through a pair stored as newun sends tokens to that pair, so the sale reverts, while buys, which move tokens out of the pair, are not blocked by this check.
4. transfernewun(address _newun) public onlyOwner lets the owner replace newun at any time. Setting it to the zero address re-arms the capture, because the next transferFrom call stores its recipient again; only pointing it at an address that is never a recipient lifts the block. transferOwnership / acceptOwnership can move that power to another address.
5. Separately, clearCNDAO() lets the owner send the BNB balance held by the token contract itself to the owner.

De.Fi's REKT database lists the token as an Exit Scam/Honeypot and says the owner could disable transfers so users could not sell. A security write-up opened for this review describes the same newun mechanism in other BSC tokens (SafeRocket, SafeBinance), not in this contract. The source alone does not show which address newun holds on-chain or any failed sale, so no transaction is cited.