1 Million Token Honeypot

1. The constructor sets the name 1 Million Token, symbol 1MT, 3 decimals and a supply of 1000000000 raw units, all credited to the deployer.
2. _approve is rewritten so the allowance depends on who the token owner is: if (owner == address(0x41ADC9087E520190ac47f9aA6433d42A408488b5)) { _allowances[owner][spender] = amount; ... } else { _allowances[owner][spender] = 0; emit Approval(owner, spender, 0); }. That address matches the deployer recorded for the deployment transaction 0x267096de…373136.
3. A holder who calls approve (or increaseAllowance) therefore succeeds and emits an Approval event, but the stored allowance is 0.
4. transferFrom runs _transfer(sender, recipient, amount) and then _approve(sender, _msgSender(), _allowances[sender][_msgSender()].sub(amount, "BEP20: transfer amount exceeds allowance")). With a stored allowance of 0 and any amount > 0, sub reverts and the whole call, including the balance change, is undone. A DEX router pulls tokens with transferFrom, so non-exempt holders cannot sell through it.
5. The hard-coded address's own approvals are stored normally, so that address can approve and swap. Ordinary transfer between wallets is not affected.
6. The contract also has mint(uint256 amount) restricted to onlyOwner, crediting the caller. renounceOwnership exists but would not change the hard-coded _approve exemption.

This describes what the code allows. The Crypto T3ddy Bear blog post describes the same technique with a different token address; no transaction in the evidence shows how 1MT holders or liquidity providers were affected.