A wallet scam detector typically focuses on identifying structural contract patterns that restrict or manipulate wallet behaviors in token transfers. One central pattern is the presence of require() checks in transfer functions that whitelist specific wallets, allowing buys but reverting sells for non-whitelisted addresses. Mechanically, this enforces an asymmetric permission model where only certain wallets can exit positions, effectively trapping others. This pattern is detectable through static contract inspection, as it relies on explicit conditional logic tied to wallet addresses rather than market activity. The presence of owner-controlled mappings for whitelists or blacklists further amplifies this control, enabling dynamic modification of wallet permissions post-launch.
This pattern’s risk relevance hinges on the owner’s ability to modify wallet permissions after deployment. If the whitelist or blacklist is immutable or governed by decentralized mechanisms, the pattern may serve legitimate purposes such as regulatory compliance or staged token releases. Conversely, if the owner can arbitrarily add or remove wallets from these lists, it creates a soft honeypot environment where exit is selectively blocked. The pattern alone does not imply malicious intent but becomes suspicious when combined with opaque ownership controls or absence of clear operational justification. In some cases, whitelist-only exit mechanisms are used to enforce vesting schedules or prevent bot trading, which can be benign if transparently communicated.
Additional signals that would shift the risk assessment include the presence of adjustable sell tax parameters controlled by the owner, which can be raised post-launch to disincentivize selling. Detection of active mint or freeze authorities on the token contract also informs risk: an active mint authority without clear operational rationale raises the possibility of inflationary dilution, while freeze authority enables selective transfer halts. Furthermore, upgradeable proxy patterns without multisig or timelock protections increase risk by allowing sudden logic changes that can introduce or remove wallet restrictions. Conversely, transparent governance mechanisms, public timelocks, or community oversight would mitigate concerns about these patterns.
When combined with other common conditions such as low liquidity pool depth or recent token launch age, wallet restriction patterns can precipitate rapid liquidity removal and price collapse. For example, a whitelist-only exit combined with owner-controlled sell tax hikes and active freeze authority may enable a scenario where holders are trapped while liquidity is drained in a single transaction. This structural capability can produce sharp, irreversible losses before affected wallets can react. However, if the token operates in a mature market with substantial liquidity and transparent controls, these patterns may have limited practical impact. The realistic outcome spectrum ranges from benign operational controls to exploitative exit blocks, depending on the interplay of contract permissions and market context.