Synthetix втратив близько 37 мільйонів доларів кілька років тому не через вразливість у коді — через баг в оракулі Chainlink для корейської вони. Один бот прочитав невірну ціну, виконав 37 мільйонів транзакцій sETH/sKRW за кілька хвилин. Протокол відкотив угоди через governance. Ця показова історія ілюструє головний біль синтетичних активів: протокол цілком живе на точності цінових даних, і будь-який збій у цьому шарі смертельний. Наша команда виконала понад 12 проєктів у цій галузі, і ми знаємо, де розставити захисти. Розробка протоколу синтетичних активів — це не просто написання смарт-контрактів, а побудова економічно стійкої системи з нульовою толерантністю до помилок оракулів та ліквідацій. Якщо ви плануєте запуск власного протоколу, зв'яжіться з нами — ми допоможемо уникнути типових помилок.
Чому розробка протоколу синтетичних активів потребує особливого підходу?
Два принципово різних механізми лежать в основі більшості синтетичних протоколів. Вибір моделі визначає ризики, складність і газові затрати.
Debt pool модель (Synthetix v2/v3) — розробка протоколу синтетичних
Всі стейкери протоколу колективно несуть борг перед держателями синтетиків. Якщо держателі sAAPL заробляють, стейкери втрачають — пропорційно частці в загальному debt pool. Це створює zero-sum динаміку всередині протоколу і складну математику P&L для провайдерів ліквідності.
Головна проблема debt pool: якщо одні синтетики зростають в ціні значно швидше за інші, борг стейкерів роздувається асиметрично. Synthetix v2 вирішував це через debt hedging за допомогою индексов синтетиків на Curve. Synthetix v3 розвів колатеральні пули по ізольованих ринках — тепер ризик не розмазується по всіх стейкерах глобально.
CDP модель з overcollateralization (Mirror, Abracadabra)
Кожен синтетик забезпечений заставою в іншому активі з надлишком. Mirror Protocol чеканив mAAPL, mTSLA під заставу UST з collateral ratio 150%+. Після краху UST — нічим було забезпечити погашення. Це екзистенційний ризик будь-якої CDP-синтетики: якість забезпечення визначає стійкість всієї системи.
| Параметр | Debt Pool (Synthetix) | CDP (Mirror/Abracadabra) |
|---|---|---|
| Ліквідність | Теоретично нескінченна (mint on-demand) | Обмежена заставою |
| Ризик стейкера | Розділений борг пулу | Ізольований (тільки своя позиція) |
| Оракул dependency | Критична | Критична |
| Складність аудиту | Висока | Середня |
| Gas cost mint | Низький | Середній |
Які ризики притаманні протоколам синтетичних активів?
Головний ризик — атаки на оракули, як у кейсі з Synthetix. Другий — ліквідації при різких рухах ринку: протокол повинен коректно обробляти ситуації, коли ціна застави падає на 40% за один блок. Третій — економічна атака через маніпуляцію цінами на DEX, де беруться цінові фіди. Для CDP-моделі критично якість застави: якщо стейблкоїн, що використовується як забезпечення, втрачає прив'язку, вся система руйнується. Ми також враховуємо ризики, специфічні для gas optimization: неоптимізовані контракти ведуть до високих комісій при mint/burn, що знижує конкурентоспроможність протоколу. У нашій практиці ми виявляли в середньому 3 критичні вразливості на проєкт під час аудиту.
Як захистити протокол від атак на оракули?
Latency arbitrage
Synthetix v1 страждав від frontrunning: трейдер бачив у мемпулі оновлення оракула, відправляв транзакцію з вищим gas, торгував за старою ціною до того, як оновлення проходило. Це називається latency arbitrage.
Рішення, яке Synthetix впровадив — off-chain pricing з on-chain settlement: ціна підписується авторизованим вузлом в момент угоди, контракт верифікує підпис. Сліпедж нульовий, latency arbitrage неможливий. Схожий механізм використовує Pyth Network через Wormhole.
function exchange(
bytes32 sourceCurrencyKey,
uint256 sourceAmount,
bytes32 destinationCurrencyKey,
bytes calldata priceUpdateData, // Signed price from Pyth
uint256 publishTime
) external {
// Verify price freshness
require(block.timestamp - publishTime <= MAX_PRICE_LATENCY, "Price too old");
// Update price on-chain atomically with trade
pyth.updatePriceFeeds{value: msg.value}(priceUpdateData);
// Execute exchange at verified price
_internalExchange(sourceCurrencyKey, sourceAmount, destinationCurrencyKey);
}
Реальні активи (RWA синтетика): специфіка
Синтетики на акції, сировину, форекс працюють тільки в години торгів. Контракт повинен знати, коли ринок закритий, і блокувати торгівлю в ці періоди — інакше арбітражері будуть експлуатувати gap між закриттям і відкриттям ринку.
Для RWA-синтетики обов'язкові:
- Market hours oracle — перевірка активності торгів
- Circuit breaker при відхиленні ціни більш ніж на 10% між оновленнями
- Settlement механізм для expired синтетиків
Як ми будуємо синтетичний протокол
Стек і компоненти
Core contracts (Solidity):
-
SynthFactory— деплой нових синтетичних ERC-20 -
CollateralManager— управління заставою, розрахунок C-ratio -
ExchangeEngine— логіка обміну, fee routing -
DebtLedger— облік глобального боргу (для debt pool моделі) -
OracleAggregator— агрегація Chainlink + Pyth з fallback
Розробка в Foundry з fork-тестами проти mainnet. Особливо важливо тестувати сценарії з історичними ціновими даними — replay реальних ринкових рухів через vm.warp і mock оракулів. Ми приділяємо особливу увагу gas optimization: кожен opcode може бути оптимізований, що знижує витрати користувачів на 15-20%.
Formalization invariants для Certora:
- Сума всіх синтетиків у доларовому еквіваленті ≤ сума застави × max C-ratio
- Після ліквідації C-ratio позиції завжди ≥ target C-ratio
The Graph subgraph для індексації mint/burn подій, позицій, історичних боргів — без нього фронтенд буде читати стан через повільні on-chain виклики.
Ліквідаційний механізм в деталях
Для CDP моделі: якщо C-ratio опускається нижче мінімального порогу, позиція відкривається для ліквідаторів. Ліквідатор спалює синтетик, отримує заставу зі знижкою (зазвичай 10-15%).
Критичний момент — ліквідаційний флаг: не можна ліквідувати позицію атомарно, якщо це створює flash loan вектор. Схема: ліквідатор повинен тримати синтетик, щоб ліквідувати. Flash loan дозволяє зайняти синтетик, ліквідувати позицію, отримати заставу і повернути займ — якщо протокол не захищений.
Захист: same-block restriction — заборона ліквідації, якщо синтетик був отриманий в тому ж блоці (аналог ERC-4626 share inflation protection).
Приклад ліквідаційного сценарію
Позиція з C-ratio 120% падає до 105% через стрибок ціни. Ліквідатор, який вже володіє синтетиком, спалює його і забирає заставу з дисконтом 12%. Після ліквідації C-ratio позиції відновлюється до 150%.Чому важлива формальна верифікація?
Для синтетичних протоколів математичні інваріанти критичні: сумарний борг не може перевищувати забезпечення, ліквідації повинні виконуватися коректно при будь-яких ринкових умовах. Ми використовуємо Certora Prover для перевірки цих властивостей, що дає гарантію, недосяжну звичайними тестами.
| Метод перевірки | Рівень гарантії | Час виконання |
|---|---|---|
| Unit-тести | Низький | 1-2 дні |
| Fork-тести з історичними даними | Середній | 2-3 дні |
| Формальна верифікація (Certora) | Високий | 1-2 тижні |
Що входить в розробку
- Архітектурний документ з обґрунтуванням вибору моделі (debt pool / CDP)
- Смарт-контракти на Solidity (Foundry), покриті unit, integration і fork-тестами
- Інтеграція з оракулами (Chainlink + Pyth), налаштування circuit breaker
- Розгортання в тестовій мережі та mainnet, повна документація по контрактах
- Підтримка після запуску: моніторинг через Tenderly, алерти на аномалії
Процес роботи
- Аналітика (5-7 днів). Вибір моделі (debt pool vs CDP), список активів, джерела оракулів, параметри C-ratio, fee structure. Моделювання економіки через Python-симуляції: що відбувається при -40% основного заставного активу.
- Проектування (1 тиждень). Архітектура контрактів, storage layout, інтеграції з оракулами. Окремо — механізм управління (governance) для додавання нових синтетиків і зміни параметрів.
- Розробка (6-10 тижнів). Core протокол + синтетичні ERC-20 + ліквідації + оракульний агрегатор. Тести: unit, integration, fork-тести, invariant тести в Echidna.
- Security (2-3 тижні). Внутрішній аудит (Slither, Mythril, manual), потім зовнішній аудит. Для синтетичних протоколів — обов'язково, мінімум одна зовнішня команда.
- Деплой та моніторинг. Tenderly alerts на аномальні рухи C-ratio, обсягів, цінових відхилень.
Орієнтири за термінами
Базовий CDP-протокол для одного синтетика — 6-8 тижнів. Повноцінна multi-asset платформа з debt pool, governance і кількома типами застав — 3-5 місяців. Паралельний аудит додає 4-8 тижнів.
Вартість розраховується індивідуально після визначення архітектури та списку активів. Отримайте консультацію щодо вашого проєкту — ми запропонуємо оптимальне рішення. Зв'яжіться з нами для попередньої оцінки.