Betelgeuse Honeypot

1. The constructor mints the whole supply (_totalSupply = 50000000000, 3 decimals, so 50,000,000 tokens) to msg.sender, the deployer.
2. _approve branches on who is approving: if (owner == address(0x08E88f5E72484Fbf99Ed2ab87c0f1d0894d4BeC9)) { _allowances[owner][spender] = amount; ... } else { _allowances[owner][spender] = 0; emit Approval(owner, spender, 0); }. The deployer's approvals are stored; every other holder's approval, including one made to a router, is silently set to 0 while the event reports 0.
3. transferFrom runs _transfer and then _approve(sender, _msgSender(), _allowances[sender][_msgSender()].sub(amount, "BEP20: transfer amount exceeds allowance")). For a non-deployer sender the stored allowance is always 0, so sub reverts for any amount above 0 and the whole transfer is undone.
4. A holder who tries to sell through a router, which pulls tokens with transferFrom, therefore fails. transfer only calls _transfer and never reads allowances, so receiving or moving tokens directly still works.
5. The deployer is exempt: its approvals are recorded, so it can approve a router and use transferFrom. The owner can also call mint(uint256 amount) (onlyOwner) to create more tokens for itself.

The code allows this one-way trap; the sources opened here do not show a transaction of the deployer selling or removing liquidity.