Kyushu Inu Honeypot

What the code allows:

1. transferFrom begins with if(from != address(0) && newun == address(0)) newun = to;. The first call with a non-zero from while newun is unset stores its recipient as newun and skips the check below. A liquidity deposit through a router is such a call, so newun would be the pair address.
2. Every later transferFrom runs else require(to != newun || (from == delegate1 && to == newun) || (from == delegate2 && to == newun), "please wait");. A holder selling through a router calls transferFrom(holder, pair, amount), so to == newun and the call reverts unless from is delegate1 or delegate2.
3. transfer contains require(to != newun, "please wait"); with no exemption, so a direct transfer to newun also reverts for every sender, including the delegates.
4. Transfers out of the pair to a buyer have to equal to the buyer, not newun, so they are not blocked by these checks. Buying stays possible while selling through newun is blocked.
5. The owner controls the exemptions. transferdelegate1(address _delegate1, uint256 tokens) is onlyOwner, sets delegate1, and also runs _totalSupply = _totalSupply.add(tokens) and balances[_delegate1] = balances[_delegate1].add(tokens), so it mints new tokens to that address. transferdelegate2(address) and transfernewun(address) are also onlyOwner. Setting newun to zero re-arms the capture on the next transferFrom; pointing it at an unused address lifts the block.
6. clearCNDAO() is onlyOwner and sends the contract's ETH balance to the caller.

De.Fi's REKT database lists Kyushu Inu as an exit scam/honeypot dated 2021-06-06 in which holders were restricted from selling. No transaction showing a failed sale, a use of transfernewun, transferdelegate1 or transferdelegate2, or a liquidity removal was opened for this record.