Розробка протоколу страхування DeFi-позицій

Розробка протоколу страхування DeFi-позицій

У березні 2023 року Euler Finance втратив $197M через вразливість у логіці ліквідацій. Користувачі, чиї позиції були застраховані через Nexus Mutual, отримали виплати; інші — ні. Це наглядно демонструє, чому потрібне страхування on-chain: не як маркетинговий інструмент, а як реальний фінансовий примітив. Побудувати такий протокол складно — треба вирішити проблему oracle для визначення страхової події, сформулювати параметричні умови без суб'єктивних суддів та збалансувати премії так, щоб протокол залишався платоспроможним.

Три класи ризиків та способи їх покриття

Ризик ліквідації: параметричне страхування

Ліквідація — найбільш формалізований страховий випадок. Кредитні протоколи (Aave, Compound) видають события LiquidationCall з чіткими параметрами: хто був ліквідований, скільки закладу вилучено, який борг погашений. Страховий контракт може слухати ці события через фільтрацію логів або верифікувати їх через доказ у межах однієї транзакції.

Складність полягає в іншому: коли виплачувати? Якщо одразу після события, атакуючий може створити штучну ліквідацію власної позиції (самоліквідацію) та отримати страховиту виплату. Захисти:

• Мінімальний період охолодження між відкриттям позиції та виплатою (наприклад, 7 днів)
• Перевірка того, що health factor падав поступово, а не різко (захист від flash loan маніпуляцій oracle)
• Ліміт виплати як відсоток від збитків, а не повне покриття (co-insurance)

Ризик взлому протоколу: пули покриття

Страхування від експлойтів smart contract складніше. Страховий випадок субективний: «це був справжній взлом чи документоване поведінка?» Nexus Mutual вирішує це через голосування governance claimassessors. Більш децентралізований підхід використовує UMA Optimistic Oracle: заявник подає заяву з bond; опонент може оспорити протягом вікна; без опозицій виплата проходить автоматично.

Пули покриття потребують окремої ліквідності, яка приймає ризик. LP отримують урожай від страхових премій, але несуть ризик виплат. Це той самий механізм, що в Nexus Mutual (NXM staking) та InsurAce.

Ключова вразливість пулів покриття — bank run: коли трапляється великий взлом, усі LP намагаються вивести ліквідність одночасно. Захисти включають периоди lock для LP (мінімум 7-14 днів від ініціації виведення) та поступовий вихід через чергу виводів.

Ризик відмови oracle: страхування circuit breaker

Окремий клас охоплює маніпуляцію или відмову Chainlink-фіду. У листопаді 2022 року неправильний LUNA-фід спричинив каскад ліквідацій на Venus Protocol. Параметричний страховий випадок тут: «відхилення ціни oracle від медіани кількох джерел перевищує X% протягом Y блоків».

Для верифікації цієї события on-chain потрібен агрегатор кількох oracle прямо у страховому контракті — Chainlink + Uniswap V3 TWAP + Pyth Network. Якщо їхні медіани розходяться більш ніж на поріг — страховий випадок наступає автоматично без голосування.

Архітектура протоколу

Модульна структура

InsuranceCore.sol          — основний маршрутизатор
├── PolicyManager.sol      — створення та зберігання полісів
├── PremiumCalculator.sol  — динамічний розрахунок премій
├── ClaimsProcessor.sol    — верифікація та виплати
├── CapitalPool.sol        — пул капіталу LP
└── RiskOracle.sol         — агрегатор умов страхової події

Кожний модуль оновлюється через UUPS, але з governance timelock мінімум 48 годин. Для ClaimsProcessor — окремий timelock 7 днів: виплати не повинні проходити миттєво без можливості оспорювання.

Розрахунок премій: on-chain актуарна модель

Статичні премії — це неправильно. Протокол повинен динамічно коригувати премії на основі:

• Поточного використання капітального пулу (більше активних полісів → вищі премії)
• Історичної волатильності застрахованого протоколу (через on-chain дані)
• Коефіцієнта покриття (відношення капіталу пулу до максимальних виплат)

Проста формула: premium = basePremium * utilizationMultiplier * riskMultiplier. Усі три параметри оновлюються governance з timelock.

Верифікація через Merkle proof

Для страхування позицій на Aave користувач може надати Merkle proof своєї позиції зі snapshot стану протоколу на момент страхової eventi. Це дозволяє не зберігати всі позиції on-chain, а верифікувати належність конкретної позиції до набору постраждалих.

Генерація Merkle tree відбувається off-chain через The Graph subgraph, доказ публікується в IPFS, ClaimsProcessor верифікує через MerkleProof.verify() з OpenZeppelin.

Критичні вразливості, які потрібно закрити

Стек розробки

Контракти: Solidity 0.8.24 з optimizer 200. Математика премій використовує FixedPointMathLib з Solmate (більш газоефективна, ніж PRBMath для простих операцій). Верифікація claims інтегрується з UMA Optimistic Oracle v3 або власним вирішенням спорів через Kleros арбітраж.

Тестування за допомогою Foundry fork-тестів на Aave V3 mainnet: моделюємо реальні ліквідації та перевіряємо правильність триггерів. Echidna property tests гарантує, що totalPayouts <= totalPremiums + initialCapital дотримується при будь-якій послідовності операцій.

Frontend використовує wagmi v2 з Viem, відображаючи відкриті позиції через інтеграцію з Aave subgraph на The Graph.

Процес розробки

Аналітика (1 тиждень). Визначаємо покриті протоколи, класи ризиків, параметри страхових подій. Формалізуємо всі умови виплати як on-chain верифіковані.

Архітектура (3-5 днів). Модульна структура, вибір oracle (UMA/Kleros/параметричний), tokenomics пулу капіталу.

Розробка (3-5 тижнів). Послідовно: пул капіталу → розрахунок премій → полісі → claims. Повне покриття тестами для кожного модуля.

Аудит (2-4 тижні). Внутрішній Slither + Mythril + Echidna. Обов'язковий зовнішній аудит — протоколи з реальним капіталом без аудиту не розгортаються.

Розгортання та моніторинг. Gnosis Safe multisig. Моніторинг через Tenderly Alerts на критичні события.

Орієнтири по срокам

Мінімальний протокол з одним класом ризику (тільки ліквідації): 4-6 тижнів. Повноцінний мультирисковий протокол з governance та динамічними преміями: 8-14 тижнів. Додайте 2-4 тижні для зовнішнього аудиту перед mainnet деплоєм.