Разработка MakerDAO-стиль протокола стейблкоина
Во время кризиса DeFi ETH обвалился на 50% за несколько часов. Оракулы обновляли цену с опозданием из-за перегрузки сети. Ликвидационные боты не успевали из-за высокого газа. Часть Vault-позиций ушла в ликвидацию с нулевой ценой — ликвидаторы забрали ETH залог фактически бесплатно. Протокол получил дефицит, который закрыли через размывание токена управления. Это не баг в коде — это системный сбой механик, связанный с неоптимальными параметрами ликвидационного аукциона и отсутствием защиты оракулов. Такие инциденты происходят, когда протокол не учитывает экстремальные сценарии волатильности и газовых войн.
Наша команда подходит к созданию CDP-протокола с анализа этих ошибок. Разработка начинается с понимания механик, а не с написания контрактов. Мы детально прорабатываем каждый компонент, чтобы минимизировать риски повторения Black Thursday.
Согласно документации MakerDAO, 'the liquidation process is designed to ensure the system remains fully collateralized at all times.'
Почему Black Thursday может повториться в новом протоколе?
Любой MakerDAO-подобный протокол строится вокруг трёх инвариантов, нарушение каждого ведёт к системной несостоятельности:
- Overcollateralization: суммарная стоимость залогов больше суммарного долга в стейблкоине
- Price feed integrity: ценовые данные должны быть актуальными и манипуляционно-устойчивыми
- Liquidation solvency: при ликвидации протокол всегда получает больше, чем теряет
Эти инварианты транслируются в параметры: liquidation ratio (130-175%), stability fee (годовая ставка на долг), liquidation penalty (10-15%), debt ceiling (максимальный долг по типу залога).
Модульная архитектура MakerDAO vs монолит
MakerDAO использует модульную архитектуру: отдельные контракты Vat (core accounting), Cat (liquidation), Dog (v2), Jug (stability fee), Spot (price feed), Flip/Clip (auction). Это позволяет заменять модули без полного апгрейда, но создаёт сложность при разработке и аудите.
Для нового протокола с нуля мы рекомендуем 3-4 контракта вместо 12+. Core-контракт с логикой CDP, отдельный оракульный модуль, отдельный аукционный. UUPS-апгрейдаемость через OpenZeppelin — позволяет исправлять ошибки без потери state.
Сравнение подходов
| Критерий | Модульная (MakerDAO) | Наш подход |
|---|---|---|
| Количество контрактов | 12+ | 3-4 |
| Сложность аудита | Высокая | Средняя |
| Возможность апгрейда | Модульная замена | UUPS |
| Риск ошибок интеграции | Выше | Ниже |
Критические компоненты: разбираем детально
Как защитить оракулы от манипуляций?
Это самое слабое место большинства CDP-протоколов. Несколько векторов атаки:
Spot price manipulation через flash loan. Если протокол использует spot price из Uniswap пула без TWAP — атакующий делает крупный своп, резко меняет цену залога, открывает или ликвидирует позиции на выгодных условиях, возвращает своп в одной транзакции. Решение: TWAP с периодом минимум 30 минут для активации ликвидации.
Chainlink price feed staleness. Chainlink обновляет цену при отклонении >0.5% или через heartbeat (1-24 часа в сети). В периоды экстремальной волатильности heartbeat может не успевать. Обязательная проверка: require(block.timestamp - updatedAt < maxStaleness). Значение maxStaleness — 1-3 часа для мажорных активов, 30 минут для волатильных.
Circuit breaker. При аномальном изменении цены (>20% за один апдейт) ценовой модуль фризит ликвидации на N минут. Это воспроизводит механику MakerDAO OSM (Oracle Security Module): цена применяется с часовой задержкой, что даёт время на реакцию при атаке на оракул.
Наш стандартный оракульный модуль комбинирует Chainlink primary feed + Uniswap v3 TWAP как secondary, с fallback логикой и circuit breaker. Если расхождение между источниками >5% — ликвидации блокируются.
Аукционный механизм ликвидаций
MakerDAO прошёл путь от English auction (Flip) к Dutch auction (Clip, DAI 2.0). Dutch auction лучше подходит для DeFi:
- Цена начинается высокой (выше рыночной залога) и убывает по формуле до минимума
- Любой участник может забрать часть или весь лот в любой момент аукциона
- Если цена упала ниже минимума — кредитор протокола (surplus buffer) покрывает разницу
- Flash loan friendly: можно купить залог, немедленно продать на DEX и вернуть стейблкоин в одной транзакции
Параметры Dutch auction:
-
buf— начальный множитель цены (обычно 1.2x от oracle price) -
tail— максимальное время аукциона (например, 3600 секунд) -
cusp— минимальный процент от начальной цены (например, 0.4 = 40%) -
chip/tip— вознаграждение тому, кто запустил аукцион (стимул для ботов)
Без tip ликвидационные боты не заинтересованы запускать аукционы на маленькие позиции — gas cost превышает потенциальную прибыль. Black Thursday в том числе поэтому: не было стимула кикать аукционы при высоком газе.
Stability fee и механизм погашения долга
Stability fee начисляется непрерывно через глобальный аккумулятор rate (аналог MakerDAO chi). Каждую секунду все открытые позиции дорожают на (1 + annualRate)^(1/31536000) - 1. Обновление аккумулятора ленивое: пересчёт при каждом обращении к позиции.
Накопленные fees поступают в surplus buffer. Когда surplus превышает заданный порог — излишек идёт на buyback и burn governance-токена. Дефицит surplus (как при Black Thursday) покрывается через debt auction: протокол минтит governance-токены и продаёт за стейблкоин.
Это полная система: CDP → stability fee → surplus buffer → buyback OR debt auction при дефиците. Разработка и тестирование всей цепочки — ключевая часть работы.
Параметры ликвидаций (пример)
| Параметр | Стандартное значение | Примечание |
|---|---|---|
| Liquidation ratio | 150% | для ETH, может быть выше для волатильных активов |
| Liquidation penalty | 13% | добавка к долгу при ликвидации |
| Auction tail | 3600 сек | максимум длительности Dutch auction |
| Tip (стимул) | 0.5% от лота | поощрение для инициатора аукциона |
Governance и параметры
CDP-протокол без governance либо централизован (owner меняет параметры), либо статичен (параметры hardcoded). Для серьёзного протокола нужен on-chain governance с timelock:
- Proposals с минимальным quorum (например, 4% от circulating supply)
- Timelock 48-72 часа перед исполнением любого изменения параметров
- Emergency multisig для критических ситуаций (5/9 multisig, bypass timelock только для заморозки)
OpenZeppelin Governor + TimelockController — стандартная база. Кастомизируем под конкретную токеномику. Закажите прототип для оценки — свяжитесь с нами.
Что входит в работу
- Спецификация параметров: типы залогов, fee structure, аукционный механизм, governance
- Смарт-контракты: Solidity 0.8.x, Foundry, fuzz-тесты инвариантов
- Аудит: два независимых аудита для TVL >$10M, отчёт+гарантия
- Тестовая сеть: развёртывание на Goerli/Sepolia, интеграционные тесты
- Мониторинг: dashboard для отслеживания ликвидаций, oracle health
- Документация: техническая спецификация и руководство по управлению
- Поддержка: 3 месяца после запуска (slack, фикс багов)
Стоимость разработки рассчитывается индивидуально в зависимости от сложности. Экономия на комиссиях за счёт оптимизации газа может составлять до 30% от первоначальных затрат. Получите консультацию по вашему проекту — свяжитесь с нами.
Процесс разработки
Этапы подробно
- Аналитика (1-2 недели): параметры залогов, fee structure, аукционный механизм, governance. Всё это должно быть зафиксировано до написания кода. Изменение auction mechanism после аудита — это новый аудит.
- Проектирование (1-2 недели): архитектура контрактов, выбор апгрейдабельности, интерфейсы.
- Реализация (3-8 недель): контракты на Solidity, тесты в Foundry. Обязательно: fuzz тесты на инварианты (overcollateralization, auction solvency), fork тесты с реальными Chainlink feed данными, симуляция Black Thursday через Foundry's
vm.warp+ резкое изменение oracle цены. - Аудит (4-8 недель): для протокола с потенциальным TVL >$1M — один аудит обязателен. Для TVL >$10M — два независимых аудита. Типичные находки в CDP-протоколах: неправильная обработка fee-on-transfer токенов как залога, reentrancy в auction callback, некорректный расчёт при частичном погашении долга.
- Тестирование (2-3 недели): bug bounty в тестнете, симуляция стресса.
- Деплой (1 неделя): основной запуск, постепенное повышение debt ceiling.
Ориентиры по срокам
MVP с одним типом залога и базовыми аукционами — от 4 недель разработки. Полноценный протокол с несколькими залогами, Dutch auction, governance и мониторинговой инфраструктурой — 2-3 месяца. Аудит не включён в эти сроки — его нужно планировать отдельно.
Стоимость рассчитывается индивидуально в зависимости от набора залогов, сложности governance и требований к UI. Получите консультацию — мы бесплатно оценим ваш проект и предложим сроки.