Розробка протоколу стейблкоїна в стилі 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. Отримайте консультацію — ми безкоштовно оцінимо ваш проект і запропонуємо строки.