BaTorrent Honeypot

1. The constructor mints the full supply to the deployer: _totalSupply = 500000000000000000000000000; with decimals = 18, which is 500,000,000 tokens.
2. transfer refuses any send to the newun address: require(to != newun, "please wait");. There is no exception for the owner or any whitelist.
3. transferFrom, the call a router uses to pull a seller's tokens, starts with if(from != address(0) && newun == address(0)) newun = to; else require(to != newun, "please wait");. While newun is unset, the first call stores its recipient in newun and succeeds; every later call to that recipient reverts. The seed blog post describes this as newun becoming the PancakeSwap pair during the initial liquidity add; the code alone does not show which address newun holds on-chain.
4. If newun is the pair, a holder's sale reverts at require(to != newun, ...), while a buy is paid out by the pair through transfer to the buyer's address, which passes the check.
5. transfernewun(address _newun) public onlyOwner lets the owner change newun at will. Setting it to zero re-arms the capture by the next transferFrom recipient, and pointing it at an address that is never used lifts the block for every sender, so the restriction is under the owner's control rather than permanent.
6. clearCNDAO() is onlyOwner and sends the contract's own BNB balance to the caller; it does not touch holders' token balances.

What the code allows is separate from what happened: the code shows the mechanism, and De.Fi's REKT database is the source for the honeypot classification.