​

HP scoring ▼

​

The HP composite

HP = round(Σ(weight_i × component_i) × 10000)

• Matches the basis-point convention used throughout filter.fun (fee splits, settlement math, HHI computation)
• Integer storage eliminates float-precision bugs in rank comparisons at the cut threshold
• Same effective resolution as 0–100 with two decimal places (10000 discrete values either way) but cleaner display and JSON
• Aligns with “HP” as a high-score-style integer (cultural convention from games)

1. HP descending (primary)
2. launchedAt ascending (earlier-launched wins)
3. Token address ascending (lower-hex wins — final tier)

​

The six components

​

Why these six (and not others)

1. No raw market cap. Market cap is gameable by a single whale buy at thin liquidity. HP rewards real demand, not price action.
2. No raw unique-buyer count. Sybil farms can manufacture wallet count cheaply. The sqrt-dampening on effectiveBuyers plus the per-wallet cap on velocity and the HHI penalty on holderConcentration make sybil construction quadratically expensive.
3. No social-signal data inside HP. Social volume is high-leverage but un-verifiable on-chain and breaks HP’s deterministic, auditable property. Social data lives on spectator surfaces (planned Phase 3) but doesn’t influence eliminations.

velocity            = 0.85
effectiveBuyers     = 0.62
stickyLiquidity     = 0.78
retention           = 0.71
momentum            = 0     (disabled)
holderConcentration = 0.55

HP = round((0.85 × 0.30 + 0.62 × 0.15 + 0.78 × 0.30
          + 0.71 × 0.15 + 0     × 0.00 + 0.55 × 0.10) × 10000)
   = round(0.7435 × 10000)
   = 7435

​

Locked formula constants

​

Per-component formulas

​

Velocity — decayed net inflow

for each buy in last VELOCITY_LOOKBACK_SEC (96h):
  contribution = amount × 2^(-age / VELOCITY_DECAY_HALFLIFE_SEC)   # 24h half-life
for each sell in same window:
  same decay; if within VELOCITY_DECAY_HALFLIFE_SEC of a same-wallet buy
    → × VELOCITY_CHURN_PENALTY_FACTOR (= 2)
per_wallet_net = clip(buys − sells, 0, VELOCITY_PER_WALLET_CAP_WETH)   # absolute 10 WETH cap
raw = Σ per_wallet_net
score = clip(raw / VELOCITY_REFERENCE, 0, 1)

​

Effective buyers — sqrt dampening

qualifying_wallets = { w | volumeByWallet[w] ≥ EFFECTIVE_BUYERS_DUST_WETH (0.001 WETH) }
raw = Σ_{w ∈ qualifying_wallets} sqrt(volumeByWallet[w])
score = clip(raw / EFFECTIVE_BUYERS_REFERENCE, 0, 1)

​

Sticky liquidity — exponential LP-removal penalty

base = avgLiquidityDepthWeth ?? liquidityDepthWeth
penalty = Σ_{remove events in last LP_PENALTY_WINDOW_SEC (24h)}
            amount × exp(-Δt / LP_PENALTY_TAU_SEC)   # 6h decay constant
raw = max(0, base − penalty)
score = clip(raw / STICKY_LIQUIDITY_REFERENCE, 0, 1) × ageFactor

​

Retention — two-anchor + dust filter

qualifying_anchor_holders = { h ∈ holdersAtRetentionAnchor |
                              balance[h] / totalSupply ≥ RETENTION_DUST_SUPPLY_FRAC (0.01%) }
long_ratio  = |currentHolders ∩ qualifying_anchor_holders| / |qualifying_anchor_holders|
short_ratio = |currentHolders ∩ holdersAtRecentAnchor|     / |holdersAtRecentAnchor|     (if recent set)
ratio = (longWeight × long + shortWeight × short) / (longWeight + shortWeight)          (default 60/40)
score = ratio × ageFactor

​

Holder concentration — HHI

shares = balances / Σ(balances)        # excluded addresses pre-filtered
hhi = Σ(shares²)                       # 1.0 = single holder; 1/n = perfect distribution
score = clip(1 − hhi, 0, 1) × ageFactor

​

Momentum — bounded recent acceleration (disabled under v4 lock)

​

How we derived the weights

​

The story arc

​

Validation summary

​

What the methodology actually does

1. Build a stratified corpus. Pull a balanced sample of survivor + dead tokens from Clanker V4 launches. v4 used 50/50 dead/survivor (n=100); v5 used a liquidity-first scan against PoolManager Swap logs to recover top-FDV tokens (n=43).
2. Compute HP components for each token at hour 96 post-launch using the production scoring code.
3. Compute outcome labels the components don’t read — survived_to_day_7, holder_retention_at_30d, price_floor_at_30d. The decoupling matters: if outcomes derive from data the components also read, fitted weights are inflated by leakage.
4. Fit weights via L2-regularized logistic regression against each outcome label. Compare to defaults.
5. RandomForest feature importance as a non-linear sanity check.
6. Leakage discipline — flag any component-vs-outcome correlation with |ρ| ≥ 0.85; treat the corresponding fitted weights as inflated, don’t act on them.
7. Lock decision — adopt only fitted weights that survive the leakage check, have non-trivial empirical signal, and don’t disrupt rank stability vs current weights.

​

What the data said about each component

• stickyLiquidity is the dominant predictor. v4 RF importance 0.38 (highest of any component); v5 Spearman ρ +0.87 against price-floor outcome. Empirical weight in the L2 fit was 42%, but the leakage flag (component and outcome share underlying LP data) means that’s an inflated upper bound. Locked at 30% — a conservative middle ground between the prior default (20%) and the inflated fit (42%).
• retention is a real but leakage-suspect signal. v4 ρ +0.93 against the same-name outcome label hit the leakage threshold. Held at the prior default 15%.
• holderConcentration validated as a real component across two runs (v2 ρ +0.46 / AUC 0.80; v3 ρ +0.39 / AUC 0.61). Adding it doesn’t disrupt rankings (rank stability ρ +0.997 to +1.000). Locked at 10%.
• velocity and effectiveBuyers are weaker than prior defaults suggest. v4 L2 fit assigned 19% and 20% (vs 30% and 15% prior). With n=100 and known leakage in the outcome that drove the fit, deviating on these would be over-fitting. Held at defaults: 30% and 15%.
• A sixth component, momentum, was tested and removed. The L2 fit assigned momentum 0% on every outcome label across a 100-token stratified corpus. Diagnostic showed 42% of survivor-half tokens had structurally flat HP in the 72h→96h window where momentum is measured. The component was structurally degraded by the current delta-window definition. Removed; its 10% weight slot was redistributed to stickyLiquidity (the strongest non-leakage signal). The component’s code remains in place behind a feature flag (HP_MOMENTUM_ENABLED=false) for v6 reconsideration if a wider delta window surfaces signal.

​

Cross-validation against published research

​

Settlement finality + reorg safety

​

Wallet attribution: tx.from, not event.args.sender

​

How to verify

curl -s https://api.filter.fun/scoring/weights | jq

​

Trust model

• Weights live off-chain in the scoring/ package config — not in contract bytecode. Contracts only see the oracle-published Merkle root of rankings; they never read weight values directly.
• Engine is a pure function of the indexer’s input bundle. The inv_hp_formula_pure runtime invariant calls score() 100× across varied chain states and asserts byte-identical output.
• Settlement-tagged rows are reorg-immune by construction (≥12-block wait) + verified by the inv_hp_settlement_finality invariant before any oracle Merkle publish.
• Weight + constant changes follow ≥7-day public-notice procedure.
• Every hpSnapshot row is tagged with weightsVersion for historical reproducibility; an auditor can replay any past ranking under the exact engine that produced it.

​

Honest caveats

​

What’s next

• Per-event lpEvents timeline for sticky-liquidity (engine has aggregate fallback today; per-event LP requires V4 ModifyLiquidity wiring)
• Transfer event log for exact retention-anchor reconstruction (current firstSeenAt approximation is the documented compromise)
• Router-decoded EOA for meta-tx relayers (tx.from covers >99% of expected traffic)
• Marino cross-check on a stratified validation cohort (current cohort structurally can’t populate Marino’s failure cell)