HighQuality Swap Honeypot

1. The constructor gives the whole supply to the deployer and leaves newun at the zero address.
2. In transferFrom, the line if(from != address(0) && newun == address(0)) newun = to; stores the recipient of the first such call as newun, with no check on that call. If that call is the liquidity-adding transfer into a pool, newun becomes the pool address.
3. Every later call hits require(to != newun, "please wait");, in transfer and in the else branch of transferFrom. The check has no exception for the owner or any other address.
4. A holder who sells through a router approves it and the router calls transferFrom(holder, pool, tokens). If newun is the pool, to == newun and the call reverts, while transfers to any other address still work.
5. transfernewun(address _newun) is onlyOwner, so the owner can move newun to an unused address (lifting the block) or back to the zero address (the next transferFrom then stores a new recipient). Which of these was ever done is not shown by the code.

The same code pattern is described, for other BNB Smart Chain tokens, as a way of blocking sells into the liquidity pool by an independent write-up; that write-up does not name this token, and no transaction for this token was opened, so what happened to holders is not established here.