Index Asset Weighting System Development

We design and develop full-cycle blockchain solutions: from smart contract architecture to launching DeFi protocols, NFT marketplaces and crypto exchanges. Security audits, tokenomics, integration with existing infrastructure.
Showing 1 of 1 servicesAll 1306 services
Index Asset Weighting System Development
Medium
~3-5 business days
FAQ
Blockchain Development Services
Blockchain Development Stages
Latest works
  • image_website-b2b-advance_0.png
    B2B ADVANCE company website development
    1214
  • image_web-applications_feedme_466_0.webp
    Development of a web application for FEEDME
    1161
  • image_websites_belfingroup_462_0.webp
    Website development for BELFINGROUP
    852
  • image_ecommerce_furnoro_435_0.webp
    Development of an online store for the company FURNORO
    1041
  • image_logo-advance_0.png
    B2B Advance company logo design
    561
  • image_crm_enviok_479_0.webp
    Development of a web application for Enviok
    823

Developing an Index Asset Weighting System

A crypto index without a thoughtful weighting methodology is not an index, it's an arbitrary token basket. TokenSets, Index Coop, Alongside — each protocol has its own math. The choice of methodology directly impacts returns, risk concentration, and rebalancing costs. Wrong choice is expensive: ETH dominates market cap indices at 60–70% weight, making the index almost equivalent to direct ETH holding.

Weighting Methodologies: Practical Comparison

Market Cap Weighting (MCW)

Classic approach: asset weight proportional to market capitalization. BTC + ETH = 70–80% in any MCW index. Consequence — low diversification, mega-cap exposure at small/mid-cap's expense.

Solidity implementation: on each rebalance cycle, fetch prices via Chainlink for each asset, multiply by circulating supply (stored off-chain, passed via oracle), calculate weights, execute swaps for alignment.

Problem: circulating supply can't be reliably obtained on-chain. Most MCW indices store supply data in updatable mapping and trust multisig for updates. This is a manipulation vector.

Square Root Market Cap (SQRT MCW)

Apply square root to market cap before normalization. Weight = sqrt(mcap_i) / sum(sqrt(mcap_j)). ETH in same composition falls from 65% to ~40%. Small-cap gets notable weight. Index Coop uses a variation in DPI (DeFi Pulse Index).

Math is simple, on-chain sqrt implementation — no standard Solidity function, use Babylonian method or FixedPointMathLib from Solmate:

function sqrt(uint256 x) internal pure returns (uint256) {
    if (x == 0) return 0;
    uint256 z = (x + 1) / 2;
    uint256 y = x;
    while (z < y) { y = z; z = (x / z + z) / 2; }
    return y;
}

Equal Weight (EW)

All assets have same weight. Maximum diversification, maximum rebalancing costs: with 20 assets, every price move creates weight drift. EW index with daily rebalancing on Ethereum mainnet — guaranteed loss on gas. Realistic for L2 (Arbitrum, Base) with gas in fractions of a cent.

Volatility-Adjusted Weighting

Weight inversely proportional to volatility: less volatile asset gets bigger weight. Goal — minimize overall portfolio volatility (minimum variance approach).

On-chain calculation: need historical prices to compute realized volatility. Either Chainlink historical data (expensive) or custom price oracle with rolling window storage. 20 assets with 30-day window — store 600 price points. Updating every 24 hours — moderate load.

Methodology Diversification Rebalance Gas Oracle Complexity
Market Cap Low Low High (supply)
SQRT Market Cap Medium Low High (supply)
Equal Weight High High Prices only
Volatility-Adj High Medium Prices + history
Fundamental Medium Low TVL/Volume data

On-Chain Weight Calculation Implementation

Fixed-Point Arithmetic for Precision

All weight calculations in Solidity as integers with 18-digit precision (WAD = 1e18). Example weight normalization:

// rawWeights[i] — unnormalized weights (e.g., sqrt of market cap)
uint256 totalWeight = 0;
for (uint i = 0; i < n; i++) {
    totalWeight += rawWeights[i];
}
// normalizedWeights[i] in WAD (sum = 1e18)
for (uint i = 0; i < n; i++) {
    normalizedWeights[i] = rawWeights[i] * 1e18 / totalWeight;
}

Auditing: check overflow on large rawWeights, check that sum(normalizedWeights) == 1e18 ± 1 (rounding error).

Rebalancing Trigger

Two approaches: time-based (every N blocks) and drift-based (when any asset deviates >threshold from target, e.g., 5%).

Drift-based is more gas-efficient: on stable market, rebalancing is rare. Implementation via Chainlink Automation: checkUpkeep returns true if abs(currentWeight - targetWeight) > threshold for any asset.

Threshold = 5% means: with 20 EW assets at 5% target, asset at 5.25% weight doesn't trigger rebalance. Only at 5.26% — rebalance happens. This reduces rebalancing count 3–5x vs daily.

Swap Integration on Rebalancing

On rebalance, contract sells overweight assets and buys underweight. Optimal route — via DEX aggregator (1inch, Paraswap API) or direct Uniswap v3 Universal Router. For index, atomic rebalancing is important: all swaps execute or none. If rebalancing reverts mid-way — index is stuck in unbalanced state.

Solution: batch swap in one transaction via multicall or custom rebalancer contract with rollback via try/catch.

Process and Timeline

Methodology design (1 day): choose weighting approach, data sources, rebalancing trigger.

Contract development (2–3 days): WeightCalculator with chosen methodology, rebalancing logic, oracle integration.

Oracle and off-chain data (1 day): if supply data or historical prices needed — off-chain service for updating.

Testing (1 day): unit tests on weight calculations with known values, fork tests on rebalancing.

Total: 3–5 days for single methodology implementation. Multi-methodology systems with governance switching — 1–2 weeks. Cost calculated individually.