How the Velocity Radar score works

What enters the radar before scoring

The live radar is not a census of every Solana token. Its candidate universe starts with unique Solana mints from DEX Screener's most-active-boosts feed, then unions unique Solana mints from DEX Screener's latest-token-profiles feed as a coverage fallback. Exact mint addresses are the join key; repeated rows are not counted twice. A boost-led mint keeps the provider's observed boost amounts. A profile-only mint receives no invented boost amount: that feed contribution starts at zero, while an independently returned active-boost value on its exact pair may still be reported.

For every candidate mint, the runtime requests DEX Screener pairs for that exact address and keeps one pair: the pair with the highest selection value of 70% visible USD liquidity plus 30% 24-hour volume. That pair-selection value only chooses the market pair; it is not the Velocity Radar score. The resulting token records expose whether their universe origin was the top-boost feed or latest-profile fallback, so the broader coverage is inspectable rather than silent.

A candidate is rankable only when it is on Solana, has a mint longer than 20 characters, has finite organic, liquidity, and 24-hour volume values, and has at least $1,000 in visible USD liquidity. The runtime ranks the eligible candidates by the formula below and returns up to ten. This remains a narrow provider-curated discovery surface shaped by current paid promotion and recently updated profiles, not an organic index or census of the whole chain.

The exact formula

Velocity score = 45% organic component + 25% volume component + 20% liquidity component + 10% boost component − holder-concentration penalty.

Each component is first bounded to 0–100 and rounded to one decimal place. The weighted result then has the concentration penalty subtracted, is floored at zero, and is rounded to one decimal place. With valid inputs the score therefore stays between 0 and 100. This is a ranking and attention-triage score. It is not a probability, price forecast, safety grade, or instruction to trade.

How the four components are normalized

Organic uses the Jupiter Tokens V2 organicScore field when it is present, clamped directly to 0–100. Liquidity uses 100 × clamp(log10(USD liquidity + 1) ÷ 7, 0, 1). Volume uses 100 × clamp(log10(24-hour USD volume + 1) ÷ 8, 0, 1). The logarithms compress very large dollar differences so that one extreme value cannot grow without limit.

Boost uses 100 × clamp(log10(total boost amount + active boosts + 1) ÷ 3, 0, 1). In the current implementation the boost input is the DEX Screener total boost amount plus active boost count. It is a paid-visibility signal and contributes positively up to ten score points. A higher score must therefore never be described as purely organic.

The component ceilings occur when the value inside the logarithm reaches its divisor's power of ten: liquidity is effectively capped at $9,999,999, volume at $99,999,999, and the combined boost input at 999. Values above those points remain at a 100 component score. Non-finite or non-positive logarithmic inputs receive zero for that component.

Holder-concentration penalty

Known top-holder concentration has no penalty through 20%. Above 20%, the score loses 0.7 points for every additional percentage point, capped at an 18-point deduction. The maximum is reached at approximately 45.7% concentration and remains 18 beyond that point.

If the provider does not return top-holder concentration, the current runtime applies no concentration penalty. That is missing evidence, not proof of healthy distribution. The interface should keep the field unavailable and the reader should treat the numeric result as less complete. Other warning labels—such as thin liquidity, unusual volume pressure, a very new pair, or boost mismatch—are annotations after scoring and do not deduct points from the numeric score.

Missing organic data and the provider-limited fallback

When DEX Screener supplies the market pair but Jupiter does not supply an organic score for the same mint, the runtime uses a neutral fallback organic input of 50. At the 45% organic weight, that fallback contributes 22.5 points to the final score. The token is marked "provider-limited" so the number is not mistaken for a Jupiter measurement.

Provider-limited values can still participate in the overall ranking because the live board needs a deterministic value while other market fields are present. They must not be used to name a “strongest organic” winner. If no Jupiter-backed organic scores exist in the current set, the organic comparison is unavailable. If the organic input is absent entirely rather than normalized to the explicit fallback, the signal is not rankable.

Worked example

Consider an illustrative candidate with organic 80, $100,000 liquidity, $1,000,000 24-hour volume, a combined boost input of 99, and known top-holder concentration of 30%. The normalized components are organic 80.0, liquidity 71.4, volume 75.0, and boost 66.7.

Before concentration, the weighted score is (80.0 × 0.45) + (75.0 × 0.25) + (71.4 × 0.20) + (66.7 × 0.10) = 75.7. A 30% concentration value is ten percentage points above the free threshold, so the penalty is 10 × 0.7 = 7.0. The final score is 75.7 − 7.0 = 68.7.

Changing only recent rank movement does not change this number. Changing only a warning label does not change it either. Changing one of the four weighted inputs or the known concentration value does.

Momentum, pressure, and risk context

Velocity Radar also calculates a display-only momentum value from rank movement and score movement: clamp(rank delta × 18 + velocity-score delta × 4, 0, 100). It appears in the score breakdown after trends are attached, but it is not one of the weighted terms in the current velocity-score formula.

Volume pressure is 24-hour volume divided by liquidity. It helps explain how intense activity is relative to visible depth, but the ratio itself is not a separate score term; volume and liquidity already enter independently through their logarithmic components. Risk flags help readers interpret the score. Only the explicit holder-concentration penalty changes the numeric score.

Freshness, updates, and fail-closed behavior

A producer refresh builds a complete candidate snapshot, applies the formula, validates the result, and only then promotes it to the public cache. Every generated snapshot is stamped stale 15 minutes after generation. Production also requires live source mode and at least ten eligible tokens before a snapshot can power public automation or partner-link eligibility.

If latest-profile retrieval fails while the unique boost-led universe is already at least the configured minimum, the runtime may still attempt the primary boost-only path; the final eligible-token coverage gate remains unchanged. If the boost universe is sparse and the fallback cannot be read, or if the combined sources still yield fewer than ten eligible tokens, the refresh fails closed and the previous public snapshot is not replaced.

If the snapshot is missing, stale, from the wrong source mode, or below required coverage, the public API returns a hold instead of quietly presenting fixture data as live. Scores can change whenever a new verified snapshot changes organic score, liquidity, volume, boost input, or known concentration. Pair selection or candidate-universe changes can also add or remove a token. The displayed generation time is therefore part of the result, not decoration.

Change history

• 2026-08-31 — Documented the deduplicated top-boost plus latest-profile candidate universe, exact-mint pair lookup, source provenance, sparse-source failure behavior, exact formula, bounds, and worked example.
• 2026-06-02 — Initial plain-language score guide published.