Розробка fractional-reserve стейблкоина
Клієнт хоче стейблкоин, який не потребує 150% overcollateralization, як DAI в режимі CDP, але при цьому тримає пег. Частичне резервування — це не баг дизайну, це компроміс між капіталоефективністю та стійкістю. Проблема в тому, що більшість команд недооцінюють механізм bank run в on-chain контексті: на відміну від традиційних банків, смарт-контракти дозволяють вивести все за одну транзакцію.
Чому fractional-reserve стейблкоини ломаються — та як їх не сломати
Алгоритмічна частина убивает пег швидше, ніж здається
FRAX v1 запустився з CR (Collateral Ratio) 100%, потім алгоритм знижував CR при зростанні спроса. Теорія: якщо ринок довіряє протоколу, частину обеспечення можна замінити governance-токеном FXS. На практиці в березні 2023, після краху SVB, CR упав нижче 90%, та відновлення коштувало кількох тижнів волатильності. Не провал — але наглядний приклад того, що алгоритмічна частина не лінійна під тиском.
Ключовий інваріант, який потрібно захищати: redemption завжди можливий по номіналу. Якщо користувач не може спалити 1 стейблкоин та отримати $1 в collateral (або еквіваленті), механізм арбітража сломан, та пег тримається тільки на психології.
Конструкція контракту: три шари
Шар 1 — Minting/Redemption. Користувач вносить collateral (USDC, ETH через Chainlink price feed) та отримує стейблкоин. При mint з CR=80% — 80 центів у USDC + governance-токени на 20 центів. При redeem — навпаки. Цей шар повинен бути атомарним та не залежати від on-chain ліквідності governance-токена.
Шар 2 — PID-контролер CR. Алгоритм, який піднімає CR при депегу вниз та знижує при стійкому пегу. Критично: не робити це миттєво. Зміна CR на 1% на день — типовий параметр. Різке зміна створює MEV-можливості для арбітражників, які будуть атакувати момент смени.
Шар 3 — AMO (Algorithmic Market Operations). Вільні резерви працюють в Curve/Aave/Convex, генеруючи дохідність. AMO-контракти повинні мати жорсткий лімит на максимальний deploy: якщо AMO може піти в стратегію більше, ніж (1 - CR) від total supply, система стає уязвимою до одночасного вилучення.
Flash loan як вектор атаки на оракул
Типова схема: злоумисник бере flash loan на 50M USDC, продавлює ціну governance-токена вниз на 40% через тонкий пул на Uniswap v2, контракт миттєво пересчитує CR через TWAP-оракул з коротким вікном (5 хвилин) — CR падає, протокол опиняється в технічному undercollateral. При цьому сам злоумисник відкриває redemption та отримує USDC з резерва по невигідному для протоколу курсу.
Захист: TWAP мінімум 30 хвилин для governance-токена як компоненту обеспечення. Для USDC та ETH достатньо Chainlink з deviation threshold 0.5%. Окремі оракули для різних компонентів, не агрегований price feed.
Як ми будуємо такі системи
Розробка починається з економічної моделі, а не з коду. Потрібно визначити:
- Цільовий CR діапазон (наприклад, 80-90%)
- Параметри PID: швидкість зміни CR, триггерні пороги
- Список дозволених collateral активів та їх вагові коефіцієнти
- Механізм incentivize для підтримання пега (stability fees, bond mechanism)
Стек: Solidity 0.8.x, OpenZeppelin для access control та pausability, Chainlink для price feeds, Curve Finance SDK для AMO-інтеграції. Тесты у Foundry з fork mainnet — обов'язково, тому що AMO-логіка залежить від реального стану пулів Curve.
Для governance-токена — стандартний ERC-20 з burn-механікою при mint стейблкоина. Важливо: governance-токен не повинен мати infinite mint — це убивало проекти вроде Iron Finance (IRON/TITAN, червень 2021, $2B → $0 за 24 години).
Тестування сценарію bank run
У Foundry можна симулювати одночасний redeem 80% supply за один блок. Контракт повинен або обробити це коректно (видати USDC з резерву, заморозити governance-token частину), або активувати circuit breaker. Circuit breaker — pausable модуль з timelock, який вводить cooldown на redeem при перевищенні порогового обсягу за блок.
Property-based тест через Echidna: інваріант «total_collateral_value / total_supply >= min_CR» повинен тримати при будь-якому сценарії minting та redemption.
Процес роботи
Економічний дизайн (1-2 тижні). Параметризація моделі, симуляція у Python/Jupyter, stress-тесты bank run сценаріїв. Визначаємо пороги, при яких система стає нестабільною.
Проектування контрактів (1 тиждень). Storage layout, інтерфейси, діаграма взаємодії. Особливу увагу — порядку операцій у mint/redeem (Checks-Effects-Interactions).
Розробка (3-6 тижнів). Core контракти + AMO + оракульна обвязка. Fork-тесты проти mainnet Curve/Aave.
Аудит. Для фінансових протоколів такого рівня — обов'язковий зовнішній аудит. Підготуємо кодову базу: Slither clean, 95%+ test coverage, NatSpec на всі публічні функції.
Деплой. Спочатку testnet (Sepolia) з імітацією market stress через Foundry scripts. Mainnet деплой через Gnosis Safe multisig з timelock мінімум 48 годин на parameter changes.
Часові орієнтири
Мінімальна система без AMO: 6-8 тижнів. З AMO-модулями та повним тестовим покриттям: 2-3 місяці. Часи сильно залежать від кількості collateral типів та складності governance-механіки.