KINGOFREFLECT Honeypot

1. The constructor mints the full supply to the deployer: _totalSupply = 1100000000000000000000000000; and balances[owner] = _totalSupply;, which is 1.1 billion tokens at 18 decimals.
2. newun starts empty. transferFrom begins with if(from != address(0) && newun == address(0)) newun = to; else require(to != newun, "please wait");. The first transferFrom therefore skips the check and stores its recipient as newun. If that first call is the liquidity deposit pulled by a router, newun becomes the pool address.
3. From then on both paths refuse that recipient: transfer has require(to != newun, "please wait"); and later transferFrom calls take the else branch with the same check.
4. A holder's sell through a router moves tokens into the pool with transferFrom, so it reverts when the pool is newun. Moves that go out to other addresses (for example transfer from the pool to a buyer) do not pass through this check.
5. The owner controls the switch: function transfernewun(address _newun) public onlyOwner { newun = _newun; }. Setting it to the zero address re-arms the capture, because the next transferFrom stores its recipient again; pointing it at an unused address lifts the block. The Owned base has transferOwnership and acceptOwnership but no renounce function.

The code shows what the owner can do; no opened transaction shows transfernewun being called or what newun currently holds.