BSCx500 Honeypot

1. The constructor mints _totalSupply = 1000000000000000000000000000000000 raw units (18 decimals, 10^15 tokens) to the owner, the deployer.
2. transfer begins with require(to != newun, "please wait");, so no direct transfer can go to the address stored in newun.
3. transferFrom begins with if(from != address(0) && newun == address(0)) newun = to; else require(to != newun, "please wait");. While newun is still empty, the first transferFrom stores its recipient as newun and goes through; every later transferFrom to that address reverts. A liquidity add through a router is a transferFrom to the pool, which is how the linked write-up says the pool address ends up in newun for tokens of this design; this record's code alone does not show which address newun holds, and it can be read with the public getter newun().
4. If newun is the pool, a sale through a router (a transferFrom from the holder to the pool) hits require(to != newun, "please wait") and reverts, while buys, where the pool is the sender, are not checked.
5. The owner can call transfernewun(address _newun) (onlyOwner) to set newun to any address. Pointing it at an unused address lifts the block for the pool; setting it to zero re-arms the capture, because the next transferFrom from a non-zero address writes its recipient into newun.

The code allows this trap; the sources opened here do not show who held the liquidity or any liquidity removal.