Разработка MakerDAO-стиль протокола стейблкоина
MakerDAO в марте 2020 года, «Black Thursday»: ETH упал на 50% за несколько часов. Оракулы обновили цену с опозданием из-за перегрузки сети. Ликвидационные боты не успевали из-за высокого газа. Часть Vault-позиций ушла в ликвидацию с нулевой ценой — ликвидаторы забрали ETH залог фактически бесплатно. Протокол получил дефицит в $5.4M, который закрыли через MKR dilution auction. Это не баг в коде — это системный сбой механик.
Разработка CDP-протокола начинается с понимания этих механик, а не с написания контрактов.
Архитектура CDP протокола
Ядро: три инварианта системы
Любой 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 liquidation), Jug (stability fee), Spot (price feed), Flip/Clip (auction). Это позволяет заменять модули без полного апгрейда, но создаёт сложность при разработке и аудите.
Для нового протокола с нуля рекомендуем менее агрессивную модульность: 3-4 контракта вместо 12+. Core-контракт с логикой CDP, отдельный оракульный модуль, отдельный аукционный модуль. UUPS-апгрейдаемость через OpenZeppelin — позволяет исправлять ошибки без потери state.
Критические компоненты: разбираем детально
Ценовые оракулы и защита от manipulation
Это самое слабое место большинства CDP-протоколов. Несколько векторов атаки:
Spot price manipulation через flash loan. Если протокол использует spot price из Uniswap пула без TWAP — атакующий делает крупный своп, резко меняет цену залога, открывает или ликвидирует позиции на выгодных условиях, возвращает своп в одной транзакции. Решение: TWAP с периодом минимум 30 минут для активации ликвидации.
Chainlink price feed staleness. Chainlink обновляет цену при отклонении >0.5% или через heartbeat (1-24 часа в зависимости от сети и feed). В периоды экстремальной волатильности 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 при дефиците. Разработка и тестирование всей цепочки — ключевая часть работы.
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 — стандартная база. Кастомизируем под конкретную токеномику.
Процесс разработки
Спецификация (1-2 недели). Параметры залогов, fee structure, аукционный механизм, governance. Всё это должно быть зафиксировано до написания кода. Изменение auction mechanism после аудита — это новый аудит.
Разработка (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, некорректный расчёт при частичном погашении долга.
Bug bounty и постепенный запуск. Debt ceiling на старте — минимальный, растёт по мере проверки протокола в боевых условиях.
Ориентиры по срокам
MVP с одним типом залога и базовыми аукционами — 4-6 недель разработки. Полноценный протокол с несколькими залогами, Dutch auction, governance и мониторинговой инфраструктурой — 2-3 месяца. Аудит не включён в эти сроки — его нужно планировать отдельно.
Стоимость зависит от набора залогов, сложности governance и требований к UI.