Розробка форку Aave для кастомного lending

Розробка форку Aave для кастомного lending

Форкнути Aave V3 — це не скачати репозиторій та поміняти параметри. Codebase Aave V3 містить 47 основних контрактів, 15 000+ строк Solidity, нетривіальну систему ролей та три різних proxy-паттерни. Більшість «форків», які ми аудитували, ломалися в одному з трьох місць: неправильна конфігурація PoolAddressesProvider, сломаний interest rate model, або відключена перевірка oracleType при додаванні нового активу. Будь-яка з цих помилок — потенційний дрейн фондів.

Де форкери найчастіше помиляються

PoolAddressesProvider та ролі

Aave V3 використовує PoolAddressesProvider як центральний реєстр адрес усіх контрактів системи. При деплое форка критично правильно ініціалізувати всі ролі:

• POOL_ADMIN — додає активи, мінює параметри ризиків
• EMERGENCY_ADMIN — може зупинити ринок при атаці
• RISK_ADMIN — змінює liquidation threshold та LTV
• FLASH_BORROWER — whitelist для нульової flash loan комісії
• ASSET_LISTING_ADMIN — листинг нових активів

Ми бачили форки, де всі ролі були на одному EOA без timelock. Один скомпрометований ключ — і атакуючий мінює оракул на свій контракт, листить фейковий актив з високим LTV, позичає проти нього всі реальні активи.

Правильна конфігурація: POOL_ADMIN та RISK_ADMIN — Gnosis Safe 3-of-5 з timelock 48 годин. EMERGENCY_ADMIN може бути 2-of-3 без timelock (потрібна швидка реакція при атаці).

Interest Rate Model: розрахунок та параметри

Aave використовує кусочно-лінійну модель ставок з оптимальною утилізацією. При утилізації нижче OPTIMAL_USAGE_RATIO ставка росте повільно, вище — експоненціально. Параметри моделі для кожного активу:

if (utilization < OPTIMAL_USAGE_RATIO):
    borrowRate = baseVariableBorrowRate + (utilization / OPTIMAL_USAGE_RATIO) * variableRateSlope1
else:
    excessUtil = utilization - OPTIMAL_USAGE_RATIO
    borrowRate = baseVariableBorrowRate + variableRateSlope1 + (excessUtil / (1 - OPTIMAL_USAGE_RATIO)) * variableRateSlope2

Помилка в параметрах — або ставки занадто низькі (LP не отримують справедливий yield), або занадто високі при стресі (каскадні ліквідації). Для кастомних активів ми калібруємо параметри на основі історичної волатильності та liquidity depth на CEX/DEX.

EMode та ізольовані активи

Aave V3 ввів два важливі механізми:

Efficiency Mode (eMode) — дозволяє задати категорію активів, які корельовані (наприклад, всі stablecoins або ETH деривативи). Усередині категорії LTV може бути 95%+, тому що ризик ліквідації при русі ціни мінімальний. Неправильне налаштування eMode — користувачі позичають більше, ніж повинні.

Isolation Mode — актив доступний як collateral тільки в ізоляції (не можна мішати з іншими). Важливий для довгохвостих активів з низькою ліквідністю.

Що та чому ми міняємо у форку

Кастомний oracle layer

Якщо форкуєте під Polygon, Arbitrum або zkSync — Chainlink Data Feeds доступні, але не для всіх активів. Для не-листованих активів потрібен кастомний оракул. Aave V3 використовує інтерфейс IPriceOracleGetter — достатньо реалізувати getAssetPrice(address asset) та зареєструвати в AaveOracle.

Для нових активів будуємо композитний оракул: primary source — Chainlink (якщо є), fallback — Uniswap V3 TWAP 30 хвилин. При розбіжності >5% між джерелами — circuit breaker, ліквідації тимчасово зупиняються.

Адаптований reserve factor

Reserve factor — процент від процентних доходів, який йде у treasury протоколу. У оригінальному Aave він варіюється від 10% (stablecoins) до 20–35% (більш волатильні активи). У форку можна налаштувати інакше: наприклад, 50% у treasury + 50% в insurance module для захисту від bad debt.

Змінення liquidation параметрів

Для кастомного форку під певну нішу (наприклад, NFT-коллатералізований lending) стандартні параметри ліквідації не працюють. NFT — неліквідний актив, миттєва ліквідація неможлива. Потрібен auction mode: ліквідатор відкриває аукціон, через 24–48 годин забирає актив. Це потребує повної переробки LiquidationLogic.sol.

Stack розробки форку

Ми працюємо з Aave V3 codebase від тега v3.0.1 або актуальної версії на момент початку проекту. Не беремо нефіксований main — у production йде тільки перевірена версія.

Foundry fork-тести — основа QA. Для кожного змінено модуля пишемо тести проти реального Aave V3 на mainnet: перевіряємо, що поведінка збігається для стандартних операцій та кастомна логіка працює тільки там, де потрібно.

# Тест liquidation на форку mainnet
forge test --fork-url $ETH_MAINNET_RPC --match-test testLiquidationWithCustomOracle -vvvv

Для фронтенду — Aave V3 Utilities SDK адаптується під кастомні параметри. wagmi + viem для підключення гаманців. The Graph subgraph для історичних даних по позиціям.

Мережі деплоя

Процес роботи

Аналітика (1 тиждень). Визначаємо, які активи листинговувати, які параметри ризиків потрібні, потребуються ли eMode категорії, який oracle layer підходить для цільової мережі.

Форк та адаптація (2–3 тижні). Деплой та налаштування PoolAddressesProvider, адаптація oracle layer, кастомізація параметрів ризиків, налаштування governance ролей.

Тестування (1–2 тижні). Fork-тести всіх операцій. Stress-тести: симуляція Black Thursday (ETH -40% за годину). Echidna property tests: solvency інваріант не нарушена при будь-якій послідовності операцій.

Аудит (2–4 тижні). Для форку зі змінено модулями — обов'язковий зовнішній аудит змінено частин. Для деплоя з мінімальними змінами — аудит конфігурації та параметрів.

Деплой та запуск. Поетапний: спочатку testnet (Sepolia/Arbitrum Goerli), потім mainnet з обмеженими лімітами, поступове зняття лімітів по мері зростання TVL.

Ориентири по строкам

Форк з мінімальними змінами (тільки параметри, новий оракул) — 3–5 тижнів. Форк з кастомним liquidation механізмом або eMode конфігурацією — 6–10 тижнів. Форк під нестандартний колатераль (NFT, RWA) — від 10 тижнів, включаючи розробку спеціалізованого liquidation engine.