Крупный протокол потерял $197M из-за атаки на ликвидацию. Пользователи с полисами от Nexus Mutual получили выплаты — остальные нет. Такой случай показывает: on-chain страхование — не маркетинг, а финансовый примитив. Мы разрабатываем протоколы, которые решают три проблемы: как определить страховой случай без субъективного участия, как динамически считать премии и как защитить пул от bank run. Проконсультируйтесь с нашими инженерами, чтобы разработать полис под ваши риски.
Три класса рисков: как их покрываем
Как работает параметрическое страхование ликвидации?
Ликвидация — самый формализуемый страховой случай. Lending-протоколы (Aave, Compound) эмитируют события LiquidationCall с параметрами: кто ликвидирован, сколько collateral изъято, какой debt погашен. Страховой контракт слушает эти события через лог-фильтрацию или верифицирует через proof в рамках одной транзакции. Параметрическое страхование быстрее governance-голосования в 2-3 раза по скорости выплат и исключает человеческий фактор.
Главная сложность — момент выплаты. Если производить выплату сразу после события, атакующий может искусственно создать ликвидацию собственной позиции и получить страховую выплату. Защита:
- Минимальный период между открытием позиции и выплатой (cooling period, например 7 дней)
- Проверка, что health factor падал постепенно, а не резко (защита от flash loan-манипуляции оракулом)
- Лимит выплаты как процент от ущерба, а не полное покрытие (co-insurance, 20-30% от потери)
Как работает страхование от взломов протокола?
Страхование от смарт-контракт эксплойтов — сложнее. Страховой случай субъективен: «был ли это взлом или задокументированное поведение?» Один подход — UMA Optimistic Oracle: заявитель подаёт claim с bond (5% от суммы), в течение окна 2 часов любой может оспорить. При отсутствии оспаривания выплата проходит автоматически. Альтернатива — собственный dispute resolution с Kleros арбитражем.
Для coverage pools нужен отдельный пул ликвидности, который берёт на себя риск. LP получают yield от страховых премий (до 20% годовых при utilisation 70%), но несут риск выплат. Ключевая уязвимость — bank run: при крупном взломе все LP пытаются вывести ликвидность одновременно. Наша архитектура включает lockup period (минимум 7-14 дней с момента начала вывода) и gradual release через очередь выводов.
Как защититься от сбоя оракула?
Отдельный класс — страхование от манипуляции или сбоя Chainlink-фида. Однажды некорректный фид LUNA вызвал каскад ликвидаций на Venus Protocol. Параметрический страховой случай здесь: «отклонение цены оракула от медианы нескольких источников превысило 2% за 10 блоков».
Для верификации этого события 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
Статичные премии — это неправильно. Протокол динамически корректирует премии на основе:
- Текущей утилизации капитального пула (при utilisation < 50% премия снижается на 40%, при > 80% — растёт на 50%)
- Исторической волатильности застрахованного протокола (через 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 |
Сравнение подходов к определению страхового случая
| Подход | Скорость выплаты | Субъективность | Сложность реализации |
|---|---|---|---|
| Параметрический (ликвидация) | Мгновенно | Низкая | Средняя |
| Optimistic Oracle (UMA) | До 2 дней | Средняя | Высокая |
| Governance голосование | Недели | Высокая | Низкая |
Что входит в результат
- Полный аудит смарт-контрактов с отчётом об уязвимостях
- Развёртывание протокола на тестовой сети и mainnet
- Документация по эксплуатации и управлению рисками
- Исходный код с форматтирующими плагинами и тестами
- Обучение вашей команды по архитектуре и процессу обновления
- Поддержка в течение 30 дней после деплоя
Ориентиры по срокам
Минимальный протокол с одним классом риска (только ликвидации) — от 4 до 6 недель. Полноценный мультирисковый протокол с governance и динамическими премиями — от 8 до 14 недель. Плюс 2-4 недели на внешний аудит перед mainnet-деплоем.
Свяжитесь с нами для оценки вашего проекта. Закажите консультацию, и мы предложим архитектуру под ваш use case.