Розробка протоколу страхування DeFi

Розробка протоколу страхування DeFi

Після взлому Euler Finance в березні 2023 року (~197M USD через flash loan + donation attack) кілька команд, які будували поверх протоколу, дійшли одного висновку: децентралізоване страхування — не опція, а інфраструктура. Традиційні страхові моделі не працюють в DeFi: немає KYC, немає юрисдикції, немає «страховика останної інстанції». Потрібен протокол, який працює через смарт-контракти та incentive-и.

Три моделі децентралізованого страхування — і де кожна ломається

Mutual модель (Nexus Mutual-стиль)

Учасники вносять капітал у загальний пул, голосують за claims. Проблема — governance атаки на процес оцінки. Якщо claim assessor-и можуть мати неправильний incentive (sybil атака на голосування, куплений великий стейк NXM), протокол одобряє хибні виплати або відклинає легітимні.

Nexus Mutual вирішував це через стейкінг NXM на конкретні протоколи — assessor втрачає стейк, якщо голосує проти більшості. Але це створює проблему minority dissent: правильне меньшинство програє і несе фінансові втрати.

Parametric модель

Виплата триггерується автоматично при наступленню on-chain івенту: ціна oracle упала нижче порогу, функція контракту вернула unexpected value, totalSupply токена змінився на X%. Не потрібен ручний процес claim assessment.

Уязвимість: oracle manipulation. Якщо триггер — ціна Chainlink, атакуючий може flash loan-ом тимчасово сдвинути ціну, отримати страхову виплату, вернути кредит. Захист: TWAP oracle (30-хвилинна ковзаюча середня), мінімальний delay між подією й виплатою, потрібна кілька незалежних oracle.

Cover protocol модель (risk-пули під конкретні протоколи)

Андеррайтери надають ліквідність під конкретний протокол (наприклад, Aave на Ethereum mainnet), coverage holders платять премію. При взломі андеррайтери несуть убутки пропорційно стейку.

Складність: ціноутворення премій. Cover Protocol використовував AMM для динамічного ціноутворення coverage: високий спрос → висока ціна → сигнал ринку, що ризик великий. Елегантно, але створює front-running: якщо хтось бачить в mempool транзакцію «купити coverage», значить кто-то знає про предстоящий взлом.

Архітектура, яку ми будуємо

Claim verification — найскладніша частина

Автоматична верифікація взломів — нерішена задача для складних експлойтів. Можна автоматично верифікувати:

• Паузу протоколу через Pausable.paused() == true з часовим порогом
• Значиме зміну TVL (>50% за 1 блок через The Graph + on-chain snapshot)
• Вихід ціни за історичні границі по TWAP oracle
• Triggering governance emergency через timelocked proposals

Для складних випадків (reentrancy, логічні баги) потрібен гібридний підхід: on-chain параметричний триггер + optimistic dispute window. Виплата виходить автоматично через 72 години, якщо ніхто не оспорив через стейкінг collateral.

Це dispute resolution будуємо на базі UMA Optimistic Oracle або власної реалізації з аналогічною економічною логікою: challenger повинен застейкати collateral, якщо його dispute відклинено більшістю — втрачає стейк. Це робить хибні disputes дорогими.

Capital efficiency через tranches

Наївний страховий пул тримає 1:1 coverage:capital. При TVL застрахованих протоколів $100M потрібно $100M капіталу. Неефективно.

Tranched capital structure: Senior tranche (AAA) несе убутки останнім, отримує меньшу доходність; Junior tranche (BB) — першим, отримує більше. Кореляція ризиків між несвязаними протоколами низька, тому $10M junior капіталу може покривати $100M exposure якщо вероятність одночасного взлому всіх протоколів мала.

Математика: якщо 10 протоколів з незалежними ризиками 2% кожен, вероятність що два взломаються одночасно — ~0.04%. Junior tranche 5% від загального coverage покриває 95% сценаріїв. Це реальна математика портфельного страхування, не маркетинг.

Реалізація в Solidity: ERC-4626 vault для кожного транша з кастомною логікою розподілу убутків. При наступленню страхового випадку функція distributeloss(uint256 amount) спочатку списує з junior vault, потім з senior — через accounting в storage без реального руху коштів до redemption.

Premium pricing oracle

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

Базова формула: premium = basePremium * utilizationMultiplier * riskMultiplier

• utilizationMultiplier росте по мірі заповнення capacity (аналог interest rate curves в Aave)
• riskMultiplier — score від зовнішнього джерела (аудит репорт, TVL history, age of protocol)

riskMultiplier можна подавати через Chainlink Data Streams або власний oracle з multisig управлінням. Останнє — вектор централізації, який потрібно обозначати в документації.

Інтеграція з Chainlink Automation для claims processing

Claim processing — off-chain триггер on-chain дії. Chainlink Automation перевіряє checkUpkeep() кожен блок: якщо умова виконана (пройшов dispute window, немає активних challenges), викликає performUpkeep() з виплатою.

Альтернатива — Gelato Network для більш гнучких умов, включаючи off-chain computation через Web3 Functions.

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

Solidity 0.8.x + Foundry + OpenZeppelin 5.x. ERC-4626 для yield-bearing vault-ів з андеррайтерським капіталом. Chainlink TWAP для parametric triggers. UMA або власний optimistic oracle для dispute resolution.

Subgraph на The Graph для off-chain моніторингу TVL змін і історичних даних. Frontend: wagmi + viem, React, інтеграція з Gnosis Safe для мультисиг управління параметрами протоколу.

Процес роботи

Аналітика (3-5 днів). Визначаємо модель: parametric, mutual, або hybrid. Аналізуємо цільові протоколи для страхування, їх on-chain поведінку, доступні параметри для triggering. Проектуємо економічну модель: капітал, премії, tranches.

Проектування (5-7 днів). Формальна специфікація інваріантів. Головний інваріант: totalCoverage <= totalCapital * leverage_factor завжди. Нарушення — платіжеспроможна криза.

Розробка (6-10 тижнів). Vault контракти → claim логіка → oracle інтеграції → dispute resolution → governance → frontend.

Аудит (обов'язків). Страховий протокол з неверною логікою убутків може бути дренований швидше, ніж застрахований протокол. Зовнішній аудит від спеціалістів по DeFi обов'язників. Echidna з інваріантами на solvency — до відправки в аудит.

Орієнтири по термінам

Parametric протокол з одним triggered event — 4-6 тижнів. Повна mutual/hybrid система з dispute resolution, tranched capital і dynamic pricing — 2-3 місяці. Без урахування аудиту.

Вартість залежить від складності моделі і вимог до децентралізації управління.