ValentineFloki Honeypot

What the code allows:

1. The constructor gives the whole supply to the deployer and whitelists the owner: _balances[_msgSender()] = _tTotal; and _isWhitelisted[owner()] = true;. There is no mint function, and tradingOpen starts as false.
2. Transfers where neither side is whitelisted are gated: if (!_isWhitelisted[sender] && !_isWhitelisted[recipient]) { then require(tradingOpen);. function openTrading(bool trueFalse) public onlyOwner sets that flag, so the owner can close trading for every non-whitelisted wallet. swapEnabled is set to true in the constructor and has no setter, so require(sender == uniswapV2Pair || recipient == uniswapV2Pair); always applies and non-whitelisted wallets can only trade with the pair.
3. On a sale (recipient == uniswapV2Pair) the code runs require(!_isBlacklisted[sender], "!Bot"); and require(!_isBlacklisted[_msgSender()], "!Bot");. Through a router, sender is the holder and _msgSender() is the router, so a blacklisted holder cannot sell and a blacklisted router would block every seller. Buys come from the pair (sender == uniswapV2Pair) and skip these checks, so a blacklisted wallet can still buy. The list is edited by function modifyBlacklist(address[] calldata wallet, bool trueFalse) external onlyWhitelist, so the owner or any wallet the owner has whitelisted can set it.
4. Balances move by exactly amount with no fee (_balances[sender] = _balances[sender].sub(amount);), so a blacklisted holder keeps a balance that cannot be sold while the pool still pays out to others.

, as listed by De.Fi's REKT database: 5. The deployer added initial liquidity with BNB, blacklisted users so they could not sell, and then removed the liquidity. The listing does not name how many wallets were blacklisted, and the blacklist calls were not opened in this review.