Розробка системи автоматичного управління 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% залежно від активу), або завчасно переплатити за надлишковий колатераль. Система автоматичного управління health factor робить четвертий варіант — автономний rebalancer, який тримає позицію в безпечній зоні без участі користувача.

Математика ліквідації в 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 та позиція ліквідована.

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

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

Три стратегії ребалансування

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

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

Стратегія 3: Deleverage через flash loan. Найскладніша та найбільш капіталоефективна. Беремо flash loan (Aave V3 flashLoan або Uniswap V3 flash), погашаємо частину боргу, виводимо частину колатералю, повертаємо 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. Виводимо еквівалентний колатераль
    IPool(aavePool).withdraw(collateralAsset, collateralAmount, address(this));
    
    // 3. Своп колатераль → боргу токен через 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() нашому контракту — той може позичати від його імені, але не може виводити токени прямо. Це важливе обмеження: навіть при компрометації нашого контракту зловмисник не може вивести колатераль без додаткового кроку.

// Користувач один раз виконує
IVariableDebtToken(vDebtToken).approveDelegation(
    address(autoManager), 
    type(uint256).max
);

Додатковий захист: slippage guard на всі своп (максимум 0.5% відхилення від 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 тижні. Вартість розраховується після аналізу вимог.