Разработка протокола страхования DeFi-позиций
В марте 2023 года Euler Finance потерял $197M в результате атаки на логику liquidation. Пользователи, чьи позиции были застрахованы через Nexus Mutual, получили выплаты — остальные нет. Это наглядный пример того, зачем нужно on-chain страхование: не как маркетинговый инструмент, а как реальный финансовый примитив. Построить такой протокол сложно — нужно решить проблему oracle для определения страхового случая, сформулировать параметрические условия без субъективных судей, и сбалансировать премии так, чтобы протокол оставался платёжеспособным.
Три класса рисков и как их покрывать
Риск ликвидации: параметрическое страхование
Ликвидация — самый формализуемый страховой случай. Lending-протоколы (Aave, Compound) эмитируют события LiquidationCall с чёткими параметрами: кто был ликвидирован, сколько collateral изъято, какой debt погашен. Страховой контракт может слушать эти события через лог-фильтрацию или верифицировать их через proof в рамках одной транзакции.
Сложность в другом: когда выплачивать? Если сразу после события — атакующий может создать искусственную ликвидацию собственной позиции (самоликвидация) и получить страховую выплату. Защита:
- Минимальный период между открытием позиции и выплатой (cooling period, например 7 дней)
- Проверка, что health factor падал постепенно, а не резко (защита от flash loan-манипуляции оракулом)
- Лимит выплаты как процент от ущерба, а не полное покрытие (co-insurance)
Риск взлома протокола: coverage pools
Страхование от смарт-контракт эксплойтов — сложнее. Страховой случай субъективен: «был ли это взлом или задокументированное поведение?» Nexus Mutual решает это через governance-голосование клейм-ассесоров. Более децентрализованный подход — UMA Optimistic Oracle: заявитель подаёт claim с bond, оспариватель может оспорить в течение окна, при отсутствии оспаривания выплата проходит автоматически.
Для coverage pools нужен отдельный пул ликвидности, который берёт на себя риск. LP получают yield от страховых премий, но несут риск выплат. Это тот же механизм, что в Nexus Mutual (NXM стейкинг) и InsurAce.
Ключевая уязвимость coverage pool — bank run: при крупном взломе все LP пытаются вывести ликвидность одновременно. Защита: lockup period для LP (минимум 7-14 дней с момента начала вывода) и gradual release через очередь выводов.
Риск сбоя оракула: circuit breaker страхование
Отдельный класс — страхование от манипуляции или сбоя Chainlink-фида. В ноябре 2022 года некорректный фид LUNA вызвал каскад ликвидаций на Venus Protocol. Параметрический страховой случай здесь: «отклонение цены оракула от медианы нескольких источников превысило X% за Y блоков».
Для верификации этого события on-chain нужен агрегатор нескольких оракулов прямо в страховом контракте — Chainlink + Uniswap V3 TWAP + Pyth Network. Если их медианы расходятся более чем на порог — страховой случай наступает автоматически без голосования.
Архитектура протокола
Модульная структура
InsuranceCore.sol — главный роутер
├── PolicyManager.sol — создание и хранение полисов
├── PremiumCalculator.sol — динамический расчёт премий
├── ClaimsProcessor.sol — верификация и выплаты
├── CapitalPool.sol — пул капитала LP
└── RiskOracle.sol — агрегатор условий страхового случая
Каждый модуль обновляемый через UUPS, но с timelock на governance-изменения минимум 48 часов. Для ClaimsProcessor — отдельный timelock 7 дней: выплаты не должны проходить мгновенно без возможности оспаривания.
Расчёт премий: actuarial model on-chain
Статичные премии — это неправильно. Протокол должен динамически корректировать премии на основе:
- Текущей утилизации капитального пула (больше активных полисов → выше премии)
- Исторической волатильности застрахованного протокола (через on-chain данные)
- Coverage ratio (отношение капитала пула к максимальным выплатам)
Простейшая формула: premium = basePremium * utilizationMultiplier * riskMultiplier. Все три параметра обновляются governance с timelock.
Верификация через Merkle proof
Для страхования позиций на Aave пользователь может представить Merkle proof своей позиции из snapshot состояния протокола на момент страхового случая. Это позволяет не хранить все позиции on-chain, а верифицировать принадлежность конкретной позиции к множеству пострадавших.
Генерация Merkle tree происходит off-chain через The Graph subgraph, proof публикуется в IPFS, ClaimsProcessor верифицирует через MerkleProof.verify() из OpenZeppelin.
Критические уязвимости, которые нужно закрыть
| Вектор атаки | Описание | Защита |
|---|---|---|
| Самоликвидация | LP страхует себя, провоцирует ликвидацию | Cooling period + проверка health factor истории |
| Flash loan манипуляция оракулом | Искусственный триггер страхового случая | TWAP 30-минут + мультиоракульная медиана |
| Bank run на coverage pool | Массовый вывод LP при крупном событии | Lockup 14 дней + очередь выводов |
| Griefing через UMA dispute | Оспаривание всех клеймов для блокировки выплат | Escalation game с растущим bond |
| Reentrancy в ClaimsProcessor | Многократный вызов выплаты | ReentrancyGuard + pull payment pattern |
Стек разработки
Контракты — Solidity 0.8.24 с optimizer 200. Математика премий — FixedPointMathLib из Solmate (более газоэффективная, чем PRBMath для простых операций). Верификация клеймов — интеграция с UMA Optimistic Oracle v3 или собственный dispute resolution с Kleros арбитражем.
Тестирование — Foundry fork-tests на Aave V3 mainnet: симулируем реальные ликвидации, проверяем корректность триггеров. Echidna property tests: totalPayouts <= totalPremiums + initialCapital должно соблюдаться при любой последовательности операций.
Для фронтенда — wagmi v2 с Viem, отображение открытых позиций через интеграцию с Aave subgraph в The Graph.
Процесс разработки
Аналитика (1 неделя). Определяем покрываемые протоколы, классы рисков, параметры страховых случаев. Формализуем все условия выплаты в виде on-chain верифицируемых условий.
Архитектура (3-5 дней). Модульная структура, выбор oracle (UMA / Kleros / параметрический), tokenomics капитального пула.
Разработка (3-5 недель). Поочерёдно: капитальный пул → расчёт премий → полисы → клеймы. Каждый модуль с полным покрытием тестами.
Аудит (2-4 недели). Внутренний Slither + Mythril + Echidna. Обязательный внешний аудит — протоколы с реальным капиталом без аудита не деплоим.
Деплой и мониторинг. Gnosis Safe мультисиг. Monitoring через Tenderly Alerts на критические события.
Ориентиры по срокам
Минимальный протокол с одним классом риска (только ликвидации) — от 4 до 6 недель. Полноценный мультирисковый протокол с governance и динамическими премиями — от 8 до 14 недель. Плюс 2-4 недели на внешний аудит перед mainnet-деплоем.