Разработка системы автоматического ребалансирования индекса
Крипто-индексный фонд без автоматического ребалансирования — это не индекс, это снапшот. За квартал аллокации drift-уют на 15-30% от целевых весов из-за разной доходности активов. Ручное ребалансирование раз в месяц — это газ, время и отставание от целевых весов до 40% на пике волатильности. Автоматическая система должна решать три задачи одновременно: триггеры ребалансирования, оптимальный роутинг свапов и минимизация потерь от slippage и MEV.
Механики триггеров ребалансирования
Drift threshold vs. Time-based
Drift threshold — ребалансирование при отклонении веса любого актива от целевого на X%. Более газоэффективно: ребалансирование происходит только когда нужно. Проблема: в высоковолатильной среде можно ребалансироваться слишком часто (thrashing). Решение: cooldown period — минимальный интервал между ребалансированиями.
Time-based — по расписанию (daily, weekly). Предсказуемо, но неэффективно: может реконфигурировать портфель когда drift минимален и тратить газ без смысла.
Комбинированный триггер — ребалансирование при drift > threshold AND time_since_last > cooldown. Это стандарт для production систем.
On-chain расчёт текущих весов требует актуальных цен. Используем Chainlink для получения USD-стоимости каждого актива в портфеле. Расчёт: current_weight[i] = (balance[i] * price[i]) / total_aum.
Keeper-based исполнение
On-chain контракт хранит целевые веса и логику триггера, но сам не инициирует ребалансирование. Это задача off-chain keeper-ов — Chainlink Automation, Gelato Network, или собственный keeper с conditional execution.
Keeper вызывает checkUpkeep() — контракт возвращает (bool upkeepNeeded, bytes memory performData). Если upkeepNeeded = true — keeper вызывает performUpkeep(performData) с данными о том, какие свапы выполнить.
Это разделение важно: контракт не хранит логику выбора маршрута — это off-chain задача. Контракт только верифицирует что предложенные свапы соответствуют целевым весам с допустимым отклонением.
Оптимизация свапов при ребалансировании
Нетирование перед свапами
Перед исполнением свапов система считает нетто-изменение для каждого актива. Если нужно продать ETH на 10k USDC и купить BTC на 8k USDC — не делаем два свапа через промежуточный USDC. Делаем один: ETH → BTC напрямую (если ликвидный маршрут существует) + ETH → USDC на разницу 2k.
Нетирование сокращает количество свапов на 30-50% в типичном портфеле из 5-10 активов.
Slippage и размер свапа
Крупный свап через один пул Uniswap v3 даёт price impact. При ребалансировании портфеля $1M+ свап $200k ETH → USDC в пул с $5M ликвидностью — это ~4% price impact. Решения:
Split по времени — разбить ребалансирование на несколько транзакций с интервалом. TWAP-style исполнение. Более газозатратно, но меньше price impact.
Агрегация через 1inch или Paraswap — off-chain роутинг находит оптимальный split между пулами. Интеграция через 1inch AggregationRouter: swap(IAggregationExecutor executor, SwapDescription calldata desc, bytes calldata data). Данные для data генерируются off-chain через 1inch API.
MEV protection — крупные ребалансировочные свапы видны в mempool. Front-running добавляет к потерям от slippage ещё 0.5-1%. Решение: Flashbots protected transactions или 1inch Fusion (intent-based, без мемпула).
Валидация исполнения
После свапа контракт проверяет, что реализованные веса не отклонились от целевых больше чем на execution_tolerance (обычно 1-2%). Если отклонение выше — транзакция реверсируется. Это предотвращает ситуацию когда рыночные условия изменились между расчётом и исполнением.
function _validateWeights(uint256[] memory actualBalances, uint256[] memory targetWeights) internal view {
for (uint i = 0; i < actualBalances.length; i++) {
uint256 actualWeight = (actualBalances[i] * prices[i] * PRECISION) / totalAUM;
uint256 diff = actualWeight > targetWeights[i]
? actualWeight - targetWeights[i]
: targetWeights[i] - actualWeight;
require(diff <= executionTolerance, "Weight drift too high");
}
}
Управление индексом и governance
Обновление состава индекса
Добавление нового актива в индекс — это больше чем targetWeights[newAsset] = X. Нужно: добавить Chainlink price feed, проверить ликвидность актива на DEX (минимальный порог TVL пулов), обновить роутинг. Изменения состава через timelock + governance голосование.
Rebalancing pause и circuit breaker
В экстремальной волатильности (flash crash, depeg стейблкоина в портфеле) автоматическое ребалансирование может зафиксировать убытки в худший момент. Guardian address с правом паузы ребалансирования — стандартная практика. Дополнительно: circuit breaker — если цена актива упала >30% за последние 4 часа, ребалансирование приостанавливается автоматически.
Процесс разработки
Mechanism design (3-5 дней). Определяем: состав индекса, методологию весов (equal weight, market cap weight, custom), параметры триггеров, источники цен.
Контракты (1-2 недели). IndexVault (ERC-4626 совместимый) + RebalanceEngine + PriceOracle adapter. Foundry, fork-тесты на mainnet с историческими ценовыми данными.
Keeper интеграция (3-5 дней). Chainlink Automation setup, off-chain routing сервис (Node.js + 1inch API), мониторинг исполнения.
Тестирование (1 неделя). Backtest на исторических данных — симулируем ребалансирования за последние 12 месяцев, считаем слипедж и gas costs. Сравниваем с buy-and-hold benchmark.
Ориентиры по срокам
Базовая система для индекса из 3-5 активов с time-based ребалансированием — 1-2 недели. Полноценная система с drift-триггерами, keeper автоматизацией, MEV-защитой и governance — от 3-4 недель.
Стоимость рассчитывается после обсуждения состава индекса и требований к автоматизации.