The fee split only burns a portion when burning is enabled. If fees are turned on with a full burn share while burning is disabled and the fee recipient is the zero address, the fee is neither burned nor collected. It simply stays with the sender while the receiver gets less than the sent amount. The outcome is a silent shortfall to the receiver and an uncollected fee. The setter permits this combination because a full burn share is allowed to have a zero recipient.

Blocking ownership transfer prevents handing ownership to a new address, but the standard renounce function is not covered by the same guard. After ownership transfer has been blocked, the owner can still renounce and set the owner to the zero address. That permanently disables every administrative function and freezes the current configuration, which is a very different outcome from what the block appears to promise.

The signing domain used for permit is fixed to the name provided at initialization, while the token name can later be changed through the metadata setter. After a rename, the value returned by the name getter no longer matches the permit signing domain. Wallets and tools that build the domain from the current name will then produce signatures that fail to validate. On the live deployment the metadata is locked, so it does not occur there, but a token that keeps metadata mutable is exposed.

The router address can be set to the zero address with no validation. Separately, turning off a market-maker pair sets the pair flag to false but leaves the fee, limit, cooldown, and anti-dump exemptions that were granted when the pair was added. A former pair address therefore keeps bypassing limits and fees even though it is no longer treated as a pair.

Several mode selectors are stored as small integers without range checks, including the whitelist mode, the anti-dump type, the dead-block mode, and the batch access and fee modes. Out-of-range values silently change behavior. For example, an unexpected batch access value leaves the batch function open to the public, and an unexpected dead-block mode disables the protection the deployer intended to enable.

The freeze functions for fees, limits, cooldown, and anti-dump only lock the rate and threshold setters. They do not lock the per-address exemption maps, and designating a market-maker pair still grants that pair every exemption. After a module is frozen, the owner can still change who is subject to it by toggling exemptions or by adding a new pair. The global rates and limits stay fixed, so the residual power can only relax the rules for chosen addresses or place a previously exempt address back under them, but it undercuts the immutability that a freeze appears to promise. The blacklist freeze does not have this gap because there is no blacklist exemption map.

The pre-trading router protection reverts only when the sender or the recipient of a token transfer equals the configured router address. In a standard exchange swap the router is the caller that moves tokens between the user and the pair, so it is never itself the sender or recipient of the token transfer. The check therefore does not stop swaps routed through that router; it only catches direct transfers to or from the router address. On the live token the router is unset, so the control is inert, and the real pre-trading control is the exempt-counterparty gate rather than this check.

The batch skip-fee path moves tokens by calling the low-level update directly, which skips the zero-recipient check that the normal transfer path enforces. A caller can pass the zero address as a recipient and burn their own tokens through the batch function, even when burning has been disabled for the token. The tokens burned are the caller's own, so there is no direct loss to others, but it breaks the guarantee that burning is off and the expectation that a plain transfer never reduces total supply. It is reachable by the public only when batch fee-skipping is open to non-owners, and it shares its root cause with the pause bypass.

The owner can add any address to a blacklist that blocks it from sending or receiving tokens. Blacklisted balances are not slashed, but the funds become non-transferable for as long as the entry stands, which is a strong control over user funds. On the live deployment the blacklist has been frozen, so no new addresses can be added, but any entries made before the freeze remain in effect.