Реальные риски 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 недель в очереди).
Стоимость рассчитывается после детального обсуждения архитектуры и требований к безопасности. Закажите консультацию — оценим ваш проект за три дня.