Розроблення стейблкоїна з обеспеченням
Протокол привлік $40M TVL за три місяці. На четвертий місяць ETH упав на 35% за 4 години — швидше, ніж liquidation bot встиг обробити чергу. Кілька позицій з collateral ratio 150% стали undercollateralized раніше, ніж їх ліквідували. Протокол напечатав необеспечені стейблкоїни. Саме так працює системний ризик в overcollateralized stablecoin — не через взлом контракту, а через архітектурний просчіт в механіці ліквідацій.
Архітектура обеспечення: де приховані справжні проблеми
Механіка ліквідацій та проблема «oracle lag»
Найскладніше в collateralized stablecoin — не сам mint/burn, а система ліквідацій під навантаженням. Класична схема: якщо collateralRatio < liquidationThreshold, позицію можна ліквідувати. Проблема починається, коли Chainlink price feed оновлюється на heartbeat (зазвичай 1 година або при відхиленні >0.5%), а ціна активу падає швидше.
При flash crash ETH -20% за 30 хвилин кілька речей відбувається одночасно:
- on-chain ціна від Chainlink ще не оновилась (останнє оновлення 25 хвилин тому)
- реальна ціна вже на 18% нижче oracle price
- liquidation боти бачать позиції як «здорові» по 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 события — покриває перші потері перед тим, як ризик переносится на holders токенів governance.
Проблема price-маніпуляції через flash loan
Класичний вектор: взяти flash loan на велику суму, задепити як collateral, отминтити stablecoin за завищеною ціною (якщо оракул використовує spot price з DEX пулу), вивести stablecoin. TWAP (Time-Weighted Average Price) закриває це — маніпуляція spot price впливає на TWAP лише при тривалому утриманні, що робить атаку дорогою.
Для нових токенів з низькою ліквідністю TWAP теж ненадійний. Тому whitelist collateral активів з мінімальним порогом ліквідності ($50M+) — не обмеження протоколу, а захисний механізм.
Як ми будуємо overcollateralized stablecoin
Архітектура контракту
Розділяємо систему на незалежні модулі:
| Модуль | Відповідальність | Upgradeability |
|---|---|---|
VaultManager |
Відкриття/закриття позицій, облік collateral | UUPS |
PriceOracle |
Агрегація Chainlink + TWAP, circuit breaker | Replaceable |
LiquidationEngine |
Черга ліквідацій, dutch auction | UUPS |
StabilityPool |
Буфер для покриття ліквідацій | Immutable |
StablecoinToken |
ERC-20 з mint/burn лише від VaultManager | Immutable |
StablecoinToken — immutable навмисно. Holders стейблкоїну не повинні залежати від того, що governance проголосує за зміну логіки самого токена.
Dutch auction для ліквідацій
Замість фіксованої liquidation penalty використовуємо Dutch auction: liquidation discount починається з 0% та зростає кожні N блоків, поки хтось не возьме позицію. Вирішує дві проблеми:
- Конкуренція між liquidation botами переходить з газ-войн в «хто швидше прийме вигідну ціну»
- Протокол не переплачує ліквідаторам при нормальних умовах
Liquity v2 та Gravita використовують схожий підхід. Ми додаємо обмеження: якщо аукціон іде довше maxAuctionDuration блоків без покупця — позиція переходить в redistribution, щоб уникнути завислих плохих долгів.
Параметри системи та governance
Ключові параметри, які governance повинен контролювати:
-
minimumCollateralRatio— зазвичай 110-150% залежно від волатильності активу -
liquidationPenalty— 5-15%, повинна бути достатньою для мотивації botів -
borrowingFee— одноразова комісія при mint, регулює спрос -
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, інтерфейси модулів, схема eventi для 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 місяці включаючи аудит. Строки істотно залежать від складності параметризації та вимог до тестового покриття.
Вартість розраховується індивідуально після аналізу вимог.