Розробка системи автоматичного управління health factor
Користувач відкриває позицію в Aave: депозит 10 ETH, позика 8000 USDC. При ETH = $2000 health factor становить 1.56 — комфортна зона. ETH падає до $1400 за два дні. Коефіцієнт здоров'я = 1.09. Liquidation threshold пройдено при 1.0 — залишилося 9% буфера. Без автоматики у користувача три варіанти: тримати руку на пульсі 24/7, втратити позицію на ліквідації (штраф 5-15% від суми боргу), або заздалегідь переплатити за надлишкове забезпечення. Втрати при ліквідації можуть досягати 15% від вартості позиції — наша система здатна запобігти збиткам на тисячі доларів без участі користувача. Система, яку ми розробили, робить четвертий варіант — автономний ребалансер, який тримає позицію в безпечній зоні без участі користувача. Наш досвід у DeFi налічує 5+ років і більше 15 проєктів з управління ризиками. Наші інженери готові реалізувати таку систему для вашого проєкту. Згідно з документацією Aave V3 (Aave V3 Technical Paper), коефіцієнт ліквідації для ETH становить 82,5%.
Чому ручне управління health factor небезпечне?
Під час волатильності ринку ліквідації можуть відбуватися за секунди через MEV-ботів. Людина не встигає зреагувати на різке падіння ціни, особливо якщо оракул Chainlink затримує оновлення. Реальний безпечний поріг — HF >1.15–1.20 для волатильних активів. Підтримувати такий рівень вручну 24/7 практично неможливо.
Як математика ліквідації впливає на health factor?
Технічна формула 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 і включають транзакцію в той самий блок, де ціна оракула оновилася.
Який ризик становить затримка оракула Chainlink?
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-ризику.
Як працює автоматичний ребаланс?
Система використовує три стратегії, що вибираються залежно від конфігурації користувача та доступної ліквідності.
Три стратегії ребалансування
| Стратегія | Капіталоефективність | Складність | Типовий сценарій |
|---|---|---|---|
| Repay debt | Середня — потребує резерву | Низька | Просте зниження боргу |
| Add collateral | Низька — потребує резерву | Низька | Збереження розміру позики |
| Deleverage через flash loan | Висока — без резерву | Висока | Мінімізація капіталу |
Детальніше про стратегію deleverage через flash loan
Стратегія 3: Deleverage через flash loan. Найскладніша і найбільш капіталоефективна. Беремо flash loan (Aave V3 flashLoan або Uniswap V3 flash), погашаємо частину боргу, виводимо частину забезпечення, повертаємо flash loan. Користувач платить лише комісію (~0.05% Aave, 0.05% Uniswap V3), без необхідності тримати резервний капітал. Витрати на газ при кожному ребалансі — зазвичай кілька доларів на Ethereum, що значно нижче потенційних втрат від ліквідації.
// Спрощена логіка 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;
}
Детальніше про flash loan та Chainlink Automation.
Тригер-механізм: 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% deviation від TWAP), cooldown між ребалансами (мінімум 5 хвилин, щоб уникнути gas drain атак), обмеження максимальної суми операції за період. Всі контракти проходять аудит. Ми гарантуємо, що кожен контракт покривається тестами та перевіряється на вразливості.
Мультипротокольна підтримка
| Протокол | Тип даних HF | Flash loan доступний | Мережі |
|---|---|---|---|
| Aave V3 | getUserAccountData() |
Так, 0.05% | ETH, Polygon, Arbitrum, Optimism |
| Compound V3 | getBorrowableOf() |
Через Uniswap | ETH, Polygon, Arbitrum |
| Morpho | позиція per-market | Немає native | ETH, Base |
Система будується з абстракцією протоколу: інтерфейс 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 тижні.
Що входить в роботу
- Документація архітектури та API.
- Вихідний код смарт-контрактів з коментарями.
- Інтеграція з Chainlink Automation.
- Розгортання на mainnet через multisig.
- Навчання команди замовника.
- Технічна підтримка протягом 1 місяця після деплою.
Зв'яжіться з нами, щоб обговорити деталі та замовити розробку. Отримайте консультацію наших інженерів — оцінимо ваш проєкт безкоштовно. Розробка під ключ від 1 до 3 тижнів залежно від вимог.