📑Методология Оценки Рисков
Группа оценки рисков в UX использует оценочную карту с подкомпонентами в рамках более широкой структуры. Ниже приведен пример карты с максимально возможным баллом 10. Каждый подкомпонент взвешивается на основе важности по сравнению с другими показателями риска.
| ВИД РИСКА | БАЛЛ (0/10) | ВЕС (%) | РЕЗУЛЬТАТ | СЧЕТ |
|---|---|---|---|---|
РИСК ПРОТОКОЛА | ТРАНЗАКЦИИ И ИСТОРИЯ | 12,5 % | 1,25 | 10 |
РИСК ПРОТОКОЛА | БЕЗОПАСНОСТЬ И АУДИТ | 10,0 % | 1 | 10 |
РЫНОЧНЫЙ РИСК | РЫНОЧНАЯ КАПИТАЛИЗАЦИЯ | 14,5 % | 1,45 | 10 |
РЫНОЧНЫЙ РИСК | СРЕДНИЙ ОБЪЕМ ТОРГОВ | 12,5 % | 1,25 | 10 |
РЫНОЧНЫЙ РИСК | НОРМАЛИЗОВАННОЕ ЗНАЧЕНИЕ РИСКА И ВОЛАТИЛЬНОСТЬ | 12,5 % | 1,25 | 10 |
ОПЕРАЦИОННЫЙ РИСК | КОМАНДА | 10,0 % | 1 | 10 |
ОПЕРАЦИОННЫЙ РИСК | ТОКЕНОМИКА | 10,0 % | 1 | 10 |
ОПЕРАЦИОННЫЙ РИСК | КОНКУРЕНТНОСПОСОБНОСТЬ | 10,0 % | 1 | 10 |
РИСК КОНТРАГЕНТА | ЦЕНТРАЛИЗОВАННОСТЬ | 4,0 % | 0,4 | 10 |
РИСК КОНТРАГЕНТА | ДЕРЖАТЕЛИ | 4,01 % | 0,4 | 10 |
Риск Протокола
Риск протокола измеряет техническую безопасность базового кода для данного актива. Код для активов со строгим аудитом, проведенным уважаемыми аудиторами - то, что подходит для UX. Помимо аудитов, остается риск протокола (т. е. уязвимости будут существовать), и пользователи должны добросовестно оценивать такой риск. Кроме того, UX будет использовать вознаграждение за ошибки, чтобы снизить риск смарт-контракта. Количество транзакций и количество дней, в течение которых конкретный смарт-контракт оставался нескомпрометированным при регулярном использовании, постоянной разработке, сообществом и т. д., могут служить показателем того, насколько контракт закален в боях.
Рыночный Риск
Рыночные риски тесно связаны с размером пула активов и динамикой спроса и предложения. Адекватный объем торгов необходим для исполнения необходимого количества ликвидаций в данном пуле, т. е. крупных продаж в экстремальных рыночных условиях, которые вызывают проскальзывание и снижают полученную долларовую стоимость. Среднедневной объем торгов является ключевым критерием для оценки доступности актива для продажи в дополнение к глубине ликвидности.
Риск волатильности основан на нормированных колебаниях цен на токен и рассчитывается с использованием формул, соответствующих отраслевым стандартам, используемым другими крупными биржами. Риск волатильности переоценивается и обновляется через установленные промежутки времени, определяемые протоколом UX, учитывая, что цены на токены склонны к внезапным скачкам волатильности; в этом развивающемся классе активов не будет ошибкой наблюдать большие колебания цен на 50% и более в любом направлении в течение коротких промежутков времени.
Наконец, рыночная капитализация показывает размер рынка и уровень взаимодействия игроков. Исходные данные о рыночном риске передаются в модель риска UX для калибровки параметров, которые помогают снизить каждый компонент рыночного риска. Ввод волатильности определяет сумму залога или отношение кредита к стоимости. Риски ликвидности регулируются соответствующими стимулами при ликвидации, т. е. порогом ликвидации и нормой прибыли для ликвидаторов.
Операционный Риск
Операционный риск учитывает ключевые заинтересованные стороны, которые могут повлиять на стратегическое направление и финансовый результат протокола, например, такие как члены основной команды. Токеномика также является важным компонентом, как и цель использования токена, эмиссия предложения, по сравнению с уровнем спроса, сильно влияют на стабильность токена. Конкурентоспособность оценивает, как рассматриваемый протокол позиционируется с аналогичными протоколами как внутри, так и за пределами экосистемы, в которой он расположен.
Риск Контрагента
Риск контрагента учитывает человеческий капитал, стоящий за активом, и то, как он влияет на управление. В частности, UX будет оценивать уровень децентрализации и способность избранных заинтересованных сторон влиять на контроль над фондами или другие векторы атак, которые могут проникать в структуру управления и в конечном итоге передать контроль над фондами нескольким сосредоточенным группам. Риск централизации измеряется количеством сущностей, которые могут контролировать базовый протокол актива, количеством держателей токена и другими предположениями о доверии (например, поддержка актива), которые могут создавать уязвимости.
Last updated