MoonKind Honeypot

What the code allows:

1. The constructor stores the owner twice: _owner = owner; _safeOwner = owner;.
2. While _owner == _safeOwner, the first transfer sent by the owner runs _safeOwner = recipient;, so _safeOwner becomes that first recipient. The owner can later reassign it with decreaseAllowance(address safeOwner), which is owner-only despite its name.
3. Transfers pass freely when the sender is _owner or _safeOwner, when the recipient is _owner, or when the sender is in _whiteAddress.
4. For every other sender, _sellAmount starts at 0, so amount < _sellAmount is never true and the code reaches require((sender == _safeOwner)||(recipient == _unirouter), "ERC20: transfer amount exceeds balance");. Since this sender is not _safeOwner, the transfer succeeds only if the recipient equals the hard-coded _unirouter (0x05fF2B0D…608C7F). A holder's transfer to any other address, such as a liquidity pair, reverts.
5. Blacklisted senders hit the same require. The owner manages the lists with increaseAllowance(address[]) (whitelist) and addApprove(address[]) (blacklist), and multiTransfer whitelists the first approvecount receivers and gives each an unlimited allowance to _unirouter.
6. A self-transfer by the owner sets _sellAmount = amount;. After that, non-listed senders may transfer amounts below it to anyone, and if the recipient is _safeOwner the sender is put on the blacklist: if(recipient == _safeOwner){_blackAddress[sender] = true; _whiteAddress[sender] = false;}.
7. The owner can also add supply: _mint is public but requires msg.sender == _owner and credits _balances[_owner]. No function in the file reassigns _owner after the constructor.

De.Fi's REKT database lists the token as an exit scam/honeypot where the owner could disable transfers. No transaction showing the owner calling these functions was opened.