Weights Calculation

Token Weighting Methodology for DiversiFi Indexes

This sections outlines the methodology used to determine the weight of each token included in a DiversiFi index. The goal is to offer transparent, data-driven exposure to various crypto themes while ensuring safety, liquidity, and long-term potential for passive investors.

Overview

Token weights are determined using a multi-factor scoring model based on 8 key metrics (expect the multi-chains index - 5).

  • Volume over the last month

  • Market cap (snap shot)

  • Liquidity (snap shot) - not available for multi-chains index

  • Volatility

  • Price change over the last month

  • Supply ratio (snap shot)

  • Holder count - not available for multi-chains index

  • Fundamental grade

Each metric is assigned a specific weight based on its relevance, and tokens are scored accordingly. The final token weight is a normalized and weighted average of these scores.

Most metrics are calculated using the Birdeye API (for Solana tokens). We also use the CoinGecko API to retrieve data for tokens in the multi-chains index, ensuring that metrics like market cap and volume are based on the native tokens rather than their wrapped equivalents.

Metrics Used

1. Volume (30-Day Average) - 10% Weight

  • Definition: Total volume in USD over the past 30 days.

  • Source: Birdeye API or Coingecko API (for multichain assets).

  • Rationale: Reflects real demand and user activity. High volume indicates strong market interest and liquidity.

2. Market Cap (Snapshot) - 65% Weight

  • Definition: Current circulating market capitalization in USDC.

  • Source: Birdeye API or CoinGecko (for multichain assets).

  • Rationale: Indicates maturity and overall valuation.

3. Liquidity (Snapshot) - 5% Weight

  • Definition: Current on-chain liquidity available for swaps.

  • Source: Birdeye API

  • Rationale: Ensures users can enter and exit index positions efficiently.

  • Observation : not fetched for multi-chains index, irrelevant regarding the adoption of those assets.

4. Volatility (30-Day) - 5% Weight

  • Definition: Standard deviation of daily price returns over the last 30 days.

  • Source: Birdeye OHLCV endpoint

  • Rationale: Measures risk. Lower volatility is often preferable for passive strategies.

5. Price Evolution (30-Day) - 5% Weight

  • Definition: Percentage change in price over the last 30 days.

  • Source: Birdeye OHLCV endpoint

  • Rationale: Captures market momentum.

6. Circulating Supply Ratio - 5% Weight

  • Definition: (Circulating Supply / Total Supply) × 100

  • Source: Birdeye API and CoinGecko (for multichain assets).

  • Rationale: Evaluates dilution risk and tokenomics health.

7. Holder Count Trend (30-Day) - 5% Weight

  • Definition: Percentage change in number of unique holders over 30 days.

  • Rationale: Tracks user growth and adoption.

  • Observation : not fetched for multi-chains index, irrelevant regarding the adoption of those assets.

Weight Calculation Process

  1. Data Collection:

The script fetch_data.py is used to gather all raw data points for each token from:

  • Birdeye API (Solana tokens): market cap, liquidity, volume, volatility, price evolution, supply ratio, holder count.

  • CoinGecko API (Multichain tokens): market cap, volume, volatility, price evolution, supply ratio.

The resulting output is written to data.json. This file serves as the standardized, structured dataset for the next computation step.

  1. Normalization:

Each metric is normalized to a 0–1 scale per index, using a mix of square-root compression, inverse linear transformation, and standard min-max scaling.

All metrics are normalized using the following methods:

  • Volume, Market Cap, Liquidity, Holder Count:

We use square-root compression to reduce the impact of very large values without flattening smaller signals completely:

normalized = sqrt(value) / sqrt(max_value)

→ Prevents large tokens from overly dominating the index while keeping some meaningful relative differences.

  • Volatility:

Lower volatility is better, so we apply an inverse linear normalization:

normalized = 1 - (value / max_value)

→ Lower volatility gets a higher score.

  • Price Change (%):

We normalize percentage change using min-max scaling within a defined range:

normalized = (value - min) / (max - min), clipped between -100% and +100%.

→ Captures relative price action momentum while avoiding outlier distortion.

  • Supply Ratio:

    Already expressed as ratios (0 to 1); no transformation required. All normalization logic is implemented in compute_results.py.

  1. Scoring:

    Each token’s normalized metric is multiplied by its corresponding weight coefficient (defined in the WEIGHTS dict in compute_results.py).

WEIGHTS = {
    "volume_1M": 0.1,
    "market_cap": 0.65,
    "liquidity": 0.05,
    "volatility": 0.05,
    "price_change_pct": 0.05,
    "supply_ratio": 0.05,
    "holder_count": 0.1,
}

Example: 

weighted_score = sum(normalized_scores[metric] * WEIGHTS[metric] for metric in available_metrics)

  1. Aggregation:

  • Sum the weighted scores for each token to get a final composite score.

  • The script sums the weighted normalized scores across all metrics.

  • If any metric is missing (e.g., no liquidity for BTC), that metric’s weight is excluded from the total and scores are re-normalized accordingly.

score /= sum(WEIGHTS[m] for m in available_metrics)

  1. Weight Allocation:

  • All tokens within the same index are then re-normalized so their scores sum to 1 (or 100% if multiplied).

  • The result is written to results.json as:

{
  "token_name": "Solana",
  "token_address": "...",
  "score": 0.89231,
  "weight": 0.34591
}

Monthly Rebalancing of Weights

Token weights are recalculated once per month. This cadence strikes a deliberate balance between responsiveness and stability:

  • Why monthly? Weekly rebalancing often chases short-term noise and volatile signals, which goes against the passive nature of our strategy.

  • Why not quarterly or longer? Longer intervals risk anchoring the index to outdated narratives, leaving exposure misaligned with current market conviction.

By recalculating weights monthly, we ensure the index:

  • Remains grounded in meaningful trends,

  • Adjusts to shifts in market dynamics,

  • Avoids being trapped in outdated themes,

  • And remains representative of what the market currently believes in.

This refresh rhythm enhances investor confidence by combining data-driven accuracy with thematic relevance - without sacrificing long-term conviction.

Special Cases

Multichain Index:

  • Birdeye does not provide metrics for native assets like BTC or ETH.

  • Use CoinGecko exclusively for Market Cap, Volume, Volatility, and Price Evolution.

  • Liquidity is skipped for those assets.

  • Data Gaps: If a token is missing data for a given metric, its score for that metric is set to 0, and the model recalculates weights proportionally.

Conclusion

This methodology is designed to balance momentum, fundamentals, safety, and growth potential in token selection and weighting. It ensures DiversiFi indexes are:

  • Transparent

  • Repeatable

  • Data-driven

  • Aligned with investor safety and opportunity

Weights can be recalculated monthly to adjust to evolving market conditions and maintain relevance.

Reproducibility

  • All scripts are modular and committed in the weights-calculation repo.

  • Required files:

    • indexes.json: token metadata and CGiD

    • fetch_helpers.py: API interaction logic

    • fetch_data.py: metric retrieval

    • compute_results.py: normalization and scoring

    • Results can be regenerated at any time by running the scripts sequentially in a Python environment.

Last updated: September 2025

PreviousVault systemNextIndex Token Price Calculation

Last updated