Skip to main content
Automated safety scanners raise the same handful of flags on advanced BaseStonk launches. Most are heuristics meeting an architecture they were not written for. If your launch - or a token you are researching - carries one of these flags, this page tells you what fires it and what is actually true, so you can decide for yourself rather than inheriting a verdict.

​
Creator can move funds

Not true of any BaseStonk launch. The token is around 120 lines and has three privileged functions, every one restricted to the launcher contract rather than to the creator: The V6 binding also asserts identity, not just presence: the tracker must answer token() with this token’s address and launcher() with this launcher’s, or the call reverts. The launcher cannot attach a tracker built for a different launch, so the address the transfer notification calls is provably the distributor deployed for this token - the creator cannot redirect holder rewards, and neither can the platform. None mints, burns, or moves a balance. There is no post-construction mint and no owner burn, and _update moves tokens only through the inherited ERC-20 implementation. What trips the heuristic is the rewards notification inside _update:
An external call to a stored address on every transfer is a genuine malware signature, so flagging it is reasonable. Here the callee only reads balances and settles dividends, and the result is discarded - the token takes no action on what it returns.
Simple launches have no tracker and no external call, which is why they scan clean while advanced launches do not. The difference is the launch mode, not the launcher generation.

​
Unlocked liquidity, 0% locked or burned

A model mismatch. Scanners look for burned or time-locked LP tokens, which is how Uniswap v2 and v3 represent a position. Uniswap v4 has no LP token at all - the position lives inside the PoolManager, keyed by the pool. There is nothing to burn, so the check reports zero. Launch liquidity is added by the launcher inside its own unlock callback with a strictly positive liquidityDelta, and the callback rejects any caller that is not the PoolManager. Why the pool cannot be pulled at all is the sell floor.

​
High transfer fees

Usually true. The figure a scanner measures is the token’s configured tax plus the pool fee, so a 4% launch measures at roughly 4.1%. It is a real cost and it is the creator’s choice, published in the token’s API record as buyTaxBps and sellTaxBps. Quote against those numbers rather than a default - and note that a scanner simulating a buy inside a V6 launch’s anti-sniper window measures the decaying toll, not the permanent rate. The toll is gone within 30 minutes of launch at most.

​
Unverified contract / unverified token

Two different claims. Every active BaseStonk contract is verified on Basescan and can be read there. “Unverified token” usually means only that a token is absent from that platform’s own curated list, which is a statement about the list.
A token that copies a BaseStonk name or ticker is not a BaseStonk launch. Anything the platform deployed is traceable to a launcher on the contract reference page - check the launcher before trusting a name.

​
Reporting a false positive

If you operate a scanner and want to classify these correctly, the two checks that separate a BaseStonk launch from the pattern it resembles are:
  1. Admin surface. Confirm the only privileged functions are the three above and that each reverts for callers other than the launcher.
  2. Call target mutability. Confirm setRewardTracker is one-way and, on V6, identity-checked - the call target cannot be repointed after launch, and could never have been pointed at a contract that does not answer for this token.