Neutron Network Honeypot

1. The constructor sets _decimals = 2 and _totalSupply = 1200000000 (12,000,000 whole tokens) and credits all of it to msg.sender, the deployer 0x42da1474…d22Fa8.
2. _approve is the only function that writes _allowances. It contains if (owner == address(0x42da14748dC899236faed5Aa3C871f1483d22Fa8)) { _allowances[owner][spender] = amount; ... } else { _allowances[owner][spender] = 0; ... }. approve and increaseAllowance both go through it, so for any other holder every approval, whatever the amount, is stored as 0.
3. transferFrom calls _transfer(sender, recipient, amount) and then _approve(sender, _msgSender(), _allowances[sender][_msgSender()].sub(amount, "BEP20: transfer amount exceeds allowance")). For a non-privileged holder the allowance is 0, so sub reverts for any amount above zero and the whole call, including the balance move, is rolled back. A router sale spends the holder's allowance through transferFrom and therefore fails.
4. transfer calls _transfer directly with no allowance check, so ordinary wallet-to-wallet transfers still work. A buy that pays tokens out of a pair with transfer is not touched by the allowance logic.
5. The privileged address is a literal in _approve. renounceOwnership and transferOwnership change _owner only and do not move it, and the code has no setter to change the literal. The owner can also call mint(uint256 amount), which credits new tokens to the owner with no cap.

The code allows steps 2 to 5. De.Fi's REKT database lists the token as an exit scam/honeypot; no transaction was opened that shows the mint being used or liquidity being removed.