Contracts exhibiting the "generated token scam" pattern often include a transfer function that enforces a whitelist or require() condition, permitting buy transactions but reverting sells for non-whitelisted addresses. Mechanically, this means the contract checks the sender or recipient against an allowed list during transfers, blocking sell attempts outside that list. This structural condition creates a one-way trade flow where tokens can be acquired but not liquidated, trapping buyers unknowingly. The price chart may appear normal because buys execute and update on-chain data, while failed sells revert without changing balances. Detection requires direct contract inspection since transaction history alone may not reveal the asymmetric transfer restrictions.
This pattern becomes risk-relevant primarily when the whitelist or allowlist is modifiable by the contract owner or deployer after launch, enabling selective blocking of sell transactions at their discretion. Such owner-controlled lists can be weaponized to trap liquidity providers or retail buyers, effectively creating a honeypot scenario. Conversely, the pattern can be benign if the whitelist is fixed at deployment and used for legitimate compliance or operational reasons, such as regulatory restrictions or staged token releases. The key distinction lies in owner mutability: immutable whitelists limit exit restrictions to predefined wallets, reducing exit risk, whereas mutable lists maintain ongoing exit-block potential.
Additional signals that would meaningfully affect the risk assessment include the presence of adjustable sell tax parameters controlled by the owner, which can be raised post-launch to discourage or penalize selling. Similarly, active mint or freeze authorities retained by the deployer can exacerbate risk by enabling supply inflation or transfer freezes, respectively. Conversely, evidence of renounced mint and freeze authorities, immutable whitelist configurations, or multisignature controls on critical functions would mitigate concerns. The presence of a pause function or blacklist capability, especially if owner-controlled without timelocks, also heightens exit risk by enabling forced transfer halts or selective blocking.
When combined with other common conditions, this pattern can produce a spectrum of outcomes ranging from subtle liquidity traps to outright scams. For instance, coupling a whitelist-only exit with an adjustable sell tax and active freeze authority creates layered exit barriers that can frustrate or prevent sales entirely. Proxy upgradeability without timelocks further compounds risk by allowing sudden logic changes to enforce new restrictions. However, if the contract employs robust governance mechanisms, transparent controls, and immutable critical parameters, these risks may be substantially reduced. The realistic range thus spans from temporary operational limits to permanent liquidity lockups, contingent on the interplay of these structural features.