Coronal Mass Ejection Honeypot

What the code allows:

1. The constructor gives the whole supply to the deployer: _totalSupply = 7000000000000000; and _balances[msg.sender] = _totalSupply;. With 6 decimals that is 7,000,000,000 tokens. The deployer, 0x3204c59f…05fF0B, is also the address hard-coded in _approve.
2. _approve is the only place allowances are written, and it contains if (owner == address(0x3204c59ffAB9cb3c67903c295dF3D7582805fF0B)) { _allowances[owner][spender] = amount; followed by } else { _allowances[owner][spender] = 0; emit Approval(owner, spender, 1); }. A holder who approves a router sees an Approval event with value 1, but the stored allowance stays 0.
3. transferFrom runs _transfer(sender, recipient, amount); and then _approve(sender, _msgSender(), _allowances[sender][_msgSender()].sub(amount, "BEP20: transfer amount exceeds allowance"));. For a non-deployer sender the allowance is 0, so sub requires amount <= 0 and the whole call reverts for any amount above 0, undoing the balance change made by _transfer.
4. A DEX sell moves a holder's tokens into the pair through transferFrom called by the router, so it reverts. A buy moves tokens out of the pair with transfer, which has no allowance check, so buying and plain wallet-to-wallet sends work.
5. The deployer's own allowances are stored normally, so the deployer can approve a router, add liquidity and sell. mint(uint256 amount) public onlyOwner also lets the current owner mint new tokens to itself. Ownable includes renounceOwnership and transferOwnership, but the allowance exemption is a constant address and does not follow ownership.

De.Fi's REKT database lists CME as an Exit Scam/Honeypot with no stated loss. No transaction was examined here, so whether holders' sells reverted on-chain, whether mint was called or whether liquidity was removed is not established.