Разработка системы взвешивания активов в индексе

Разработка системы взвешивания активов в индексе

Крипто-индекс без продуманной методологии взвешивания — это не индекс, а произвольная корзина токенов. TokenSets, Index Coop, Alongside — у каждого протокола своя математика. Выбор методологии напрямую влияет на доходность, концентрацию риска и ребалансировочные издержки. Неправильный выбор обходится дорого: ETH доминирует в market cap индексе с 60–70% весом, что делает индекс почти эквивалентным прямому холдингу ETH.

Методологии взвешивания: сравнение на практике

Market Cap Weighting (MCW)

Классика: вес актива пропорционален его рыночной капитализации. BTC + ETH = 70–80% любого MCW индекса. Следствие — низкая диверсификация, exposure на mega-cap за счёт small/mid-cap.

Реализация на Solidity: в каждом цикле ребалансировки запрашиваем цены через Chainlink для каждого актива, умножаем на circulating supply (хранится off-chain и передаётся через оракул), считаем веса, исполняем свапы для выравнивания.

Проблема: circulating supply нельзя надёжно получить on-chain. Большинство MCW индексов хранят supply данные в обновляемом маппинге и доверяют мультисигу обновление. Это вектор манипуляции.

Square Root Market Cap (SQRT MCW)

Применяем корень квадратный к market cap перед нормализацией. Вес = sqrt(mcap_i) / sum(sqrt(mcap_j)). ETH в том же составе падает с 65% до ~40%. Small-cap получают заметный вес. Index Coop использует вариацию этого подхода в DPI (DeFi Pulse Index).

Математика простая, реализация через on-chain sqrt — нет стандартной функции в Solidity, используем Babylonian method или FixedPointMathLib из 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)

Все активы имеют одинаковый вес. Максимальная диверсификация, максимальные ребалансировочные издержки: при 20 активах каждое ценовое движение создаёт дрейф весов. EW индекс с ежедневным ребалансированием на Ethereum mainnet — гарантированный убыток на газ. Реалистично для L2 (Arbitrum, Base) с газом в сотые доли цента.

Volatility-Adjusted Weighting

Вес обратно пропорционален волатильности актива: менее волатильный актив получает больший вес. Цель — минимизация общей волатильности портфеля (minimum variance approach).

Расчёт on-chain: нужны исторические цены для вычисления realized volatility. Это или Chainlink historical data (дорого), или собственный price oracle с rolling window хранением. На 20 активах с 30-дневным окном — хранение 600 ценовых точек в storage. При обновлении каждые 24 часа — умеренная нагрузка.

On-chain реализация весового расчёта

Fixed-point arithmetic для точности

Все расчёты весов в Solidity в integer с 18-знаковой точностью (WAD = 1e18). Пример нормализации весов:

// rawWeights[i] — ненормализованные веса (например sqrt от market cap)
uint256 totalWeight = 0;
for (uint i = 0; i < n; i++) {
    totalWeight += rawWeights[i];
}
// normalizedWeights[i] в WAD (сумма = 1e18)
for (uint i = 0; i < n; i++) {
    normalizedWeights[i] = rawWeights[i] * 1e18 / totalWeight;
}

Рauditing: проверить overflow при больших rawWeights, проверить что sum(normalizedWeights) == 1e18 ± 1 (погрешность округления).

Ребалансировочный триггер

Два подхода: time-based (каждые N блоков) и drift-based (когда отклонение любого актива от целевого веса превышает threshold, например 5%).

Drift-based эффективнее по газу: при стабильном рынке ребалансировки редки. Реализация через Chainlink Automation: checkUpkeep возвращает true если abs(currentWeight - targetWeight) > threshold для хотя бы одного актива.

Threshold = 5% означает: при 20 активах с EW 5% target, актив с весом 5.25% не триггерит ребаланс. Только при 5.26% — ребаланс. Это сокращает количество ребалансировок в 3–5 раз по сравнению с ежедневным.

Интеграция со свапом при ребалансировке

При ребалансировке контракт продаёт overweight активы и покупает underweight. Оптимальный маршрут — через DEX-агрегатор (1inch, Paraswap API) или напрямую через Uniswap v3 Universal Router. Для индекса важен atomic rebalancing: либо все свапы прошли, либо ни один. Если на середине ребалансировки транзакция ревертится — индекс застрял в несбалансированном состоянии.

Решение: batch swap в одной транзакции через multicall или кастомный rebalancer контракт с откатом через try/catch.

Процесс и сроки

Проектирование методологии (1 день): выбор подхода к взвешиванию, источники данных, ребалансировочный триггер.

Разработка контракта (2–3 дня): WeightCalculator с выбранной методологией, ребалансировочная логика, интеграция с оракулом.

Оракул и off-chain данные (1 день): если нужны supply данные или исторические цены — off-chain сервис обновления.

Тестирование (1 день): unit-тесты весовых расчётов с известными значениями, fork-тесты ребалансировки.

Итого: 3–5 дней для реализации с одной методологией. Мультиметодологические системы с governance-переключением — 1–2 недели. Стоимость рассчитывается индивидуально.