Мы часто сталкиваемся с ситуацией, когда стандартный liquidation engine перестаёт справляться при высокой волатильности. Aave V3 теряет ликвидатора быстрее, чем вы думаете. При нагрузке на сеть газ на liquidationCall вырастает до 400-600k gas units — при цене 80 gwei это 0.03-0.05 ETH только на газ. Если спред между долгом и залогом меньше этой суммы, ликвидация нерентабельна, и позиция висит в состоянии bad debt. Именно поэтому дизайн инцентивов ликвидаторов — не детали, а основа платёжеспособности всего lending-протокола.
Почему стандартный протокол ликвидаций терпит коллапс?
Health factor каждой позиции рассчитывается как сумма коллатерала, умноженная на liquidation threshold (LT), делённая на долг. Когда HF < 1 — позиция ликвидируема. HT зависит от актива: ETH — 82.5%, USDC — 85%, более волатильные активы — 65-75%. Кастомный lending с экзотическими активами требует тщательной калибровки LT на основе исторической волатильности.
Проблема пылевых позиций: если позиция маленькая (долг $50), газ на ликвидацию ($30-80) съедает всю прибыль. Ликвидаторы игнорируют такие позиции — протокол накапливает bad debt. Решение — minimum debt threshold (минимальный размер позиции) или flat fee компонент в инцентиве.
Для позиций с залогом >$10M возникает другая проблема: ликвидатор не может ликвидировать сразу из-за slippage при продаже залога — цена падает, bonus нивелируется. Aave V3 решает это через partial liquidation (до 50% за раз) и close factor. Для кастомных протоколов мы реализуем dutch auction: bonus стартует с 5% и растёт со временем, пока позиция не ликвидирована.
Профессиональные ликвидаторы используют flash loans: берут актив в долг, погашают позицию, забирают залог с бонусом, продают и возвращают заём. Всё в одной транзакции с нулевым капиталом. Ваш протокол должен быть совместим с asyncCall в liquidationCall. MEV-боты часто перехватывают ликвидации через frontrunning — это не всегда плохо, но для защиты можно использовать Flashbots MEV-Boost.
Как защититься от MEV при ликвидациях?
MEV-атаки на ликвидации возникают из-за прозрачности pending транзакций. Frontrunner видит вашу ликвидацию и копирует её с более высоким газом, забирая бонус. Решения: private mempool (Flashbots), использование Dutch auction с непредсказуемым началом, или commit-reveal схемы. Мы предпочитаем голландский аукцион — он делает frontrunning невыгодным, так как цена постоянно меняется.
Как мы проектируем устойчивый liquidation engine?
Мы строим двухуровневую систему ликвидации в одном контракте:
- Standard liquidation — ликвидатор предоставляет актив для погашения долга, получает залог с бонусом. Простой, газэффективный.
- Auction liquidation — активируется при залоге выше порога (например, $500K). Голландский аукцион: начальная цена залога = рыночная цена × (1 - максимальный discount), цена растёт каждые N блоков. Первый ликвидатор, принявший текущую цену, выигрывает.
function getAuctionPrice( uint256 startPrice, uint256 startBlock, uint256 priceIncreasePerBlock ) public view returns (uint256) { uint256 elapsed = block.number - startBlock; return startPrice + (elapsed * priceIncreasePerBlock); } Для оракульной интеграции мы используем Chainlink AggregatorV3 с проверкой на stale data. Для активов без Chainlink — Uniswap V3 TWAP с минимальным окном 30 минут. Как указано в документации: Chainlink Data Feeds обновляются каждые 27 секунд при отклонении >0.5%.
| Режим | Триггер | Bonus | Газ | Лучше для |
|---|---|---|---|---|
| Standard | Любой HF<1 | Фикс. 5-10% | Низкий | Средние позиции |
| Auction | Залог > $500K | Динамический | Выше | Крупные позиции |
Если протокол накапливает bad debt, нужен механизм покрытия: Insurance module (стейкеры несут первый убыток), Reserve factor (часть процентов идёт в резерв) или socialisation (bad debt размазывается по LP). Мы выбираем вариант под вашу токеномику.
Почему важно калибровать liquidation threshold?
Неправильный LT ведёт к двум проблемам: слишком низкий — позиции быстро становятся опасными, вызывая ненужные ликвидации; слишком высокий — при резком падении цены протокол оказывается с undercollateralized позициями. Мы калибруем LT на основе исторической волатильности с запасом в 1.5x стандартного отклонения.
Stress-тест: симуляция массовых ликвидаций
Для проверки устойчивости мы используем fork-тест mainnet с Foundry. Сценарий: падение ETH на 40% за 1 час. Проверяем, что все ликвидации проходят за 10 блоков, а bad debt не накапливается. Результаты фиксируем в отчёте для вас.
Что входит в работу
- Аналитика: моделируем stress scenarios с учётом ваших активов и LT.
- Архитектура: проектируем liquidation engine под вашу платформу (двухуровневая система).
- Разработка: пишем контракты на Solidity 0.8.24, тесты на Foundry, fuzzing с Echidna.
- Интеграция: подключаем Chainlink, Uniswap TWAP, flash loan провайдеров (Aave, Uniswap).
- Off-chain bot: пишем ликвидационный бот для первых недель работы (Python/TypeScript).
- Документация: API, развёртывание, настройка параметров.
- Техподдержка: 2 месяца после деплоя.
Процесс работы и сроки
| Этап | Длительность |
|---|---|
| Аналитика | 3-5 дней |
| Разработка | 1-4 недели |
| Тестирование | 5-7 дней |
| Деплой и мониторинг | 3 дня |
Базовый liquidation module для встраивания в lending-протокол — от 1 до 2 недель. Автономный протокол с dutch auction и bad debt socialisation — от 3 до 4 недель. Включая off-chain bot — плюс 1 неделя. Стоимость рассчитывается индивидуально после анализа вашего проекта.
Наш опыт и метрики
- 7+ лет в DeFi
- 30+ аудитов смарт-контрактов
- 20+ lending-протоколов в продакшене (включая Compound, Aave, Morpho)
- Среднее снижение bad debt на 50% после внедрения нашей архитектуры
Свяжитесь с нами для оценки вашего проекта — обсудим детали и предоставим примерный план. Закажите разработку liquidation engine, и мы спроектируем решение под ваши активы. Гарантируем, что протокол пройдёт stress-тесты на исторической волатильности и будет совместим с основными DeFi-инструментами.