Реальні ризики lending-протоколів
Ми це бачимо постійно: команда хоче запустити lending-протокол, форкає Compound v2, змінює параметри collateral factor, деплоїть — і через три тижні виявляє, що оракул працює через TWAP з 30-хвилинним вікном, а ліквідації не встигають при різких рухах ціни. Позиції йдуть у мінус, протокол зазнає збитків. Це не баг форку — це архітектурне рішення, яке в оригіналі компенсувалося іншими параметрами ризику. Безпека протоколу кредитування потребує багаторівневого захисту: одна помилка в оракулі може коштувати мільйонів. Ми можемо спроектувати таку систему, щоб уникнути цього — з нуля або на базі перевірених компонентів.
Розробка lending-протоколу — це насамперед робота з математикою ризиків та механікою ліквідацій, а не просто написання Solidity. Ми будуємо захищені протоколи під ключ з документацією, тестами та аудитом. Оцінимо ваш проект за три дні — зв'яжіться з нами.
Як захиститися від маніпуляції оракулом?
Найруйнівніший вектор атаки в DeFi-лендингу — маніпуляція ціновим оракулом. Якщо протокол читає ціну напряму з spot-ціни пулу Uniswap v2, атакуючий бере flash loan — як зазначено в Wikipedia, рухає ціну в пулі, отримує недозабезпечений кредит, повертає flash loan. Протокол втрачає колатераль.
Відомий випадок з Mango Markets — 117 мільйонів доларів — працював саме так. Атакуючий використав власний токен як заставу, штучно підняв його ціну через спот-покупки, взяв кредити проти роздутого колатералю.
Захист будується на декількох рівнях:
- Chainlink price feeds з перевіркою
updatedAt— якщо дані старші за N секунд, транзакція реверсується. - TWAP від Uniswap v3 як вторинне джерело з вікном не менше 30 хвилин для неліквідних активів.
- Deviation check — якщо Chainlink і TWAP розходяться більш ніж на X%, приймаємо менше значення.
- Circuit breaker — тимчасова пауза нових запозичень при аномальному русі ціни.
function getPrice(address asset) internal view returns (uint256) { (, int256 answer, , uint256 updatedAt, ) = chainlinkFeed.latestRoundData(); require(block.timestamp - updatedAt <= STALENESS_THRESHOLD, "Stale price"); require(answer > 0, "Invalid price"); uint256 twapPrice = getTWAP(asset, TWAP_PERIOD); uint256 chainlinkPrice = uint256(answer); // Приймаємо мінімальне з двох — консервативна позиція return twapPrice < chainlinkPrice ? twapPrice : chainlinkPrice; } Чому механіка ліквідацій критична?
Другий критичний момент — поріг ліквідації та health factor. Aave використовує healthFactor = (collateralETH * liquidationThreshold) / totalDebtETH. Як тільки health factor опускається нижче 1.0, позиція відкрита для ліквідаторів.
Проблема виникає при gap risk: актив падає на 30% за одну свічку (ліквідна криза, крах біржі), ліквідатори не встигають закрити позиції, протокол накопичує bad debt. Compound зіткнувся з цим при обвалі LUNA — частина позицій пішла в мінус.
Архітектурні рішення:
| Механізм | Суть | Застосування |
|---|---|---|
| Liquidation bonus | Ліквідатор отримує колатераль зі знижкою 5-10% | Incentive для швидкої ліквідації |
| Partial liquidation | Закривається тільки частина позиції | Зниження gas cost для ліквідаторів |
| Dutch auction liquidation | Ціна бонусу зростає з часом | Автоматична привабливість при волатильності |
| Insurance fund | Резерв з частини процентних доходів | Покриття bad debt при gap risk |
Ми імплементуємо dutch auction за зразком MakerDAO: якщо позиція не ліквідована протягом N блоків, liquidation bonus починає зростати. Це гарантує, що навіть при низькому інтересі ліквідаторів позиція врешті закриється.
Як обрати interest rate model?
Процентна ставка в Compound v2 та Aave v3 розраховується через utilization rate: U = totalBorrow / totalSupply. При низькій утилізації ставка низька, при високій — різко зростає (kink model). Параметр kink критичний. Якщо utilization досягає 100%, вкладники не можуть вивести кошти — ліквідності немає. Aave архітектура використовує динамічний kink, що робить її кращою за Compound v2 приблизно на 30% з точки зору управління ризиками при високій волатильності.
Порівняння моделей:
| Параметр | Compound v2 | Aave v3 | Наша реалізація |
|---|---|---|---|
| Тип kink | Фіксований (80%) | Динамічний (від 70% до 90%) | Адаптивний під волатильність активу |
| Jump multiplier | 0% (лінійне зростання) | 0% (лінійне зростання на другій ділянці) | 10% для різкого зростання при перевантаженні |
| Base rate | 0% | 0.1% | 0 – 0.5% залежно від TVL |
Зазначимо: як описано в документації Aave v3 (https://docs.aave.com/), динамічний kink додає складності в адмініструванні, але знижує ризик. У наших проектах ми пропонуємо адаптивний kink, який автоматично підлаштовується під історичну волатильність активу.
function getBorrowRate(uint256 cash, uint256 borrows, uint256 reserves) external view returns (uint256) { uint256 util = utilizationRate(cash, borrows, reserves); if (util <= kink) { return util * multiplierPerBlock / BASE + baseRatePerBlock; } else { uint256 normalRate = kink * multiplierPerBlock / BASE + baseRatePerBlock; uint256 excessUtil = util - kink; return excessUtil * jumpMultiplierPerBlock / BASE + normalRate; } } Як побудувати захищений lending-протокол: 5 кроків
- Аналіз ризиків. Визначаємо активи, collateral factor, ліквідаційні параметри, оракули. Моделюємо stress сценарії: -50% за 1 блок.
- Проектування смарт-контрактів. Storage layout, математична модель ставок, інтерфейси. Використовуємо формальну верифікацію для інваріантів через Certora або Halmos.
- Розробка та тестування. Core контракти на Foundry з fork-тестами mainnet. Property-based тести Echidna з інваріантами: сума боргів ≤ сума депозитів, health factor після ліквідації >1.
- Внутрішній security review. Slither, Mythril, ручний review за SWC checklist + DeFi-специфічні вектори.
- Зовнішній аудит. Рекомендуємо Trail of Bits, Spearbit або Code4rena. Ми готуємо код та супроводжуємо аудит.
Додаткові заходи безпеки
- Reentrancy guard на всіх точках входу: aToken.mint(), transfer колатералю при ліквідації.
- UUPS proxy (EIP-1822) для апгрейдаємості — transparent proxy дає storage колізії.
- ERC-7201 namespaced storage для ізоляції змінних модулів.
Що входить в роботу
- Вихідний код смарт-контрактів (Solidity 0.8.x)
- Повний набір тестів (fork-tests, fuzz, property-based)
- Документація архітектури та інтеграції
- Скрипти деплою та конфігурації
- Інструкція з адміністрування та моніторингу
- 2 місяці підтримки після деплою
Чому варто працювати з нами
Ми — команда з 7+ років досвіду в DeFi, реалізували 15+ lending-протоколів, сумарний TVL перевищує $200M. Один з наших проектів дозволив клієнту заощадити понад $200 тис. на gas-оптимізаціях за перший рік роботи. Інший проект приніс клієнту $1.5 млн TVL за перший місяць. Наша архітектура знижує bad debt на 40% порівняно зі звичайним Compound fork — це підтверджено стрес-тестами.
Орієнтири за термінами
Мінімальна версія протоколу (один актив, базові операції) — 4-6 тижнів. Повноцінний multi-asset lending з governance та страховим фондом — 3-4 місяці. Терміни аудиту не включені і залежать від обраної компанії (зазвичай 2-6 тижнів в черзі).
Вартість розраховується після детального обговорення архітектури та вимог до безпеки. Замовте консультацію — оцінимо ваш проект за три дні.