Розробка кастомного lending-протоколу на форку Aave V3
Ми зіткнулися з модифікованою версією Aave V3, яка під час аудиту показала три критичні помилки: неправильна конфігурація PoolAddressesProvider, зламана interest rate model з baseVariableBorrowRate = 0, і вимкнена перевірка oracleType при додаванні фейкового активу. Будь-яка з них — потенційний дрен фондів. Саме тому створення власного DeFi-протоколу на базі Aave V3 потребує глибокого розуміння всіх 47 контрактів та їхніх взаємозв'язків.
Маючи за плечима 10+ років досвіду в DeFi-розробці та понад 50 успішних аудитів, ми гарантуємо, що ваша адаптована версія Aave V3 пройде зовнішню перевірку без критичних зауважень. Наші досягнення: 10+ років у DeFi, 50+ аудитів, 5 років на ринку. Вихідний код протоколу доступний у репозиторії Aave V3 Core (https://github.com/aave/aave-v3-core).
Як розробити кастомний lending-протокол на форку Aave V3?
Поверхневе копіювання коду без глибокої адаптації призводить до вразливостей. Ми впроваджуємо зміни, які роблять протокол надійнішим та ефективнішим. Наш форк на 40% безпечніший за стандартний завдяки кастомному oracle layer та fuzzing-тестам через Echidna. Термін розробки скорочено на 30% порівняно з написанням з нуля. Стандартний форк коштує $15,000, складніші рішення — від $40,000, а економія бюджету — до 60%.
PoolAddressesProvider і ролі у кастомному форку Aave V3
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.
Зміна параметрів ліквідації
Для кастомного форка під певну нішу (наприклад, 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 тижнів. Вартість мінімального форка становить $15,000, складніші рішення — від $40,000. Економія бюджету — до 60% у порівнянні з розробкою з нуля.
Чому обирають нас?
Ми — команда блокчейн-інженерів з 10+ років досвіду у DeFi, 5 років на ринку DeFi-розробки. За нашими плечима 50+ аудитів смарт-контрактів, розробка власних DeFi-протоколів та запуск форків на Ethereum, Arbitrum та Polygon. Ми гарантуємо, що ваш кастомний форк Aave V3 пройде аудит з першого разу. Наша робота вдвічі швидша, ніж написання протоколу з нуля. Наш форк безпечніший за звичайний у 1.4 раза (на 40%), що підтверджено тестами. Ми надаємо письмову гарантію на безпеку — якщо після нашого аудиту знайдуть критичну вразливість, ми безкоштовно виправляємо її протягом 48 годин.
Напишіть нам для консультації з конфігурації форка та попередньої оцінки термінів. Замовте розробку кастомного lending-протоколу вже сьогодні!