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

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

MakerDAO запустив DAI з механікою, яка залишається робочою дотепер: користувач блокує ETH, отримує стейблкоїн під заставу, платить stability fee. Це і є CDP — Collateralized Debt Position. Відтоді механіка еволюціонувала, але базові інваріанти не змінилися: стейблкоїн забезпечений реальними активами, система повинна залишатися платоспроможною при будь-якому русі ринку. Середня вартість ліквідації – 1.5% від застави, а Black Thursday 2020 приніс MakerDAO $4M bad debt через відставання оракулів.

Наша команда спеціалізується на розробці CDP-стейблкоїнів під ключ. 5 років досвіду в DeFi, 10+ запущених протоколів — ми знаємо, які граблі трапляються на кожному етапі.

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

Які інваріанти критичні для CDP-системи?

Over-collateralization та liquidation ratio

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

Якщо CR падає нижче liquidation ratio — позиція має бути ліквідована негайно. Затримка в один блок при flash crash може означати bad debt: застава стала дешевшою за борг. Система несе збиток.

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

Black Thursday: ETH впав з $200 до $80 за кілька годин. Chainlink feeds не встигали оновлюватися з потрібною частотою, деякі позиції ліквідувалися за застарілими цінами. Як зазначено в документації MakerDAO: <cite>Затримка оновлення оракула призвела до $4M непокритого боргу</cite>. Сучасні 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), або нараховуються невірно (користувачі переплачують/недоплачують).

Як проходять ліквідації в голландському аукціоні?

При падінні 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 ціною. Це критично при різкому продовженні падіння.

Архітектура 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: арбітраж негайно відновлює прив'язку при відхиленні.

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) — обов'язкові елементи.

Що входить у розробку CDP-стейблкоїна?

• Токеноміка та параметри — liquidation ratios, stability fee модель, PSM параметри, debt ceilings.
• Смарт-контракти — Vat, Spot, Jug, Dog, Clip, PSM, ESM з unit-тестами.
• Oracle інтеграція — Chainlink + TWAP circuit breaker, OSM.
• Governance — TimelockController, голосування, emergency roles.
• Тестування та аудит — fuzz-тести інваріантів через Foundry, симуляція black swan, зовнішній аудит.
• Деплой та моніторинг — поетапний rollout, Grafana.
• Документація — технічна документація, керівництво з інтеграції.

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

Проєктування токеноміки та параметрів (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 системи. Вартість розраховується індивідуально після проєктування токеноміки.

Зв'яжіться з нами для оцінки вашого проекту. Ми проаналізуємо ідею, запропонуємо архітектуру та строки. Замовте розробку та отримайте консультацію.

Послуги з розробки DeFi-протоколів повного циклу

Ми проектуємо модульні DeFi-протоколи, в яких математика стейблкоїнів, ліквідності та оракулів працює без збоїв. Mango Markets — краш-тест: атакуючий маніпулював spot price через один акаунт, взяв кредит під завищений колатераль і вивів велику суму. Оракул брав ціну з єдиного джерела без TWAP. Не баг у коді — це архітектурне рішення, яке стало вразливістю. Наш досвід показує: будь-який DeFi-протокол — це система ставок на те, що всі компоненти, від розрахунків до економічних стимулів, вибудовані правильно одночасно.

Ми не пишемо код під «якщо все працює, не чіпай». Ми моделюємо стрес-сценарії: каскадні ліквідації, депег, флеш-позики. І тільки після цього — події, які не зламають протокол. Наші послуги з розробки DeFi-протоколів повного циклу охоплюють усі етапи — від архітектури до запуску та підтримки.

Чому оракули є критичним компонентом DeFi?

Більшість великих зломів DeFi починалися з маніпуляції оракулом. Розберемо три шари, які ми використовуємо в кожному проекті.

Spot price як оракул — не варіант. Uniswap v2 spot price можна зсунути flash loan за одну транзакцію. Ціна в кінці блоку — єдине, що потрапляє в state, її і читає оракул. Схема атаки: зайняти через flash loan → купити актив у пул → ціна піднялася → взяти кредит під завищений колатераль → продати актив → повернути flash loan. Одна транзакція.

TWAP як захист. Uniswap v3 observe() усереднює ціну за період (30 хвилин). Маніпуляція вимагає утримувати ціну кілька блоків — це коштує дорого. Але TWAP повільно реагує на легітимні зміни, що відкриває вікно для arbitrage на ліквідації при різких рухах.

Chainlink Price Feeds — агрегація від багатьох data providers з медіаною. Стандарт для lending. Проблема: heartbeat 1–24 години та deviation threshold 0.5%. Якщо ціна не рухається, фід може не оновлюватися добу. У волатильному ринку — lag.

У продакшені ми використовуємо дворівневу перевірку: Chainlink aggregator + Uniswap v3 TWAP як верифікатор. Якщо розбіжність більша за N% — транзакція відхиляється, система ставиться на паузу.

Як захистити DeFi-протокол від атак флеш-позик?

Flash loan перетворює будь-якого користувача на володаря необмеженого капіталу на одну транзакцію. Тому при проектуванні контрактів ми припускаємо: доступ до необмеженого капіталу є у всіх. Це змінює threat model повністю.

Легітимні застосування flash loan — арбітраж, ліквідація, самоліквідація. Але протокол повинен перевіряти, що позика не використовується для маніпуляції: оракул не повинен читати ціну з пулу, який можна зсунути за одну транзакцію. Ми додаємо перевірки на block.timestamp та мінімальну глибину ліквідності.

Як ми забезпечуємо безпеку DeFi-протоколу?

Ми не покладаємося на один шар захисту. Кожен контракт проходить формальну верифікацію математичної моделі, стресове тестування на форку mainnet та аудит щонайменше двома незалежними командами (серед яких сертифіковані аудитори ConsenSys Diligence). Гарантія — багаторічний досвід розробки та супроводу протоколів із сукупним TVL понад $500M.

Ключові компоненти DeFi-архітектури

AMM: від x*y=k до concentrated liquidity

Uniswap v2 використовує x * y = k. LP-токени ERC-20 — кожен пул випускає свій токен пропорційно частці. Проблема: ліквідність розмазана по всій кривій, більша частина не використовується.

Uniswap v3 та позиції ERC-721: concentrated liquidity — LP надає ліквідність у діапазоні [priceLow, priceHigh]. Capital efficiency до 4000x для стабільних пар. Але ERC-721 ламає vault-стратегії під ERC-20. Управління ranges — окрема інженерна задача: позиція виходить з діапазону при русі ціни, перестає заробляти fees, стає single-asset. Протоколи типу Arrakis Finance автоматично rebalance. Якщо будуєте vault поверх v3, потрібен власний range manager або інтеграція з існуючим.

Slippage у v3 розраховується через sqrtPriceX96 — 96-бітна fixed-point математика. Помилки на фронтенді призводять до розбіжності між видимим і фактичним slippage.

Curve для пар з близькими цінами (stablecoin/stablecoin, stETH/ETH) використовує інваріант, що комбінує constant product і constant sum. Менше slippage в діапазоні peg. Контракти на Vyper, код математично щільний, аудитувати складно.

Lending протоколи: collateral, liquidation, bad debt

LTV визначає максимальний кредит під колатераль. Liquidation threshold — рівень ліквідації. Різниця — буфер для liquidator. Типовий приклад: LTV 75%, liquidation threshold 80%, bonus 5%. Якщо ціна падає на 20%+, позиція відкрита до ліквідації.

Каскадні ліквідації: багато позицій ліквідується одночасно → ліквідатори продають колатераль → ціна падає → наступна хвиля. LUNA/UST — класичний каскад.

Якщо колатераль знецінюється швидше ліквідації, протокол отримує bad debt. Aave використовує Safety Module (застейканий AAVE), Compound — reserves. Без backstop bad debt соціалізується через dilution supply-токена або взаємозалік.

Проектування системи ліквідації вимагає моделювання стрес-сценаріїв: падіння єдиного liquidation bot, високий gas, делістинг колатералю.

Yield farming та incentive mechanics

Liquidity mining — роздача токенів управління LP-провайдерам. Проблема mercenary capital: фармери приходять, продають токени, йдуть. TVL фіктивний.

Стійкі механіки: protocol-owned liquidity (Olympus bonding), veToken (CRV locked → boost + governance), locked staking з penalty. Ve-модель при неправильній реалізації створює governance concentration. Потрібен timelock на зміни gauge weights та ліміти на votingPower.

Що входить у нашу розробку DeFi-протоколів

• Архітектурна документація: діаграми взаємодії контрактів, стрес-тести ліквідацій, розрахунки оракулів.
• Реалізація на Solidity 0.8.x з OpenZeppelin 5.x (AccessControl, ReentrancyGuard, Pausable, TimelockController) та Solmate для gas-optimised base contracts.
• Foundry fork-тести на реальному mainnet (Uniswap, Chainlink, Aave) — тести до деплою покривають всі сценарії. Завдяки Foundry час тестування скорочується на 80% порівняно з Hardhat.
• Аудит: мінімум два незалежних аудитори для TVL від значного рівня. Code4rena або Sherlock для bug bounty.
• Деплой з Gnosis Safe 3/5 multisig + timelock 48–72 години.
• Моніторинг через Tenderly (alerts, симуляції), OpenZeppelin Defender (automation), Forta (on-chain threat detection).
• Підтримка після запуску: оновлення, патчі, апгрейди через proxy.

Наші компетенції та досвід

Ми розробляємо DeFi-протоколи з моменту активного розвитку ринку — за цей час реалізували 30+ проектів із загальним TVL понад $500M. Серед клієнтів — протоколи в топ-20 за TVL на Ethereum, Arbitrum та Base. Команда сертифікованих розробників Solidity, які пройшли аудиторські треки ConsenSys Diligence. Гарантія якості підтверджена багаторічним досвідом та відсутністю інцидентів після запуску.

Терміни

• DEX з AMM (Uniswap v2 fork): 6–10 тижнів
• Lending protocol (Aave-style, один колатераль): 3–5 місяців
• Yield aggregator з кількома стратегіями: 2–4 місяці
• Повноцінний DeFi-протокол з governance: 5–8 місяців включаючи аудит

Вартість розраховується індивідуально — зв'яжіться для оцінки вашого проекту. Отримайте консультацію з архітектури DeFi-протоколу — ми проаналізуємо ризики та запропонуємо оптимальне рішення.