DogeTeen Honeypot

What the code allows:

1. The owner (the deployer, 0x8FFd97F3…617d45) receives the whole supply in the constructor: balances[owner] = _totalSupply;.
2. transferFrom runs if(from != address(0) && newun == address(0)) newun = to; so the first transferFrom with a non-zero sender stores its recipient in newun. A liquidity add through a router calls transferFrom(owner, pair, amount), so the pair would be stored. That transfer itself succeeds.
3. After that, every call to transferFrom takes the else require(to != newun, "please wait"); branch, and every call to transfer runs require(to != newun, "please wait");. Any transfer whose recipient is the stored address reverts.
4. A holder's sell sends tokens to the pair (a router calls transferFrom(holder, pair, amount)), so it reverts. A buy moves tokens out of the pair with transfer(buyer, amount); the recipient is the buyer, not newun, so it passes. The same rule also blocks the owner from sending tokens to the pair again.
5. transfernewun(address _newun) public onlyOwner lets the owner overwrite newun at any time. Setting it to address(0) re-arms capture on the next transferFrom; pointing it at an unused address lifts the block for the pair. Owned has transferOwnership and acceptOwnership but no renounce function.
6. clearCNDAO() is onlyOwner and sends the contract's own BNB balance to the caller. It does not touch token balances.

De.Fi's REKT database lists DogeTeen as an Exit Scam/Honeypot with no stated loss. The transaction that stored newun and any call to transfernewun were not examined here, so whether the block was triggered or lifted on-chain is not established.