// Scoring methodology
Open by design.
Every factor, every signal, every hard cap — published openly so anyone can audit how scores are calculated. No black boxes. No hidden penalties.
Current scoring version
v1.0 — launched April 2026
The five factors
Launch History
30%
How long did your tokens survive? In pump.fun, 99% of tokens die within an hour. Survival time is the clearest signal of genuine community interest. Points are tiered and cumulative — a token that survives 7 days earns all tiers below it.
| Milestone | Points | Reality |
| Survived 1 hour | +2 | Baseline — most tokens die here |
| Survived 4 hours | +8 | Top ~10% of launches |
| Survived 8 hours | +12 | Top ~5% |
| Survived 24 hours | +20 | Genuinely rare |
| Survived 48 hours | +28 | Very strong |
| Survived 72 hours | +35 | Exceptional |
| Survived 7 days | +50 | Elite — full points |
| Graduated to Raydium | +25 bonus | Separate on top of longevity |
graduation bonus
launch veteran (10+)
dev dumped >50% in first hour
self-sniping detected
Liquidity Behavior
25%
pump.fun controls LP during the bonding curve — devs cannot lock it. What devs CAN do: lock their token allocation via Streamflow or Realms, and lock Raydium LP after graduation. We score voluntary commitments, not things out of the dev's control.
| Dev Token Lock Duration | Points |
| 180+ days locked | +20 — strong commitment |
| 90–179 days locked | +14 |
| 30–89 days locked | +8 |
| Under 30 days locked | +3 — minimal signal |
| No lock detected | 0 — neutral |
dev tokens locked (Streamflow/Realms)
100% of dev allocation locked
Raydium LP locked post-graduation
high graduation rate
low dev allocation (<3%)
held 48h+ before first sell
sold before lock expired
post-graduation LP pull
dev allocation >15%
sold within 1h of launch
Note: pump.fun LP locking during the bonding curve is not possible — the protocol controls it. Penalizing devs for this would be unfair. Only post-graduation Raydium LP behavior and voluntary token locks are scored.
Holder Retention
20%
The community voted with their wallets. Only tokens that survived long enough to measure are scored — a token must survive 7 days to contribute to 7d retention scoring. This avoids penalizing devs for tokens that died too fast to generate meaningful holder data.
7d retention >50%
30d retention >30%
peak community >500 holders
holder cliff event (95%+ exit)
7d retention <10%
Community Signals
15%
On-chain hygiene signals. Mint authority, freeze authority, and Telegram channel longevity. Note: pump.fun auto-renounces mint authority on graduation — this only affects non-graduated tokens.
Telegram maintained
mint authority renounced
freeze authority revoked
Telegram deleted post-launch
mint authority active (non-graduated)
Wallet History
10%
Age and consistency of the wallet itself. New wallets start with lower scores — not zero, but lower. Wallet age, transaction history, total volume, and funding wallet clustering.
wallet age >1 year
1000+ lifetime transactions
high lifetime volume
wallet age <30 days
5+ linked funding wallets
Hard caps
Certain critical flags override the raw score calculation and cap the maximum possible score regardless of other factors.
| Flag | Score Cap | Reason |
| SERIAL_EARLY_DUMP |
250 |
Dev dumped >50% in first hour on 2+ launches |
| POST_GRAD_LP_PULL |
300 |
Pulled Raydium LP after graduation |
| SELF_SNIPE |
350 |
Dev wallet sniped own launch |
| 2+ CRITICAL flags |
199 |
Multiple critical violations — BLACKLISTED tier |
Known limitations
New wallet problem
Ruggers can create fresh wallets to reset their history. We use funding trail analysis and behavioral fingerprinting to cluster wallets — but we won't catch everyone. A fresh wallet scores UNPROVEN, not VERIFIED. Projects can set minimum score thresholds for early access.
Mixer obfuscation
Tools like SplitNow and Solflare stealth can obscure wallet funding trails. We flag wallets with obfuscated histories as a signal but cannot definitively identify the underlying identity.
This is V1 beta
Scoring improves as more data is indexed. Historical holder retention data becomes more accurate over time. Some approximations are used in early data — these will be replaced with precise indexer data in V2.
Open source
The scoring engine is open source. Read the code, audit the logic, submit issues or improvements. Transparency is how we earn trust.
↗ View scoring engine on GitHub