Developing a crypto index without a thoughtful asset weighting system is not an index—it's an arbitrary basket. We've encountered projects where BTC and ETH dominance in a market cap index reached 80%, defeating the purpose of diversification. In one real case, an MCW index on Ethereum mainnet required daily rebalancing with gas costs of $50–200 per operation, eating up to 30% of annual returns. We replaced the methodology with SQRT and moved to Arbitrum: gas dropped to $2, diversification improved, and rebalances became infrequent. Our approach is to select a methodology aligned with portfolio goals and implement it in Solidity with minimal gas and maximum reliability. We have 10+ years of experience in DeFi and have developed over 15 weighting systems for various indices.
How to Choose an Asset Weighting System for a Crypto Index?
Market Cap Weighting (MCW)
Classic approach: weight proportional to market cap. BTC + ETH occupy 70–80% of any MCW index—resulting in low diversification and mega-cap bias. Solidity implementation: fetch prices via Chainlink, multiply by circulating supply (stored off-chain, updated via multisig). Issue: supply data cannot be reliably obtained on-chain—manipulation via multisig.
Square Root Market Cap (SQRT MCW)
Apply sqrt to market cap: weight = sqrt(mcap_i) / sum(sqrt(mcap_j)). ETH drops from 65% to ~40%, small-caps gain noticeable weight. Index Coop uses a variant in DPI. On-chain sqrt—no built-in Solidity function; use Babylonian method or Solmate library. Example code:
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 equal weight—maximum diversification, but rebalancing costs high: with 20 assets, every price move creates drift. Daily rebalancing on Ethereum mainnet—guaranteed loss to gas. Realistic only on L2s (Arbitrum, Base) with gas in cents.
Volatility-Adjusted Weighting
Weight inversely proportional to volatility—less volatile assets weigh more. Goal: minimize overall portfolio volatility. On-chain calculation: historical prices for realized volatility via Chainlink (expensive) or a custom rolling window. For 20 assets with a 30-day window—600 storage entries, updated once a day—moderate load.
| Methodology | Diversification | Gas per Rebalance | 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 |
How to Implement Weighting in Solidity Without Losing Precision?
Fixed-Point Arithmetic for Precision
All calculations in integers with 18 decimal precision (WAD = 1e18). Normalization example:
uint256 totalWeight = 0; for (uint i = 0; i < n; i++) { totalWeight += rawWeights[i]; } for (uint i = 0; i < n; i++) { normalizedWeights[i] = rawWeights[i] * 1e18 / totalWeight; } Check for overflow with large rawWeights and ensure normalizedWeights sum to 1e18 within ±1.
Rebalancing Trigger
Two approaches: time-based (every N blocks) and drift-based (deviation from target weight > threshold, e.g., 5%). Drift-based is more efficient: in stable markets, few rebalances. Implement via Chainlink Automation: checkUpkeep returns true if |currentWeight - targetWeight| > threshold for any asset. A 5% threshold reduces rebalances by 3–5 times, saving up to 40% in gas.
Trigger Comparison
| Parameter | Time-based (24h) | Drift-based (5% threshold) |
|---|---|---|
| Rebalances per year | ~365 | ~70 |
| Gas (yearly) | High | Up to 40% lower |
| Slippage | Stable | Lower in calm markets |
Integration with Swaps
During rebalance, sell overweight assets and buy underweight ones. Optimal route: via a DEX aggregator (1inch, Paraswap) or directly Uniswap v3 Universal Router. Atomic rebalancing is critical: all swaps in a single transaction via multicall or try/catch with revert. If the transaction reverts mid-way, the index becomes stuck.
What the Process Includes
- Requirements analysis—select methodology, data sources, rebalancing trigger.
- Architecture design—smart contract specification, oracle layout.
- Development—WeightCalculator, Rebalancer, integration with external protocols.
- Testing—unit tests for weight calculations, fork tests with real prices and rebalance simulation.
- Deployment and documentation—deployment instructions, contract addresses, ongoing support.
Common Pitfalls When Designing a Weighting System
- Using floating point in Solidity—banned; use fixed-point only.
- Not accounting for supply data in MCW—leading to incorrect weights when circulating supply changes.
- Missing slippage protection in rebalance swap logic—can lead to sandwich attacks.
- Rebalancing in a single transaction without a partial fill revert—index gets stuck.
Timeline and Cost
Timeline depends on complexity: for a single methodology—3 to 5 days; for a multi-methodology system with governance switching—1–2 weeks. Cost is calculated individually after discussing your index.
Contact us for a consultation—we'll help you choose a methodology and evaluate the project. Get a free analysis of your index and launch weighting with minimal risk.