Разработка стейблкоина с CDP (Collateralized Debt Position)

Разработка стейблкоина с CDP (Collateralized Debt Position)

MakerDAO запустил DAI в 2017-м с механикой, которая остаётся рабочей до сих пор: пользователь блокирует ETH, получает DAI против залога, платит stability fee. Это и есть CDP — Collateralized Debt Position. С тех пор механика эволюционировала, но базовые инварианты не изменились: стейблкоин обеспечен реальными активами, система должна оставаться платёжеспособной при любом движении рынка.

Разработать собственный CDP-стейблкоин — задача на несколько месяцев даже для опытной команды. Не из-за сложности отдельных компонентов, а из-за системных зависимостей: oracle, liquidation engine, stability fee accumulation, governance — каждый компонент критичен, и провал одного разрушает всю систему.

Три инварианта, нарушение которых убивает систему

Over-collateralization и liquidation ratio

CDP-стейблкоин работает только при условии, что стоимость залога всегда превышает стоимость выпущенного долга с достаточным буфером. Минимальный collateralization ratio (CR) определяется волатильностью актива:

Если CR падает ниже liquidation ratio — позиция должна быть ликвидирована немедленно. Задержка в один блок при flash crash может означать bad debt: залог стал дешевле долга. Система несёт убыток.

Oracle manipulation — главный вектор атак

Black Thursday 2020: ETH упал с $200 до $80 за несколько часов. Chainlink feeds не успевали обновляться с нужной частотой, некоторые позиции ликвидировались по устаревшим ценам. MakerDAO получил $4M bad debt.

Современные CDP-системы используют двухуровневую oracle систему:

Primary oracle: Chainlink — медиан из 31+ нод, обновление каждые 60 секунд или при отклонении >0.5%. Высокая надёжность, но latency при sharp moves.

Circuit breaker oracle: on-chain TWAP из Uniswap v3 (30-минутное окно). Если Chainlink price отклоняется от TWAP более чем на 20% — система переходит в режим Emergency Shutdown или freeze новых CDP.

Oracle Security Module (OSM) из MakerDAO — паттерн, который стоит взять за основу: ценовое обновление применяется с задержкой 1 час. За это время governance может отреагировать на oracle атаку.

Stability fee accumulation и DSR

Stability fee — процент, который начисляется на долг каждую секунду. Корректная реализация через rate accumulator (chi в терминологии Maker): каждый раз при обращении к позиции chi обновляется:

chi_new = chi_old * (1 + stabilityFee)^(block.timestamp - lastUpdate)

Долг пользователя хранится в normalizedDebt (количество единиц до умножения на chi). Реальный долг = normalizedDebt * chi. Это позволяет начислять проценты всем позициям одновременно без итерации по всем CDP — критично при тысячах активных позиций.

Ошибка в accumulator logic — самая дорогостоящая: либо проценты не начисляются (protocol insolvent), либо начисляются неверно (пользователи переплачивают/недоплачивают).

Архитектура CDP-протокола

Модульная структура контрактов

Монолитный контракт для CDP не подходит — слишком сложная логика, слишком высокий риск. Референсная архитектура:

Vat (Core CDP engine) — хранит все позиции, считает залог и долг, знает о collateralization ratio. Никакой бизнес-логики — только чистый учёт.

Spot (Oracle module) — принимает цены от оракулов, пересчитывает в liquidation price для каждого collateral типа. Vat читает из Spot.

Jug (Fee accumulator) — обновляет drip() для каждого collateral type, накапливает stability fee в Vat.

Dog/Cat (Liquidation trigger) — проверяет позиции, начинает аукционы. Dog — аукционный ликвидатор (Maker v2); более простой паттерн — fixed-spread liquidation как в Aave.

Clip (Auction) — голландский аукцион: цена начинается с premium и линейно снижается. Ликвидатор, первым принявший цену — получает залог. Этот механизм лучше fixed-bonus при глубоких рынках.

PSM (Peg Stability Module) — позволяет обменивать USDC 1:1 на stablecoin без комиссии (или с микро-fee). Ключевой механизм удержания peg: арбитраж немедленно восстанавливает привязку при отклонении.

Liquidation в деталях: голландский аукцион

При падении CR ниже liquidation ratio Dog создаёт аукцион в Clip. Параметры:

• buf — начальный premium (например 120% от oracle цены)
• tail — максимальная продолжительность аукциона
• cusp — минимальный допустимый price drop (0.4 = 40% от старта)
• chip — flash loan incentive для ликвидаторов

Ликвидатор вызывает take(id, amt, max): покупает amt залога по цене не хуже max. Оставшийся долг погашается, излишек залога возвращается позицию-владельцу.

Edge case: что если аукцион истёк (tail/cusp достигнут), а залог не куплен? Redo перезапускает аукцион по новой oracle цене. Это критично при резком продолжении падения.

Emergency Shutdown

Любая CDP-система должна иметь механизм корректного завершения. ESM (Emergency Shutdown Module) позволяет держателям governance токенов сжечь определённое количество токенов для активации shutdown. После активации:

1. Новые CDP заблокированы
2. Цены фиксируются по oracle на момент shutdown
3. Пользователи могут выкупить залог по фиксированному rate
4. Все аукционы завершаются

Без ESM система не имеет механизма выхода при системном сбое.

Типичные ошибки при разработке

Flash loan атака через oracle. Если используется on-chain TWAP с коротким окном (1–5 минут) — flash loan может кратковременно сдвинуть цену, открыть CDP по завышенной цене залога, вывести средства, вернуть flash loan. Решение: TWAP с минимальным 30-минутным окном или Chainlink с OSM.

Reentrancy в liquidation callback. Ликвидатор получает callback после получения залога. Если в этот момент система не заблокирована — возможна reentrancy через повторный вызов take. Все ликвидационные функции должны быть защищены mutex на уровне Vat.

Накопленный долг без cap. Без глобального debt ceiling по каждому collateral type один актив может доминировать в обеспечении системы. При падении этого актива — вся система под угрозой. Параметры line (debt ceiling per collateral) и Line (global ceiling) — обязательные элементы.

Процесс разработки

Проектирование токеномики и параметров (1–2 недели): liquidation ratios, stability fee модель, PSM параметры, debt ceilings. Эти решения фундаментальны — менять сложно после запуска.

Разработка core контрактов (4–6 недель): Vat, Spot, Jug, Dog, Clip, PSM, ESM. Каждый контракт — отдельный набор unit-тестов.

Oracle интеграция (1 неделя): Chainlink + TWAP circuit breaker, OSM с задержкой.

Governance (1–2 недели): TimelockController, параметры голосования, emergency roles.

Тестирование и аудит (3–4 недели): fuzz-тесты инвариантов через Foundry, симуляция black swan сценариев, внешний аудит обязателен перед mainnet.

Деплой и мониторинг (1 неделя): поэтапный rollout с низкими debt ceiling на старте, Grafana мониторинг health metrics.

Итого: 2 месяца — 3 месяца для production-ready CDP системы. Стоимость рассчитывается индивидуально после проектирования токеномики.