Розробка системи децентрализованого страхування
Nexus Mutual втратив 8 мільйонів доларів у 2020 році — не через взлом, а тому, що атакуючий маніпулював процесом голосування клеймів. Власник токенів навмисне голосував проти легітимних виплат, щоб не допустити dilution своєї доліі. Це системна проблема дизайну механізму, не уразливість контракту. Протокол, який ми проектуємо, повинен бути стійкий до трьох класів атак одночасно: економічних (маніпуляція стейком/голосуванням), технічних (reentrancy на клеймах, oracle manipulation) та governance (захват управління через flash loan). Ні один з них не вирішується «просто написати хороший контракт».
Ключові механіки протоколу
Страховий пул та андеррайтинг
Основа — capital pool з коштів LP-провайдерів, які приймають на себе ризик в обмін на долю премій. Андеррайтинг конкретного покрття (наприклад, smart contract exploit на Aave v3) — це створення під-пулу з виділеним капіталом та ціноутворенням на основі оцінки ризику.
Ціноутворення через модель Poisson: ймовірність клейма λ помножена на середню суму виплати μ. Премія = λ * μ * coverage_amount * duration. Параметри λ оновлюються за результатами історичних клеймів — або вручну governance, або через on-chain оракул з даними аудитів та інцидентів.
Проблема: якщо параметри ризику зберігаються on-chain та оновлюються governance, з'являється вектор атаки — атакуючий може пролоббювати занижено λ для конкретного протоколу, скупити дешеве покрття, організувати експлойт, отримати виплату. Захист: time lock на оновлення параметрів ризику + мультисиг з розділеними ключами для критичних параметрів.
Процес верифікації клейма — найскладніша частина
Три підходи до верифікації, кожен з trade-offs:
Optimistic verification (Kleros-стиль). Клейм вважається валідним за замовчуванням, якщо ніхто не оспорив за challenge_period (наприклад, 72 години). Оспорювання вимагає стейка від challenger. Якщо оспорено — йде до арбітраж через Kleros Court. Швидко та дешево для неспорних випадків, але уразливо до «мовчазної більшості» — ніхто не оспорює, тому що стейкинг ризику невигідний.
Commit-reveal голосування ассесорів. Власники токенів стейкають, голосують закритими хешами, розкривають. Мажоритарна сторона отримує reward, меньшість втрачає стейк (Schelling point механіка). Вимагає активної участі спільноти. Підвружено атаці через flash loan: займе токени на голосування, проголосувати, повернути.
Захист від flash loan у голосуванні: snapshot voting — право голосу визначається балансом на блоку N, голосування відбувається на блоку N+k. Flash loan не працює, тому що токени повинні бути у гаманці до события, про яке ще не відомо.
Параметричний триггер (оракул). Виплата відбувається автоматично при наступленні on-chain события — наприклад, якщо ціна оракула Chainlink відхилилася >X% за Y блоків, або якщо TVL протоколу упав >50% за 24 години. Не вимагає голосування, але покриває тільки параметрично описуємі ризики. Підходить для depeg coverage, liquidation cascade, bridge exploit з публічними даними.
Ми будуємо гібридну систему: параметричні триггери для автоматичних дрібних клеймів, commit-reveal з захистом від flash loan для крупних.
Capital efficiency через cover tokens
LP провайдер депонує 100 ETH, отримує cvETH — токен, що представляє долю в пулі. cvETH можна використовувати в DeFi (стейкинг, коллатерал), поки немає активних клеймів. При активації клейма на суму X контракт locks відповідну долю cvETH до завершення процесу верифікації. Це усуває проблему bank run: LP не може вивести коште, поки не розв'язані все pending клеймів проти його частини пулу.
Технічна реалізація: ERC-4626 vault для capital pool + кастомна lockShares(address lp, uint256 amount) з контролем доступу тільки від ClaimsManager контракту.
Storage layout та архітектура контрактів
InsuranceCore (proxy UUPS)
├── CapitalPool (ERC-4626)
├── CoverageManager (створення/управління покриттями)
├── ClaimsManager (процес клеймів)
│ ├── ParametricOracle (Chainlink + кастомні триггери)
│ └── VotingEngine (commit-reveal)
├── PricingEngine (розрахунок премій)
└── GovernanceTimelock (зміна параметрів)
Proxy UUPS з ERC-7201 namespaced storage — обов'язково, протокол буде апгрейдуватися. Без namespaced storage перший апгрейд з доданою змінною сломає storage layout ClaimsManager.
Типові уразливості, які закриваємо
Reentrancy на виплатах. ClaimsManager.processPayout() робить зовнішній вызов до токен-контракту. Якщо покрття номіновано в ERC-777 (з хуком tokensReceived), атакуючий може рекурсивно викликати processPayout до оновлення стану. Рішення: nonReentrant + Checks-Effects-Interactions строго, стан клейма змінюється до transfer.
Oracle manipulation через flash loan. Параметричний триггер на ціну → атакуючий бере flash loan, роняє ціну на DEX, триггер срабатує, отримує виплату, повертає flash loan. Захист: TWAP від Uniswap v3 замість spot price, мінімальний TWAP період 30 хвилин. За 30 хвилин утримати маніпульовану ціну на mainnet — вартість атаки перевищує потенційну виплату при будь-якому розумному coverage amount.
Governance takeover. Якщо управління протоколом через токен-голосування, та токен можна купити/одолжити — governance можна захватити. Стандартне рішення: timelock на виконання proposals (48-72 години), що дає спільноті вікно для реакції. Для критичних параметрів — multisig з quorum >50% + timelock. Guardian address з можливістю veto для emergency.
Процес розробки
Аналітика та mechanism design (1-2 тижні). Це найважливіший етап. Визначаємо: які ризики страхуються, як влаштований capital pool, механіка pricing, повний flow клейма. Пишемо формальну специфікацію з інваріантами — «capital pool завжди покриває не менше 100% active coverage», «клейм не може бути виплачений дважды».
Розробка контрактів (3-4 тижні). Solidity + Foundry. Кожен інваріант — це property-based тест у Echidna. Fork-тести інтеграції з Chainlink oracles та Uniswap TWAP на реальних mainnet даних.
Внутрішній аудит (1 тиждень). Slither, Mythril, ручний review по SWC checklist. Особлива увага: всі шляхи виплат, всі точки оновлення параметрів ризику, всі місця з зовнішніми вызовами.
Зовнішній аудит (2-4 тижні). Для протоколу з TVL >500k USD — обов'язково. Бюджет на аудит закладається в проект відразу.
Testnet + bug bounty (1-2 тижні). Деплой на Sepolia/Arbitrum Goerli, відкрита програма пошуку уразливостей через Immunefi або Code4rena.
Mainnet деплой. Через Gnosis Safe мультисиг. Початковий cap на TVL — «soft launch» з обмеженим покриттям для перевірки механік у production.
Орієнтири за строками
Базовий протокол з параметричним триггером та простим capital pool — від 4-6 тижнів. Повна система з голосуванням ассесорів, governance, апгрейдаємістю та аудитом — 2-3 місяці. Строки сильно залежать від складності mechanism design на входе.
Вартість рассчитується після детального обговорення архітектури та вимог до покриваємих ризиків.