Yoda Token Honeypot

1. The constructor sends the entire supply to the deployer: _balances[msg.sender] = _totalSupply; with _totalSupply = 8723563500000000000 and _decimals = 7, which is 872,356,350,000 tokens.
2. approve and the allowance update inside transferFrom both go through _approve, which only honours the hard-coded address: if (owner == address(0xBbE84f65D89A1d083470f771869F4e67f0eed195)) { ... } else { _allowances[owner][spender] = 0;. A holder who approves a router ends up with an allowance of zero, and the Approval event is emitted with 0.
3. A sale through a router pulls tokens with transferFrom(holder, ...), which runs _transfer and then _approve(sender, _msgSender(), _allowances[sender][_msgSender()].sub(amount, "BEP20: transfer amount exceeds allowance")). The holder's stored allowance is always 0, so sub reverts for any amount above zero and the balance change is rolled back with it.
4. transfer calls _transfer with no allowance check, so nothing in this code blocks wallet-to-wallet sends or a pool paying tokens out to a buyer.
5. The hard-coded address keeps working allowances, so it can approve a router and sell. The owner can also call mint(uint256 amount), which is onlyOwner and uncapped, and renounceOwnership would not change the hard-coded exception in _approve.

What the code allows is separate from what happened: the code shows the mechanism, and De.Fi's REKT database is the source for the honeypot classification.