Skip to content

How a token qualifies

Most new Pump.fun launches never become a call. This page explains what has to be true for one to make it through.

The fail-closed principle

The single most important rule is this: a missing value is a rejection, not a pass. Every required metric must be present, fresh and passing at the same moment — a stale holder snapshot, unavailable market-cap evidence or a token with no usable image is rejected rather than called on partial evidence.

The screening dimensions

Dimension What it looks at What it protects against
Token age Time since the token was first observed trading Calling something that is either not yet real or long past its launch window
Market cap Latest causal swap price × supply, with a floor and a ceiling Dust launches at the bottom; manufactured high-FDV farm tokens at the top
2m / 5m volume Actual SOL traded in each window Tokens with a price but no real trading behind it
Buy ratio & trade count Share of recent trades that were buys, and how many there were A "rally" that is really one wallet, or that is already net selling
Peak drawdown How far off its own peak the token already is Calling a token that has already topped and is bleeding
Top-1 / top-10 holder share Supply concentration across the largest holders A single wallet or small group able to dump the entire market
Top-holder SOL balances Whether the biggest holders are funded, real wallets Farms of empty throwaway wallets manufacturing a holder count
Fresh wallets (recorded, not screened) Share of sampled holders with no other observed trading history Nothing, currently. Measurement showed this dimension selected against the tokens that went on to run, so it is published on the card but no longer rejects a call
Rug registry (recorded, not screened) Whether sampled holders match wallets seen in previously detected rugs Nothing, currently. Rug participation turned out to be the norm rather than the exception among active traders, so matches are published on the card but no longer reject a call
Insider / bundler balances Early-control heuristics over the first moments of the launch Bundled supply hidden behind many addresses
Mint security Mint and freeze authority state Tokens whose supply or your ability to sell can still be changed
Snapshot freshness Age of the holder data used Deciding on stale holder evidence
Token image Metadata image present and renderable Zero-effort launches, and unrenderable call cards

We publish the metrics, not the thresholds

The specific numbers behind each dimension — the exact bands, ratios, shares and windows — are part of the versioned rule set and are deliberately not published.

What is public is the list above: these are the metrics a token is judged on, and the ones marked screened are required and fail closed — missing evidence rejects a call rather than passing it.

Dimensions marked recorded, not screened are still collected, still shown on the card, and still versioned; they simply do not reject a call on their own. Every value a call was made on is printed on its call card.

KOL and influencer data is deliberately not part of the filter. Whether an account with a following has mentioned a token has no bearing on whether it gets called.

Creator launch history and migration counts are recorded on every evaluation for research, but they are not currently hard pass/fail thresholds on their own.

The rug guard

Passing the base rules above is necessary but not sufficient. A separate, versioned balanced rug guard then evaluates the candidate using holder distribution, creator history, volume, bundler/insider evidence and rug-wallet evidence combined.

A flagged candidate is terminally rejected before a Premium message exists, so the call is never sent and no autotrader entry can be triggered by it.

The guard treats missing evidence differently from the base screen: unavailable evidence disables only the term that needed it, and can never create a rejection on its own.

Why one rug-guard term was retired

The guard's fresh-wallet terms were retired: they were fitted against a fresh-wallet measurement that could not see wallets with no trading history at all, so their thresholds no longer meant what they were calibrated to mean.

Versioned, immutable rules

A call cannot be quietly re-graded after the fact: the rules it was made under are recorded against it permanently, and changing a threshold produces a new version rather than rewriting the history of old calls.

How the versioning is enforced

The rule set is versioned and hashed. Each version registers a canonical manifest, and the service refuses to start if the configuration changes while reusing an existing version string. Moving a dimension between screened and recorded is a threshold change like any other — it produces a new immutable version rather than quietly altering the old one.

Honest limits of our metrics

  • Wallet age is a lower bound derived from retained trading history. It is not the true on-chain creation time of a Solana wallet.
  • "Fresh" means no other token was observed for that wallet within our retained history. It does not prove the wallet is new.
  • Insider and bundler labels are bounded on-chain heuristics. They are not proof that supply was bundled.
  • The rug registry is historical research evidence. A match is not proof of wrongdoing by that wallet.
  • Pump.fun and Pump AMM are our venue boundary. Trading that happens only on other venues is not included in any of these numbers.
  • USD values are presentation evidence. All filters and milestones are SOL-native.

None of these limits are reasons to skip the screening — they are reasons not to read a call as a safety certificate. It isn't one.

What screening cannot do

Screening is applied at one instant, before the call. Nothing about passing it prevents the token from being dumped in the next block. A token can pass every rule here and still go to zero minutes later, and some do.

That risk is the subject of Risk & Safety, and it is the reason the autotrader is built around exits rather than entries.