Whitelist primitives (`add_to_whitelist` et al.) are unenforced dead code

[Ejirowebfi]

🔴 Critical · contracts/token-factory/src/lib.rs:210-243

Description

add_to_whitelist, remove_from_whitelist, and is_whitelisted fully implement an admin-gated address allow-list backed by instance storage. Grepping the rest of lib.rs shows no call site reads is_whitelisted or the underlying storage key anywhere else in the contract — create_token, create_tokens_batch, mint_tokens, and every other entrypoint are reachable by any address regardless of whitelist state. This is either an incomplete feature (the enforcement was never wired up) or intentionally-unused infrastructure for a future gated-launch mode — either way, it currently ships on mainnet as three public, gas-costing, storage-writing functions that do nothing observable to any other contract behavior, which is confusing for auditors and a wasted attack surface (an admin key compromise gains an extra set of callable functions with no corresponding safety benefit).

Tasks

• Decide the intended semantics: should the whitelist gate create_token/create_tokens_batch (only whitelisted addresses may create tokens), or something else (e.g. gating who may be set as treasury recipients in a fee split)?
• If gating token creation: add a require_whitelisted check at the top of create_token_inner/create_tokens_batch, gated behind a factory-level toggle (e.g. FactoryState.whitelist_enabled: bool, defaulting to false so existing deployments are unaffected) so the feature can be turned on without breaking public/open factories.
• If the feature is not wanted at all: remove the three functions, their storage key, and associated tests, rather than shipping unused privileged surface area.
• Whichever direction is chosen, update docs/contract-abi.md and the README to describe the actual, enforced behavior (the README currently describes the whitelist as present-but-unenforced as of this audit — keep that accurate or update it once resolved).
• Add tests proving the chosen behavior: either "whitelist gates creation when enabled" or "whitelist functions have been removed."

Acceptance Criteria

• The whitelist either visibly affects contract behavior with test coverage proving it, or is removed entirely — no unenforced admin surface remains merged to main.
• If kept and enforced, a non-whitelisted address's create_token call fails with a clear, dedicated error variant (not a generic Unauthorized) when whitelist mode is enabled.
• Documentation accurately reflects the shipped behavior.