Разработка системы автоматического управления health factor

Разработка системы автоматического управления health factor

Пользователь открывает позицию в Aave: депозит 10 ETH, займ 8000 USDC. Health factor при ETH = $2000 составляет 1.56 — комфортная зона. ETH падает до $1400 за два дня. Health factor = 1.09. Liquidation threshold пройден при 1.0 — осталось 9% буфера. Без автоматики у пользователя три варианта: держать руку на пульсе 24/7, потерять позицию на ликвидации (штраф 5-15% в зависимости от актива), или заранее переплатить за избыточный collateral. Система автоматического управления health factor делает четвёртый вариант — автономный rebalacer, который держит позицию в безопасной зоне без участия пользователя.

Математика ликвидации в Aave V3

Что такое health factor технически

HF = (∑ collateral_i × price_i × liquidationThreshold_i) / totalDebt

Каждый актив в Aave V3 имеет свой liquidationThreshold (выражен в basis points, например ETH = 8250 = 82.5%). При HF < 1.0 позиция ликвидируема. Ликвидатор вызывает liquidationCall(), получает бонус liquidationBonus (для ETH = 10500 = 105% — то есть 5% premium сверх долга).

На практике ликвидации происходят раньше 1.0 — MEV-боты мониторят mempool и включают транзакцию в тот же блок, где цена оракула обновилась. Реальный безопасный порог — HF > 1.15-1.20 для волатильных активов.

Риск Chainlink oracle latency

Aave V3 использует Chainlink агрегаторы с heartbeat 1 час для большинства пар. Во время быстрого движения цены (flash crash) оракул может опаздывать до 30-60 минут. За это время on-chain цена ETH в Aave отличается от реальной биржевой на 5-10%. Это создаёт ситуацию, когда наша система видит HF = 1.25, но после следующего оракульного обновления HF мгновенно становится 0.95 и позиция ликвидируется.

Обработка этого сценария — один из ключевых инженерных вызовов. Наша система учитывает delta между текущей Chainlink ценой и ценой на Uniswap TWAP (30-минутный) как косвенный индикатор latency-риска.

Архитектура системы управления health factor

Три стратегии ребалансирования

Стратегия 1: Repay debt. При падении HF ниже target threshold система берёт средства из резервного буфера пользователя (заранее депонированные на контракт) и частично погашает долг через repay(). Просто, предсказуемо, без сложных операций. Минус: требует резервного капитала.

Стратегия 2: Add collateral. Депозит дополнительного collateral через supply(). Также требует резервов, но не уменьшает leverage пользователя. Подходит, когда цель — удержать размер займа неизменным.

Стратегия 3: Deleverage через flash loan. Самая сложная и наиболее капиталоэффективная. Берём flash loan (Aave V3 flashLoan или Uniswap V3 flash), погашаем часть долга, выводим часть collateral, возвращаем flash loan. Пользователь платит только комиссию (~0.05% Aave, 0.05% Uniswap V3), без необходимости держать резервный капитал.

// Упрощённая логика deleverage через Aave flash loan
function executeOperation(
    address[] calldata assets,
    uint256[] calldata amounts,
    uint256[] calldata premiums,
    address initiator,
    bytes calldata params
) external returns (bool) {
    // assets[0] = долговой токен (USDC)
    // amounts[0] = сумма к погашению
    
    // 1. Погашаем долг в Aave
    IPool(aavePool).repay(assets[0], amounts[0], 2, userAddress);
    
    // 2. Выводим эквивалентный collateral
    IPool(aavePool).withdraw(collateralAsset, collateralAmount, address(this));
    
    // 3. Свапаем collateral → долговой токен через Uniswap V3
    swapExactOutputSingle(collateralAsset, assets[0], amounts[0] + premiums[0]);
    
    // 4. Возвращаем flash loan + premium
    IERC20(assets[0]).approve(aavePool, amounts[0] + premiums[0]);
    return true;
}

Триггер-механизм: Chainlink Automation

Для мониторинга HF используем Chainlink Automation (бывший Keeper Network). checkUpkeep() читает текущий HF через IPool.getUserAccountData(), сравнивает с target threshold. Если HF < threshold — performUpkeep() вызывает нужную стратегию.

Важный нюанс: checkUpkeep() выполняется off-chain нодами Chainlink. Это значит, что внутри него можно делать дорогие вычисления без газа. Мы выносим всю математику выбора стратегии туда, а performUpkeep() получает уже готовые параметры через performData.

Альтернатива — собственный keeper bot. Дешевле при высоком объёме пользователей, но требует инфраструктуры (VPS, мониторинг uptime). Для B2C продуктов рекомендуем Chainlink — нет зависимости от нашего сервера.

Ролевая модель и безопасность

Контракт управляет позицией от имени пользователя через delegatecredit механизм Aave. Пользователь выдаёт approveDelegation() нашему контракту — тот может занимать от его имени, но не выводить токены напрямую. Это важное ограничение: даже при компрометации нашего контракта атакующий не может вывести collateral без отдельного шага.

// Пользователь один раз выполняет
IVariableDebtToken(vDebtToken).approveDelegation(
    address(autoManager), 
    type(uint256).max
);

Дополнительная защита: slippage guard на все свапы (максимум 0.5% deviation от TWAP), cooldown между ребалансами (минимум 5 минут, чтобы избежать gas drain атак), ограничение максимальной суммы операции за период.

Мультипротокольная поддержка

Система строится с абстракцией протокола: ILendingAdapter интерфейс позволяет добавлять новые протоколы без переписывания core логики.

Процесс работы

Аналитика (2-3 дня). Определяем протоколы, активы, target HF threshold, выбираем стратегию ребалансирования. Моделируем в Python сценарии: ETH -50% за 24 часа, flash crash до -80%, gradual decline. Проверяем, что система успевает среагировать при realistic Chainlink latency.

Разработка (5-7 дней). Core контракт, adapter для Aave V3/Compound, Chainlink Automation интеграция, fuzz-тесты на граничные значения HF. Fork-тесты на mainnet с реальными позициями через vm.prank.

Тестирование edge cases (2-3 дня). Симуляция: Chainlink оракул застыл на 2 часа, Aave pool paused, Uniswap V3 pool с низкой ликвидностью. Каждый сценарий — отдельный Foundry тест с fork.

Деплой (1-2 дня). Goerli/Sepolia с тестовыми Aave, затем mainnet через multisig.

Базовая система с одной стратегией и одним протоколом — 1-1.5 недели. Мультистратегия с мультипротокольной поддержкой и кастомным дашбордом — 2-3 недели. Стоимость рассчитывается после анализа требований.