Разработка форка 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 — белый список для нулевой flash loan fee
• ASSET_LISTING_ADMIN — листинг новых активов

Мы видели форки, где все роли были на одном EOA без timelock. Один скомпрометированный ключ — и атакующий меняет oracle на свой контракт, листит фейковый актив с высоким 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 — пользователи берут в долг больше, чем должны.

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

Что и почему меняем в форке

Кастомный oracle layer

Если форкаете под Polygon, Arbitrum или zkSync — Chainlink Data Feeds доступны, но не для всех активов. Для нелистованных активов нужен кастомный oracle. 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 parameters

Для кастомного форка под определённую нишу (например, NFT-коллатерализованный lending) стандартные параметры ликвидации не работают. NFT — неликвидный актив, instant liquidation невозможна. Нужен auction mode: ликвидатор открывает аукцион, через 24-48 часов забирает актив. Это требует полной переработки LiquidationLogic.sol.

Стек разработки форка

Мы работаем с 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 invariant не нарушается при любой последовательности операций.

Аудит (2-4 недели). Для форка с изменёнными модулями — обязательный внешний аудит изменённых частей. Для деплоя с минимальными изменениями — аудит конфигурации и параметров.

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

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

Форк с минимальными изменениями (только параметры, новый oracle) — 3-5 недель. Форк с кастомным liquidation mechanism или eMode конфигурацией — 6-10 недель. Форк под нестандартный коллатерал (NFT, RWA) — от 10 недель, включая разработку специализированного liquidation engine.