Разработка стейблкоина с обеспечением
Протокол привлёк $40M TVL за три месяца. На четвёртый месяц ETH упал на 35% за 4 часа — быстрее, чем liquidation bot успел обработать очередь. Несколько позиций с collateral ratio 150% стали undercollateralized раньше, чем их ликвидировали. Протокол напечатал необеспеченные стейблкоины. Именно так работает системный риск в overcollateralized stablecoin — не через взлом контракта, а через архитектурный просчёт в механике ликвидаций.
Архитектура обеспечения: где зарыты настоящие проблемы
Liquidation механика и проблема «oracle lag»
Самое сложное в collateralized stablecoin — не сам mint/burn, а система ликвидаций под нагрузкой. Классическая схема: если collateralRatio < liquidationThreshold, позицию можно ликвидировать. Проблема начинается, когда Chainlink price feed обновляется раз в heartbeat (обычно 1 час или при отклонении >0.5%), а цена актива падает быстрее.
При flash crash ETH -20% за 30 минут несколько вещей происходят одновременно:
- on-chain цена от Chainlink ещё не обновилась (последний update был 25 минут назад)
- реальная цена уже на 18% ниже oracle price
- liquidation bots видят позиции как «здоровые» по on-chain данным
- к моменту обновления оракула очередь ликвидаций становится огромной
- gas войны между ботами → liquidators платят 200-500 gwei → часть позиций просто не успевают
Решение — двухслойная проверка: основной Chainlink feed + Uniswap V3 TWAP как sanity check. Если разрыв между ними превышает 5%, протокол входит в «emergency mode» с ограничениями на новый mint. Это то, что MakerDAO реализовал через OSM (Oracle Security Module) с задержкой 1 час — не идеальное решение, но даёт время на реакцию governance.
Bad debt и механизм покрытия
В Liquity v1 при ликвидации долг покрывается из Stability Pool. Если пул пуст, долг распределяется между всеми vault holders через «redistribution». Это элегантно, но создаёт скрытый риск: в условиях массовых ликвидаций redistribution размывает collateral ratio здоровых позиций, что может запустить каскад.
В нашей реализации мы используем страховой резерв (Insurance Fund), формируемый из части liquidation penalty (обычно 10-13%). При нормальной работе он накапливается. При bad debt события — покрывает первые потери до того, как риск переносится на держателей governance токена.
Проблема прайс-манипуляции через flash loan
Классический вектор: взять flash loan на большую сумму, задепить как collateral, отминтить stablecoin по завышенной цене (если оракул использует spot price из DEX пула), вывести стейблкоин. TWAP (Time-Weighted Average Price) закрывает это — манипуляция spot price влияет на TWAP только при длительном удержании, что делает атаку дорогой.
Для новых токенов с малой ликвидностью TWAP тоже ненадёжен. Поэтому whitelist collateral активов с минимальным порогом ликвидности ($50M+) — не ограничение протокола, а защитный механизм.
Как мы строим overcollateralized stablecoin
Контрактная архитектура
Разделяем систему на независимые модули:
| Модуль | Ответственность | Апгрейдаемость |
|---|---|---|
VaultManager |
Открытие/закрытие позиций, collateral учёт | UUPS |
PriceOracle |
Агрегация Chainlink + TWAP, circuit breaker | Replaceable |
LiquidationEngine |
Очередь ликвидаций, dutch auction | UUPS |
StabilityPool |
Буфер для покрытия ликвидаций | Immutable |
StablecoinToken |
ERC-20 с mint/burn только от VaultManager | Immutable |
StablecoinToken — immutable намеренно. Держатели стейблкоина не должны зависеть от того, что governance проголосует за изменение логики самого токена.
Dutch auction для ликвидаций
Вместо фиксированной liquidation penalty используем Dutch auction: liquidation discount начинается с 0% и увеличивается каждые N блоков, пока кто-то не возьмёт позицию. Это решает сразу две проблемы:
- Конкуренция между liquidation ботами переходит из газ-войн в «кто быстрее примет выгодную цену»
- Протокол не переплачивает ликвидаторам при нормальных условиях
Liquity v2 и Gravita используют схожий подход. Мы добавляем ограничение: если аукцион идёт дольше maxAuctionDuration блоков без покупателя — позиция переходит в redistribution, чтобы избежать зависших плохих долгов.
Параметры системы и governance
Ключевые параметры, которые governance должен контролировать:
-
minimumCollateralRatio— обычно 110-150% в зависимости от волатильности актива -
liquidationPenalty— 5-15%, должна быть достаточной для мотивации ботов -
borrowingFee— одноразовая комиссия при минте, регулирует спрос -
stabilityFee(опционально) — непрерывная ставка, аналог interest rate в MakerDAO
Для новых протоколов рекомендуем начинать с консервативных параметров (MCR 150%, penalty 10%) и снижать по мере накопления on-chain истории.
Тестирование: fork-тесты на сценариях краша
Ни один unit-тест не заменит fork-тест на реальных исторических данных. Мы тестируем протокол на нескольких сценариях:
Black Thursday 2020 (ETH -55% за 24h): проверяем, что очередь ликвидаций обрабатывается корректно при нулевой ликвидности в Stability Pool.
LUNA/UST депег 2022: симулируем быстрое падение collateral актива с одновременным ростом sell pressure на сам stablecoin. Проверяем circuit breaker в оракуле.
Gas spike до 3000 gwei: проверяем, что ликвидации экономически выгодны даже при экстремальном газе. Если нет — размер позиций или penalty нужно пересматривать.
Foundry vm.createFork + vm.rollFork позволяет воспроизвести точное состояние mainnet в любой момент истории. Это стандарт для нашего тестирования CDP-протоколов.
Процесс разработки
Аналитика (3-5 дней). Определяем whitelist активов, параметры системы, механику ликвидаций. Анализируем конкурентов: Liquity, Gravita, Raft, Prisma.
Проектирование (5-7 дней). Storage layout, интерфейсы модулей, схема событий для The Graph индексации.
Разработка (4-8 недель). Контракты + comprehensive тесты: unit, integration, fork-тесты на исторических сценариях, fuzz-тесты через Echidna с property-based проверками инвариантов системы.
Внешний аудит (обязателен). Для CDP-протоколов с TVL потенциалом >$1M — минимум один внешний аудит от специализированной компании (Trail of Bits, Sherlock, Code4rena contest). Бюджет и время закладываем в roadmap заранее.
Деплой. Мультисиг через Gnosis Safe на все административные функции. Timelock на изменение ключевых параметров (минимум 24-48 часов).
Ориентиры по срокам
Минимальная реализация (один тип collateral, базовая ликвидация) — 6-8 недель разработки. Полноценный протокол с несколькими типами collateral, Dutch auction ликвидациями, Stability Pool и governance — 2-4 месяца включая аудит. Сроки существенно зависят от сложности параметризации и требований к тестовому покрытию.
Стоимость рассчитывается индивидуально после анализа требований.