Крупний протокол втратив $197M через атаку на ліквідацію (DeFiLlama). Користувачі з полісами від Nexus Mutual отримали виплати — інші ні. Такий випадок показує: on-chain страхування — не маркетинг, а фінансовий примітив. Наш on-chain протокол страхування DeFi позицій пропонує страхування від ліквідацій, зломів та збоїв оракулів. Ми розробляємо протоколи, які вирішують три проблеми: як визначити страховий випадок без суб'єктивної участі, як динамічно розраховувати премії та як захистити пул від bank run. Вартість розробки базового протоколу — від $80k, повноцінний мультиризиковий — від $150k. Зверніться до наших інженерів для консультації.
Три класи ризиків: як їх покриваємо
Як працює параметричне страхування ліквідації?
Ліквідація — найбільш формалізований страховий випадок. Lending-протоколи (Aave, Compound) емітують події LiquidationCall з параметрами: хто ліквідований, скільки collateral вилучено, який debt погашено. Страховий контракт слухає ці події через лог-фільтрацію або верифікує через proof в рамках однієї транзакції. Параметричне страхування ліквідації працює в 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 (відношення капіталу пулу до максимальних виплат, оптимально 1:4)
Найпростіша формула: 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 - Документація з експлуатації та управління ризиками - Вихідний код з форматувальними плагінами та тестами (90%+ покриття) - Навчання вашої команди з архітектури та процесу оновлення - Підтримка протягом 30 днів після деплоюОрієнтири за термінами
Як відбувається розробка: 1) Аналіз вимог (1 тиждень), 2) Проектування архітектури (1-2 тижні), 3) Розробка смарт-контрактів (2-4 тижні), 4) Внутрішнє тестування (1 тиждень), 5) Зовнішній аудит (2-4 тижні), 6) Деплой (1 тиждень). Мінімальний протокол з одним класом ризику (тільки ліквідації) — від 4 до 6 тижнів. Повноцінний мультиризиковий протокол з governance та динамічними преміями — від 8 до 14 тижнів. Плюс 2-4 тижні на зовнішній аудит перед mainnet-деплоєм.
Зв'яжіться з нами для оцінки вашого проекту. Ми гарантуємо якість: сертифікований аудит, багаторічний досвід команди (7+ років у Web3), 15+ завершених аудитів та 45+ розроблених протоколів. Замовте консультацію, і ми запропонуємо архітектуру під ваш use case.