Ecosystem Index Methodology v2

Overview

As ecosystems grow and develop, so must our index token methodology. By improving our existing index methodology (current methodology can be found here), we can expand our index tokens to have a more diversified number of constituents, while also reducing the price impact incurred during rebalances.

Objective

1. Expand the eligible universe to include up to 10 tokens

2. Add bumper/ constraints rules to prevent sudden exclusion of existing tokens — To be included in a future iteration

3. Reduce price impact from inclusion and rebalancing

Eligible Universe Criteria

A token is considered eligible for index inclusion if it meets the all of the below criteria:

• Must be listed on Defi Llama with TVL data
• Must be listed on CoinGecko with Market Capitalization data
• Must have over $10,000 of liquidity in a single liquidity pool
• Must have existed for at least 2 months. This criteria will be measured by looking at liquidity pair creation dates in integrated DEXs.

Improved Index Methodology

Below is a simplified summary of the improved index methodology.

1. Within any specific ecosystem, the methodology looks at all tokens in that ecosystem that also meet the eligible universe criteria
2. These tokens are then ranked by Market Capitalization. The top 10 tokens are then considered by the methodology for inclusion and is assigned a Market Capitalization Weight
3. Ecosystem tokens (SOL for Solana, MATIC for Polygon, etc) are assigned a fixed weight of up to 50%. As ecosystems mature over time, we expect to lower fixed weight of ecosystem tokens and make room for other promising projects.
4. Next, a Maximum Allowed Weight (MAW) for each token is calculated. This metric takes the below variables into account:
5. Size of the largest liquidity pool for that individual token,
6. The estimated rebalance amount,
7. The tokens market cap weight
8. AUM of the basket.

The goal of this maximum weight limit is to reduce the potential slippage during 2 events:

1. Index construction — when the tokens are initially included in the index
2. Monthly rebalancings

A more detailed explanation of how MAW is calculated is available below.

1. Once each token’s MAW has been calculated, each token is then assigned the lesser value of the 2 weights (Market cap weight vs. Maximum Allowed Weight). The lessor of the 2 weights becomes the Token’s Initial Weight
2. If a token’s market cap weight is greater than its Maximum Allowed weight, then the extra funds are recursively redistributed to the other tokens until the assigned weights for each token add to 100%. Only after this recursive process is concluded do we arrive at each constituent token’s Final Weights.
3. For tokens with low liquidity, final weights can be smaller than the market cap weights to prevent high price slippage when rebalancing. On the other hand, for tokens with large amounts of liquidity, final weights can be greater than the initially assigned market cap weights to absorb excess weights.

Index Weight Optimization Process:

Step 1: Each underlying token is assigned its market cap based weight, except an ecosystem token (SOL for Solana, MATIC for Polygon, etc). A fixed weight of up to 50% is set to the ecosystem token. As ecosystems mature over time, we expect to lower the fixed weight of ecosystem tokens and make room for other promising projects.

Step 2: Maximum Allowed Rebalancing Amount is the USD amount that any trade can be executed without incurring more than 2%k. This amount is calculated from the liquidity pool size and a ratio of trade amount in USD to LP size in USD.

Based on this formula, to avoid price slippage greater than 2%, the trade amount cannot exceed 1% of the LP size.

Step 3: At most, we assume 10% of the token’s market cap weight will be rebalanced during each rebalance. Using this assumption of 10% rebalancing amount and the Maximum Allowed Rebalancing Amount, we can calculate maximum allowed weight.

Rearranging the above formula;

After the substitution for the rebalance amount, the maximum allowed weight is simply;

Step 4: For each token, Initial Weight is chosen to be the lesser of: 1) maximum allowed weight or 2) market cap based weight.

Step 5: Step 4 leads to a selection of weights where the sum of weights allocated may not add up to 100%. This is due to the presence of tokens whose maximum allowed weight is smaller than the market cap weight. The remaining portion of the portfolio is then recursively redistributed to the other tokens whose maximum allowed weight is higher than the market cap weight.

Step 6: The recursive redistribution from step 5 is repeated until all conditions are met and the portfolio weight sums up to 100%.