№13 Страховые протоколы

После DeFi-лета 2020 года интерес к криптоиндустрии значительно увеличился. Это привело к тому, что на нее обратили внимание злоумышленники и хакерские группировки. Именно с этого момент, начались большие проблемы в области безопасности DeFi-протоколов, которые продолжаются до сих пор, но уже в значительно меньшем масштабе, чем в 2021 году.

Чтобы решить проблемы безопасности, большинство проектов принимало решение пройти аудиты. Для этого, они связывались с аудиторскими компаниями в сфере блокчейна (такими как CertiK) и отдавали на ручную или автоматическую проверку коды своих-смарт-контрактов. Однако, даже это не давало полной уверенности в том, что это поможет защититься от хакерских угроз. Лишь чем больше проходило атак, тем больше расширялась экспертиза аудиторов, но в это время страдали множество DeFi-проектов и команд.

В связи с этим, появился второй пласт безопасности - страховые протоколы. И хотя их идея появилась еще на бычьем рынке 2017-2018 годов - более известны они стали именно после 2020 года. Модель проекта состоит в том, чтобы, как и в традиционном мире - покупать страховку на определенный срок для защиты от различных инцидентов, связанных с потерей средств и имущества.

DeFi-протоколы попытались реализовать эту модель на блокчейне. Однако, чтобы она оказалась успешной, необходимо было придумать реализовать 2 важнейших решениях для страховых протоколов:

• откуда взять средства для потенциальных выплат пострадавшим
• как определять безопасность проекта или, по-другому, кредитный рейтинг

Для устойчивого функционирования страхового протокола, они должны обладать значительным количеством ликвидности. Именно поэтому в традиционном мире зачастую крупнейшими страховщиками являются банковские структуры.

Поэтому перед командами таких проектов стал закономерный вопрос как увеличить объем ликвидности, особенно в рамках значительно меньшего объема средств в криптоиндустрии, по сравнению с миром традиционных финансов. Именно здесь понятие DeFi и пришло на помощь - страховые протоколы открыли пулы ликвидности для депозита активов, и взамен большую часть прибыли от покупки страховок отдавали провайдерам ликвидности. Справедливая и честная модель, в которой ни один из проектов не контролирует ликвидности пользователей.

Однако, не все так просто. В случае реального эксплойта застрахованного протокола, в котором лицо, купившее страховку, потеряло деньги - страховщик должен будет выплатить средства провайдеров ликвидности. Это значит, что они несут потенциальный расходы. Понимание этого момента значительно тормозило рост страховых протоколов, особенно в те моменты, когда взломам подвергался каждый второй DeFi-проект.

Другой проблемой является тот факт, что в некоторых протоколах страхования, ликвидностью служит собственный токен проекта. Это означает, что он может подвергаться излишнему давлению или спросу и тем самым страховой резерв будет либо расти, либо уменьшаться. Более того, в случае выплат, на него будет оказываться давление, что в итоге сделает выплату еще более дорогой, так после продажи, стоимость токена снизится, а следовательно и его объем в страховых пулах.

При этом стоит отметить тот факт, что доходность провайдеров ликвидности в страховые протоколы не является высокой и находится в диапазоне 1% - 4%. Эти же значения наблюдаются децентрализованных кредитных протоколах, но без прямого риска потери средств. Именно поэтому, большинство пользователей предпочитало использовать именно их.

Вторым важным являлась оценка риска взлома или фактора безопасности. На основании этого вычисляет базовая стоимость страхования и дохород поставщиков ликвидности. Оценка риска использования страховых средств, по своей сути, и является главным бизнесом любой страховой компании.

Самое сложное здесь является то, как оценить безопасность страхуемого протокола. На текущий момент нет единого подхода, который используется такими проектами. Существует несколько бизнес-моделей, каждая из которой имеет свои преимущества и недостатки:

• оценка безопасности протокола поставщиков ликвидности - это значит, что владелец ликвидности должен сам оценить протокол на предмет безопасности, риска взлома. Однако, в реальности так не происходит - чем громче имя DeFi - проекта, тем больше надежности к нему в глазах пользователей. Это значит, что проверять надежность протокола будут единицы. Пример с крахом FTX показывает, что даже самые крупные инвесторы не проводят должного анализа перед вкладыванием средств, что тут говорить о рядовых пользователях.
• оценка безопасности протокола командой страхового протокола - это значит что есть специальные люди, которые оценивает надежность, кредитоспособность, безопасность. Проблема здесь заключается в централизованном факторе, так как эти люди могут продвинуть откровенно опасный протокол из-за каких-либо причин (чаще всего “ему заплатили”).

И хотя первый случай в целом является децентрализованным и удовлетворяет условиям, но в реальности никто не будет ничего изучать, и уж тем более среди них мало экспертов в области оценки технических и практических рисков. Второй вариант - это полностью централизованный подход, который не раз доказывал свою уязвимость. Но лучше решений на текущий момент так и не появилось.

Также отметим, что протоколы разделяют уровень риска между проектами и защиту от конкретных потенциальных угроз. Например, стоимость страховки от взлома смарт-контракта будет отличаться от стоимости в случае депега того же актива. В целом, все страховки разделяются на группы не только по проектам, но и по виду угрозу. Поэтому покупатель должен четко для себя решить, от чего именно он готов застраховаться. В целом, это очень похоже на страховые компании в реальном секторе.

Также отметим, что каждая из страховок имеет максимальную пропускную способность. Это значит, что покупатель страховки ограничен объем ликвидности, который внес в провайдер ликвидности. Это полностью защищает от перекредитованности и кредитного плеча, используемым страховым протоколом. Так, если пользователь покупает страховку, то часть ликвидности блокируется до момента окончания срока ее действия. Все это значит, что число страховок ограничено объемом, внесенным в страховой протокол, и есть вероятность, что купить страховку будет просто невозможно.

Особенности

Также некоторые из протоколов ввели решение, которое позволяет безрисково увеличить доходность для поставщиков ликвидности. Для этого, они используют проставивающую ликвидность для автоматического размещения низкорискованных DeFi-протоколах, таких как агрегаторы ликвидности и кредитные протоколы.

Протоколы понимают, что поставщики ликвидности несут высокий риск потерь, вкладываясь лишь в страховку конкретных протоколов. Поэтому некоторые из них придумали что-то наподобие индекса страховок, когда провайдер ликвидности отдает деньги в него - он распределяет свои активы сразу между всеми страховками, доступными на платформе. Это значительно снижает степень риска.

Отметим, что очень многие страховые протоколы предлагали защиту от рисков депега UST, USDN. Как мы в итоге знаем, эти депеги случились и пользователи потеряли деньги. Страховые протоколы возместили все потери из пулов ликвидности и хотя потеряли из-за этого объем ликвидности - их модель осталась рабочей и не подвергалась сомнению.

Сами возмещения происходят не моментально. Обычно необходимо самому предоставить доказательства утраты средств ончейн и оффчейн способом. Иными словами, дать свой адрес и официальный источник о взломе либо страховом случае. Решение по выплате чаще всего принимает DAO. Весь этот процесс может длиться от 3 до 14 дней.

Еще раз повторимся - провайдеры ликвидности могут потерять средства, поэтому вкладывать необходимо с учетом сопутствующих рисков.