Pumpamental Honeypot

1. The constructor sets both control addresses to the address passed as the constructor's owner argument: _owner = owner; and _safeOwner = owner;. _sellAmount is initialised to 0, and the owner can add or remove addresses from _whiteAddress and _blackAddress.
2. transfer and transferFrom both call _approveCheck, which runs the modifier burnTokenCheck. While _owner == _safeOwner, the first transfer sent by the owner passes and moves _safeOwner to its recipient: if (_owner == _safeOwner && sender == _owner){_safeOwner = recipient;_;}.
3. After that, transfers from _owner or _safeOwner, and transfers whose recipient is _owner, pass. Whitelisted senders pass.
4. Every other sender reaches require((sender == _safeOwner)||(recipient == _unirouter), ...). Because _sellAmount is 0, the test amount < _sellAmount is never true, so such a sender can only send to _unirouter; a transfer to any other recipient reverts.
5. The owner decides who is exempt: increaseAllowance(address[] receivers) sets _whiteAddress to true and _blackAddress to false, addApprove does the reverse, and decreaseAllowance(address safeOwner) reassigns _safeOwner. These names do not change any ERC-20 allowance.
6. A self-transfer by the owner, once _safeOwner differs from _owner, sets _sellAmount = amount. From then on non-listed senders can send amounts below that value, and doing so with _safeOwner as the recipient marks the sender as blacklisted.
7. The owner can also mint: _mint is public, requires msg.sender == _owner and always credits _balances[_owner].

The code allows this; the sources opened for this entry do not include transactions showing which addresses were whitelisted or blacklisted, or what _safeOwner pointed to. The code has no function that changes or renounces _owner. The contract header lists a 3% liquidity fee and a 2% holder reward, but no function in the source applies a fee.