SafeAtmosphere Honeypot

1. The constructor mints _totalSupply = 100000000000000000000 to owner, the deployer. With decimals = 8 that is 1,000,000,000,000 whole tokens.
2. newun starts as the zero address. transferFrom begins with if(from != address(0) && newun == address(0)) newun = to;, so the first transferFrom call with a non-zero from stores its recipient in newun and goes through. A router-based liquidity add moves tokens into the pair with transferFrom, so in that flow the pair would be recorded. The linked write-up describes exactly this pattern for other tokens.
3. From then on, transferFrom runs else require(to != newun, "please wait"); and transfer runs require(to != newun, "please wait");. Any transfer whose recipient is newun reverts before the balance lines run, so the holder is never debited. If newun is the pair, a router sale (tokens moved to the pair) reverts, while transfers to every other recipient, including the pair paying out a buy, are not touched by these lines.
4. The owner can call transfernewun(address _newun) (onlyOwner) to set newun to any address. Pointing it at an unused address lifts the block. Setting it to the zero address re-arms the capture, because the next transferFrom with a non-zero from writes its recipient into newun.
5. The code has no renounceOwnership. transferOwnership and acceptOwnership can hand the owner role to another address.

The code allows steps 3 and 4; whether newun held the pair address, and whether the owner ever called transfernewun, is not shown by the source. De.Fi's REKT database lists the token as an exit scam/honeypot.