Розробка алгоритмічного стейблкоина
Terra/LUNA рухнула за 72 години — $40 млрд випарилося, тому що механізм rebasing опирався на єдиний інваріант: спрос на UST буде зростати вічно. Коли спрос розвернувся, алгоритм почав гіперінфлювати LUNA для відновлення пега, що прискорило втечу з UST, яка потребувала ще більше LUNA. Death spiral. Це не баг реалізації — баг токеномічної моделі, яку ніхто не стресував у сценарії «всі виходять одночасно».
Алгоритмічні стейблкоини — найскладніша категорія DeFi-протоколів. Тут економіка та смарт-контракти залежать один від одного настільки щільно, що ошибка в одному рівні миттєво руйнує інший.
Чому більшість алгоритмічних стейблкоинів не доживають до року
Проблема єдиного механізму стабілізації
Протоколи, які вижили — FRAX, DAI з PSM, crvUSD — використовують кілька рівнів захисту пега. Чисто алгоритмічні системи типу Basis Cash, ESD, DSD вмерли, коли ринок не захотів купувати облігації (bonds/coupons) під час contraction фази. Механізм працює тільки якщо в нього вірять. Як тільки віра пропадає — автоматика не встигає.
Ключова відмінність у виживших: коллатеральний backstop. FRAX тримає частину резервів у USDC. crvUSD використовує LLAMMA (Lending-Liquidating AMM Algorithm) — при падінні залогу система не ліквідує одним срізом, а поступово конвертує залог у стейблкоин через спеціальну AMM-криву. Дає буфер часу, зменшує liquidation cascade.
Oracle manipulation як вектор атаки на peg
Алгоритмічний стейблкоин залежить від оракула ціни. Якщо протокол використовує spot price з єдиного пула DEX як сигнал для expansion/contraction — він уразливий для flash loan маніпуляції.
Сценарій: атакуючий бере флеш-займ, створює штучний спрос на стейблкоин (ціна летить вище $1), протокол бачить expansion сигнал та мінтить нові токени, атакуючий продає позицію та погашає займ. Система розширила пропозицію на хибному сигналі, після чого ціна повертається нижче $1 та запускає contraction.
Рішення — TWAP oracle з адекватним вікном (мінімум 30 хвилин для Uniswap V3 TWAP), краще Chainlink як другий источник з circuit breaker: якщо Chainlink та TWAP розходяться більше ніж на X% — expansion/contraction припиняються.
Rebasing проти seigniorage shares проти CDP
Три основні архітектури з принципово різними ризиками:
| Архітектура | Приклади | Механізм | Головний ризик |
|---|---|---|---|
| Rebasing | AMPL, BASE | Зміна балансу всіх гаманців | UX-путаниця, інтеграція з DeFi складна |
| Seigniorage shares | Basis Cash, TITAN | Окремий share-токен поглинає волатильність | Death spiral при потері довіри |
| CDP з алго-елементами | FRAX v2, crvUSD | Частичний колатерал + алгоритм | Залежність від якості колатералю |
| Overcollateralized | DAI | Надмірний залог + PSM | Капіталоємкість, централізація через USDC |
Для нового проекту чистий seigniorage shares без коллатеру — це ризик, важко обґрунтувати після Terra. Гібридні моделі FRAX-style або системи з ліквідуючим AMM (crvUSD-style) дають краще співвідношення капіталоефективності та стійкості.
Як будуємо алгоритмічний стейблкоин
Моделювання токеномики до написання коду
Перші 2-3 тижні — агентне моделювання у Python. Симулюємо кілька класів учасників: holders (пасивні), arbitrageurs (активно підтримують пег), speculators (купують share-токен на expansion), паникёри (виходять при першому депегу). Гоняємо сценарії: bank run 30% TVL за 24 години, oracle failure на 6 годин, flash crash залогу на 40%.
Якщо модель не тримає пег при bank run 30% — змінюємо архітектуру, не реалізацію.
Контракти: що будуємо
Stablecoin ERC-20 з контрольованим mintом/burn. Тільки авторизовані контракти (Policy, PSM, CDP) можуть мінтити. Без owner mint — це вектор rugpull.
Policy контракт — мозок системи. Читає TWAP oracle, рахує deviation від $1, приймає рішення про expansion/contraction. Ставки expansion/contraction — параметри governance, не хардкод.
Bond/coupon механізм для contraction (якщо вибрана seigniorage-архітектура): користувач спалює стейблкоин, отримує bond з премією, який можна погасити при наступному expansion. Реалізуємо через ERC-1155 з різними сроками погашення — це дає вторинний ринок облігацій.
PSM (Peg Stability Module) — прямий своп стейблкоин/USDC за курсом 1:1 з невеликою комісією (0.1%). Це жесткий якір. Так, це частична централізація. Але без PSM утримувати жесткий пег на турбулентному ринку практично неможливо.
LLAMMA-style AMM (якщо будуємо CDP-систему): ліквідації відбуваються не одним срізом, а через спеціальну криву, що починає конвертувати залог у стейблкоин при приближенні до liquidation price. Контракт складніший, але liquidation cascade неможливий за конструкцією.
Тестування: обов'язкові сценарії
Звичайні unit-тесты недостатні. Будуємо fork-тесты на Ethereum mainnet через Foundry vm.createFork та гоняємо:
- Flash loan атака на TWAP oracle: займаємо з Uniswap V3, рухаємо ціну, дивимось реакцію Policy
- Bank run симуляція: 50 послідовних великих redemption в одному блоці
- Oracle failure: Chainlink повертає stale price (перевищено
updatedAtthreshold), система повинна встати на паузу - Governance атака через timelock: перевіряємо, що критичні параметри (max expansion rate) захищені мінімальним delay
Fuzzing через Echidna з інваріантами: totalSupply >= collateralValue ніколи не порушується, pegDeviation не може перевищити X% при нормальних умовах.
Інтеграції та інфраструктура
Chainlink price feeds для залогових активів — обов'язково. The Graph для індексації подій (expansion, contraction, bond issuance) — frontend не може покладатися на eth_getLogs для історії. Gnosis Safe з timelock для governance-операцій.
Для моніторингу депеггінга — Tenderly alerts на события Policy контракту та on-chain ціну в AMM. Якщо ціна виходить за межі band — тригер для команди до того, як це помітять користувачи.
Процес роботи
Токеномічне дослідження (1-2 тижні). Вибір архітектури, агентне моделювання, stress testing моделі. Документ з інваріантами системи — основа для аудиту.
Проектування контрактів (1 тиждень). Діаграми взаємодії, storage layout, інтерфейси. На цьому етапі фіксуємо все governance точки входу та переконуємось, що attack surface мінімальний.
Розробка (4-8 тижнів). Policy, stablecoin, bond mechanism, PSM або LLAMMA залежно від архітектури. Паралельно — тесты, включаючи fuzz та fork-тесты.
Зовнішній аудит. Для будь-якого стейблкоина з реальними грошима — обов'язковий. Мінімум одна фірма рівня Trail of Bits, Spearbit або OtterSec.
Деплой та моніторинг. Спочатку обмежений launch з cap на total supply, поступове зняття обмежень за доказом стабільності.
Сроки: від 2 місяців до півроку залежно від складності архітектури та вимог до аудиту. Вартість розраховується після вибору механіки та обсягу робіт.