Розробка крипто-лендингової платформи
Протокол Euler Finance втратив $197M у березні 2023 року. Вразливість — у функції donateToReserves, яка дозволяла накопичувати дефіцит без відповідної перевірки collateral. Атакуючий використав flash loan для створення позиції з порушеним health factor, а потім ліквідував себе через donate-механіку. Це була не очевидна помилка — код пройшов кілька аудитів.
Лендингові протоколи — одна з найскладніших категорій DeFi за кількістю векторів атак. Кожна функція (deposit, borrow, repay, liquidate) взаємодіє з іншими, та інваріанти системи нетривіальні.
Критичні вразливості лендингових протоколів
Oracle manipulation та cascading liquidations
Лендинговий протокол залежить від price oracle для розрахунку collateral ratio. Компрометація оракула = можливість взяти кредит під переоцінену collateral або уникнути ліквідації.
Cream Finance втратила $130M у 2021 році саме через oracle manipulation: токен з тонкою ліквідністю використовувався як collateral, його ціна була маніпульована через flash loan в AMM-пулі, та атакуючий отримав кредит на багаторазово перевищуючу реальну суму.
Захист — многоосередний оракул:
- Chainlink як primary feed з перевіркою
latestRoundDataна staleness (>1 година — pause) - TWAP з Uniswap v3 як secondary з вікном 30 хвилин
- Circuit breaker: якщо два оракула розходяться більше ніж на 5% — new borrows suspended
Cascading liquidations — окремої проблеми. При різкому падінні ринку одночасна ліквідація тисяч позицій давить ціну активу вниз, що триггерить нові ліквідації. Compound v3 вирішує це через liquidation caps на рівні протоколу.
Розрахунок health factor та целочислена точність
Тут вчиняється більшість помилок. Health factor = (collateralValue * collateralFactor) / borrowedValue. Коли це рахується з uint256 без правильного масштабування — округлення режить точність.
Конкретний приклад: collateral 1.001 ETH при collateralFactor 0.8 дає 0.8008 ETH покриття. Borrow 0.8 ETH. Health factor повинен бути 1.001. Якщо розрахунок робиться через (collateral * factor / 1e18) / borrow, а не через mulDiv — можлива втрата точності, при якій здорова позиція помічається як ліквідуємо.
Використовуємо FullMath.mulDiv з Uniswap v3 core для всіх розрахунків, де важливо точність. Жодного ділення до всіх множень.
Reentrancy у liquidate + transfer ланцюгах
Функція liquidate зазвичай робить кілька дій: забирає collateral у позичальника, погашає борг, виплачує бонус ліквідатору. Якщо токен collateral реалізує ERC-777 або має кастомний transfer hook — є вікно для reentrancy між етапами.
AAVE v3 використовує ReentrancyGuard на рівні Pool контракту та додатково — перевірку флага _status у critical paths. Для будь-якого лендингового протоколу — nonReentrant на deposit, borrow, repay, liquidate обов'язковий.
Архітектура протоколу
Модульна структура за образцем Compound v3
Comptroller / RiskManager
├── CToken / CometMarket (per asset)
│ ├── InterestRateModel
│ └── PriceOracle
├── LiquidationEngine
└── GovernanceModule
Окремий контракт на кожен підтримуваний актив (CToken-паттерн) vs єдиний Comet-контракт з маппінгами — принципове архітектурне рішення. CToken-паттерн простіший для аудиту та ізоляції ризику: проблема в одному ринку не торкається інших. Єдиний контракт дешевше в деплое та простіший для користувачів.
Interest rate model
Kinked interest rate — стандарт: низька ставка при utilization < 80%, різкий зростання вище. Формула:
- Якщо
U < kink:borrowRate = baseRate + slope1 * U - Якщо
U >= kink:borrowRate = baseRate + slope1 * kink + slope2 * (U - kink)
При utilization 95% ставки можуть досягати 100%+ APR — це механізм тиску на позичальників для повернення ліквідності в пул.
Параметри (baseRate, slope1, slope2, kink) повинні бути змінювані через governance з timelock. Ринок змінюється, оптимальні параметри змінюються разом з ним.
Liquidation mechanics
Liquidation bonus (5-10% від collateral) — винагорода ліквідатору. Занадто малий бонус — ліквідатори не зацікавлені, протокол накопичує bad debt. Занадто великий — позичальники втрачають більше при ліквідації, ніж розумно.
Partial liquidation (погашення тільки частини боргу) — обов'язкова. Повна ліквідація великої позиції за один раз вимагає величезного капіталу у ліквідатора. Compound v3 дозволяє ліквідувати до health factor 1.05.
Flash loan ліквідації — стандартний паттерн. Ліквідатор бере flash loan, погашає борг, отримує collateral (з бонусом), продає на DEX, повертає flash loan + fee. Протокол повинен підтримувати це — тобто не блокувати вивід collateral у тій же транзакції.
Підтримувані активи та collateral factors
| Актив | Collateral Factor | Liquidation Threshold | Приклад (Aave v3) |
|---|---|---|---|
| ETH/WETH | 80% | 82.5% | 80% / 82.5% |
| WBTC | 70% | 75% | 70% / 75% |
| USDC | 85% | 88% | 86% / 88% |
| LINK | 65% | 70% | 65% / 70% |
| Volatile ERC-20 | 40-60% | 50-65% | varies |
Isolation mode (Aave v3) — активи з обмеженим долговим стелею, використовуються тільки як collateral для стейблкоїнів. Для нових або менш ліквідних активів це правильна стратегія: знижує системний ризик.
Процес розробки
Специфікація (3-5 днів). Які активи, які interest rate моделі, є ли governance, потрібна ліапгрейдаємість.
Математичні специфікації (2-3 дні). Всі формули верифікуємо на Python-референсі до написання Solidity. Це економить тиждень отладки у контрактах.
Розробка (4-6 тижнів). Foundry + fuzz-тести на всі інваріанти: health factor не може стати негативним, загальний борг не перевищує резерви, liquidation bonus рахується коректно.
Fork-тестування. Симуляція flash loan атак на форку mainnet. Тест cascading liquidations через price manipulation.
Зовнішній аудит. Обов'язков для будь-якого протоколу з TVL. Бажано — два незалежних аудитори.
Орієнтири за часовими рамками
Мінімальний лендинговий протокол (один актив, базова ліквідація) — 4-6 тижнів. Повнофункціональна платформа з кількома ринками, governance, апгрейдами — 2-3 місяці. Аудит — додатково 4-8 тижнів залежно від обсягу коду.