RapidSwap Honeypot

1. The constructor mints the whole supply to the deployer: _totalSupply = 100000000000000000000000000; and balances[owner] = _totalSupply;. A public variable address public newun; starts at the zero address.
2. In transferFrom, the first call made while newun is unset runs if(from != address(0) && newun == address(0)) newun = to;. That call is not checked against anything, and it records its recipient to in newun. The blog post describes this as the first add-liquidity transaction, so that newun becomes the pool; the supplied code does not itself say which address was recorded.
3. After that, every transferFrom takes the else branch: else require(to != newun, "please wait");. The plain transfer function has the same check on every call: require(to != newun, "please wait");. Neither function exempts the owner or any other sender.
4. A swap of tokens for BNB sends the tokens to the pool. If the pool is newun, that transfer reverts with "please wait", so holders cannot sell. Transfers to any other address, and transfers out of newun, are not blocked by these checks.
5. The owner can change the target with transfernewun(address _newun) public onlyOwner. Setting it to the zero address makes the next transferFrom capture its recipient again, so the block comes back; pointing it at an address that never receives tokens lifts the block. The owner can also run clearCNDAO() (onlyOwner), which sends the contract's own BNB balance to the caller.

The code allows this behaviour. The sources opened show no transaction proving which address newun held or when the owner changed it, so what actually happened to holders rests on De.Fi's listing.