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 с помощью indeces синтетиков на 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 недель.
Стоимость рассчитывается индивидуально после определения архитектуры и списка активов. Получите консультацию по вашему проекту — мы предложим оптимальное решение. Свяжитесь с нами для предварительной оценки.