A token scam database typically catalogs contracts exhibiting structural patterns that can restrict token exit liquidity or enable owner control over token flows. Central among these is the honeypot pattern, where the transfer() function includes a require() check that reverts sell transactions for non-whitelisted addresses while allowing buys. Mechanically, this means buyers can acquire tokens but cannot sell them, as sell attempts revert and consume gas without changing balances. This pattern is detectable by inspecting the contract code, specifically the transfer logic, without needing to execute trades. The database’s role is to flag these structural conditions that indicate a potential exit block, even if the price chart appears normal.
This pattern becomes risk-relevant when the whitelist or allowlist controlling sell permissions is owner-modifiable post-launch, enabling the project team to selectively block sells at will. Such control creates a soft honeypot scenario where buyers may be trapped unknowingly. Conversely, the pattern can be benign if the whitelist is fixed at launch or used for regulatory compliance, such as restricting sales to verified participants in certain jurisdictions. The key differentiator is the ability of the owner to adjust the whitelist after deployment; without this, the pattern’s exit-block potential is effectively disabled, reducing risk despite the structural presence of the require() check.
Additional signals that would shift the risk assessment include the presence of an adjustable sell tax parameter controlled by the owner, which can be raised suddenly to punitive levels, effectively discouraging or blocking sells economically. Similarly, active mint or freeze authorities that remain unrenounced can compound risk by enabling supply inflation or transfer freezes, respectively. Conversely, the existence of a timelock or multisig on owner functions, or transparent governance mechanisms limiting owner power, would mitigate concerns by reducing the likelihood of arbitrary whitelist changes or tax hikes. Observing on-chain activity such as past whitelist modifications or sell tax adjustments would also inform the risk level but is not strictly necessary to identify the structural capability.
When combined with other common conditions like proxy upgradeability without timelocks or pause functions, the range of outcomes broadens from soft exit blocks to full-scale rug pulls. For example, a contract with a whitelist-controlled transfer plus an owner-controlled pause function can halt all transfers instantly, trapping all holders. Upgradeable proxies without multisig controls can allow the logic to be swapped to malicious code, amplifying risk beyond the initial whitelist pattern. On the other hand, if these additional controls are absent or constrained, the honeypot pattern alone typically results in failed sell attempts with gas loss but no direct theft, illustrating how layered contract features modulate the severity of the exit risk.