Skip to main content
Safety scanners raise the same few flags on advanced BaseStonk launches. Most are heuristics meeting an architecture they were not written for.

​
Creator can move funds

The token has three privileged functions. Every one is restricted to the launcher contract, never the creator: No mint, no owner burn, no balance move; _update moves tokens only through the inherited ERC-20. V6 also checks identity at binding: the tracker must answer token() and launcher() correctly, so it is provably the distributor deployed for this token. What trips the heuristic:
An external call to a stored address on every transfer is a real malware signature. Here the callee reads balances and settles dividends, and the result is discarded.
Simple launches have no tracker and no external call, so they scan clean. The difference is the mode, not the generation.

​
Unlocked liquidity

Scanners look for burned or locked LP tokens - a v2/v3 concept. v4 has none; the position is keyed inside the PoolManager. Launch liquidity is added in the launcher’s own unlock callback with a strictly positive liquidityDelta, and the callback rejects any caller but the PoolManager. Why it cannot be pulled: the sell floor.

​
High transfer fees

A 4% V7 launch measures at 4% - V7 pools charge no LP fee. A launch from before V7 measures at about 4.1%, tax plus the 0.3% pool fee. Quote against the token’s published buyTaxBps and sellTaxBps, not a default. A scanner simulating inside the anti-sniper window measures the decaying toll, which is gone within 30 minutes.
A token that copies a BaseStonk name is not a BaseStonk launch. Anything the platform deployed traces to a launcher on the contract reference. Check the launcher, not the name.

​
For scanner operators

Two checks separate a BaseStonk launch from the pattern it resembles:
  1. Admin surface - the only privileged functions are the three above, each reverting for any caller but the launcher.
  2. Call-target mutability - setRewardTracker is one-way and, on V6, identity-checked.