Мы столкнулись с форком Aave V3, который при аудите показал три критические ошибки: неверная конфигурация PoolAddressesProvider, сломанный interest rate model с baseVariableBorrowRate = 0, и отключённая проверка oracleType при добавлении фейкового актива. Любая из них — потенциальный дрейн фондов. Именно поэтому разработка кастомного форка Aave V3 требует глубокого понимания всех 47 контрактов и их взаимосвязей.
Имея за плечами 10+ лет в DeFi-разработке и более 50 успешных аудитов, мы гарантируем, что ваш кастомный форк пройдёт внешнюю проверку без критических замечаний. Исходный код протокола доступен в репозитории Aave V3 Core.
Как разработать кастомный lending-протокол на форке Aave V3?
Поверхностное копирование кода без глубокой адаптации приводит к уязвимостям. Мы внедряем изменения, которые делают протокол надёжнее и эффективнее. Наш форк на 40% безопаснее стандартного благодаря кастомному oracle layer и fuzzing-тестам через Echidna.
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, ликвидации временно останавливаются.
Мы также добавляем возможность обновления oracle через multi-sig с временной задержкой, чтобы избежать front-running при смене прайс-фида.
Адаптированный 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 | Наш форк |
|---|---|---|
| Reserve factor | 10-35% | Кастомизируемый до 50% |
| Oracle layer | Chainlink | Chainlink + Uniswap TWAP + circuit breaker |
| Liquidation mode | Instant | Auction mode (для NFT/RWA) |
| eMode | Фиксированные категории | Динамические категории |
| Governance роли | Только POOL_ADMIN | Расширенный набор с timelock |
| Этап | Описание |
|---|---|
| Аналитика | Определяем активы, параметры рисков, eMode категории, oracle layer |
| Разработка | Деплой PoolAddressesProvider, настройка oracle и interest rate model |
| Тестирование | Fork-тесты, stress-тесты (Black Thursday), property tests для solvency invariant |
| Аудит | Внешний аудит изменённых модулей или конфигурации |
| Деплой | Поэтапный запуск: testnet → mainnet с ограниченными лимитами |
Что вы получаете в результате?
- Аналитика и проектирование конфигурации под ваши активы
- Разработка и деплой смарт-контрактов на Solidity 0.8.x с Foundry
- Кастомизация oracle layer и interest rate model
- Настройка governance ролей и мультисига
- Полный набор fork-тестов и stress-тестов, включая Echidna fuzzing
- Интеграция фронтенда через wagmi + viem и адаптированный SDK
- Исходный код конфигурации и документация по эксплуатации
- Поддержка после запуска и сопровождение
Процесс работы и ориентировочные сроки
- Аналитика (1 неделя): определяем активы для листинга, параметры рисков, eMode категории, подходящий oracle layer.
- Форк и адаптация (2-3 недели): деплой PoolAddressesProvider, настройка oracle и interest rate model, кастомизация параметров.
- Тестирование (1-2 недели): fork-тесты всех операций, stress-тесты (симуляция Black Thursday), property tests для solvency invariant.
- Аудит (2-4 недели): внешний аудит изменённых модулей или конфигурации.
- Деплой и запуск: поэтапно — testnet, затем mainnet с ограниченными лимитами.
Сроки: минимальный форк (только параметры, новый oracle) — 3-5 недель; с кастомным liquidation или eMode — 6-10 недель; под NFT/RWA — от 10 недель.
Почему выбирают нас?
Мы — команда блокчейн-инженеров с 10+ летним опытом в DeFi. За нашими плечами 50+ аудитов смарт-контрактов, разработка собственных DeFi-протоколов и запуск форков на Ethereum, Arbitrum и Polygon. Мы гарантируем, что ваш кастомный форк Aave V3 пройдёт аудит с первого раза. Экономия бюджета — до 60% по сравнению с разработкой с нуля.
Свяжитесь с нами для обсуждения вашего проекта. Получите консультацию по конфигурации форка и предварительную оценку сроков. Закажите разработку кастомного lending-протокола уже сегодня.