Перевод

Это вольный перевод важнейшего решения: https://governance.aave.com/t/arfc-technical-asset-listing-framework/24988.

Краткое содержание

Aave Labs предлагает внедрить стандартизированный Technical Asset Listing Framework (TALF) для активов, претендующих на листинг, сохранение листинга или существенное расширение параметров в Aave V3, Aave V4 и Horizon.

Цель инициативы - сделать процесс листинга и мониторинга активов более единообразным, прозрачным и воспроизводимым, а также создать постоянную базу для контроля того, что уже размещённые активы продолжают соответствовать требованиям качества и безопасности протокола.

Фреймворк должен дополнять существующие методологии риск-провайдеров и Aave Asset Classification Framework (AACF), определяя публичный базовый стандарт технической безопасности.

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

Однако данный ARFC не устанавливает конкретные пороговые значения рейтингов и не определяет исчерпывающий список блокирующих факторов.

Мотивация

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

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

Среди ключевых требований:

• совместимость с ERC-20;
• предсказуемое поведение переводов токена;
• ограниченная эмиссия (bounded minting);
• надёжный контроль привилегированных ролей;
• устойчивые и надёжные оракулы;
• безопасная архитектура мостов (bridges);
• наличие аудита кода;
• раскрытие информации о внецепочечных компонентах и договорённостях, если критически важные данные отсутствуют ончейн.

Хотя многие из этих вопросов являются техническими, они напрямую влияют на:

• платёжеспособность Aave;
• процессы ликвидации;
• настройку параметров обеспечения;
• архитектуру оракулов;
• механизмы экстренного реагирования.

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

Поэтому данный ARFC предлагает формализовать и стандартизировать технические требования к активам, чтобы все будущие предложения оценивались по единому базовому стандарту, а DAO могло чётко понимать:

• какие активы соответствуют требованиям;
• какие требуют дополнительных мер по снижению рисков;
• какие нуждаются в дополнительном аудите или доработке.

Область применения

Фреймворк распространяется на:

• новые листинги активов в любых экземплярах Aave V3, Aave V4 и Horizon;
• уже размещённые активы, проходящие существенные изменения;
• уже размещённые активы, подлежащие периодической или внеплановой технической переоценке.

Фреймворк учитывает особенности разных сетей. Если актив существует в нескольких блокчейнах, он должен соответствовать требованиям в каждой из них отдельно, включая:

• реализацию смарт-контрактов в каждой сети;
• используемые оракулы;
• архитектуру мостов;
• систему контроля доступа;
• конфигурацию внешних зависимостей.

При этом фреймворк не заменяет:

• анализ рыночных рисков;
• анализ ликвидности;
• юридическую экспертизу;
• дискреционные решения DAO.

Он определяет базовый уровень технической пригодности актива. Решения о листинге и параметрах актива по-прежнему остаются за DAO и принимаются на основе полного набора доступной информации, проведённого анализа и рекомендаций сервис-провайдеров.

Анализ ликвидности и глубины рынка предполагается получать от риск-провайдеров DAO в рамках их стандартной оценки рыночных рисков. Их выводы должны рассматриваться совместно с техническими выводами данного фреймворка при определении таких параметров, как:

• Supply Cap;
• Borrow Cap;
• коэффициенты обеспечения (Collateral Parameters).

Связь с AAcA

Каждый актив сначала должен быть отнесён к соответствующей категории в рамках Aave Asset Classification Framework (AAcA).

На этапе предварительного отбора категория AAcA должна быть подтверждена. Активы, относящиеся к неразрешённым (non-approved) или санкционированным категориям, не должны проходить дальше по процессу оценки.

Классификация AAcA определяет, на каких требованиях необходимо сосредоточить основное внимание при проверке. Например:

• доходные активы (yield-bearing assets) должны соответствовать специальным требованиям к обменному курсу (exchange rate), процедурам вывода средств (withdrawal path) и механизму CAPO;
• мостовые активы (bridged assets) должны соответствовать требованиям к безопасности мостов и целостности предложения токенов (supply integrity).

Методология оценки

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

Он не предназначен для публикации фиксированных рейтинговых шкал или полного списка автоматических причин для отказа.

Когда Aave Labs или другой участник готовит официальный технический отчёт по активу, такой отчёт может включать:

• качественные оценки по отдельным разделам;
• метки рисков (risk labels);
• другие результаты оценки.

Эти оценки следует рассматривать как выводы конкретного отчёта, основанные на:

• анализируемом активе;
• конкретной сети развёртывания;
• предоставленной эмитентом информации;
• текущем состоянии рынка и самого протокола.

Что должен содержать технический обзор?

Проверка должна чётко разделять фактические выводы и рекомендации.

Для каждого раздела аудитор или рецензент должен указать:

• какие контракты и системы были проверены;
• ключевой вывод;
• необходимые исправления (remediation);
• остаточный риск после исправлений;
• должен ли выявленный риск ограничивать параметры листинга или лимиты экспозиции;
• итоговую качественную оценку и заключение.

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

Существенные недостатки могут привести к:

• снижению лимитов экспозиции;
• усиленному мониторингу;
• переносу листинга;
• рекомендации не проводить листинг до устранения проблем.

Требования предварительного отбора (Pre-Screening)

До начала полноценной технической проверки актив должен соответствовать следующим требованиям:

1. Контракт актива должен быть развёрнут и верифицирован в целевой сети.
2. Категория актива в рамках AAcA должна быть подтверждена.
3. Актив не должен относиться к неразрешённой или санкционированной категории AAcA.
4. Если актив уже присутствует в Aave, существующие листинги должны быть выявлены и использованы как ориентир для параметров там, где это применимо.
5. Должен быть определён наиболее близкий по характеристикам актив, уже размещённый в Aave.
6. Байткод прокси-контракта и реализации должен совпадать либо быть сопоставлен с последней аудированной версией кода (если используется прокси-архитектура).
7. Если существует сопоставимый актив, он должен использоваться как отправная точка для настройки:
• оракулов;
• LTV;
• Liquidation Threshold;
• лимитов (Caps);
• прочих параметров обеспечения.

При этом окончательные параметры всё равно должны учитывать уникальный технический профиль нового актива.

Стандартный отчёт по результатам проверки (Standard Findings Report)

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

Отчёт может содержать:

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

При этом данный ARFC не определяет эталонные значения или шкалы для таких оценок.

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

Разделы фреймворка

Ниже перечислены основные технические области, которые обычно должны проверяться при рассмотрении:

• нового листинга;
• сохранения листинга;
• существенного расширения параметров актива в Aave.

Этот перечень не является окончательным или исчерпывающим.

Дополнительные требования могут появляться в зависимости от:

• типа актива;
• особенностей реализации;
• среды развёртывания;
• операционной модели эмитента;
• внешних зависимостей;
• новых рисков, выявленных DAO или сервис-провайдерами.

Активы с существенными оффчейн-компонентами

Для активов, имеющих значимые внецепочечные элементы, включая:

• токенизированные реальные активы (RWA);
• кастодиальные инструменты;
• активы, погашение или обеспечение которых зависит от юридических соглашений, а не от смарт-контрактов,

требования данного фреймворка применяются прежде всего к ончейн-слою.

При этом оффчейн-механизмы, влияющие на:

• целостность предложения токена (supply integrity);
• надёжность погашения (redemption reliability);
• контрагентские риски,

должны быть раскрыты и оценены в рамках:

• Раздела 8 (Dependencies and Composability);
• раздела Issuer Expectations.

Если оффчейн-компонент является критически важной зависимостью, он должен проверяться столь же тщательно, как и критическая ончейн-зависимость.

1. Соответствие стандарту ERC-20 (ERC20 Compliance)

Активы, размещаемые в Aave, должны вести себя предсказуемо с точки зрения стандартных предположений ERC-20 и общей совместимости с DeFi-протоколами.

Технические требования

Контракт должен корректно реализовывать следующие функции:

• name()
• symbol()
• decimals()
• totalSupply()

и возвращать разумные значения.

Функции:

• transfer()
• transferFrom()

должны возвращать булево значение (bool).

Токен не должен иметь механизмов:

• Fee-on-Transfer (комиссия при переводе);
• автоматического ребейза (rebase),

если только не используется специальная обёртка (wrapper), которая устраняет эти особенности.

Токен не должен использовать:

• ERC-777 Hooks;
• callback-механизмы передачи ERC-1363.

Если поддерживается Flash Mint, необходимо:

• полностью документировать механизм;
• доказать, что он не нарушает учёт активов и логику работы Aave.

Смарт-контракты должны иметь возможность:

• хранить токены;
• получать токены;
• отправлять токены

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

Количество десятичных знаков (decimals) должно быть совместимо с:

• интеграциями Aave;
• пользовательскими интерфейсами Aave.

Что считается проблемой?

Следующие особенности обычно требуют исправления либо специального подхода к листингу:

• Fee-on-Transfer токены;
• ребейзинг-токены без безопасной обёртки;
• использование ERC-777 Hooks;
• нестандартные decimals, которые невозможно безопасно интегрировать.

До устранения таких проблем актив обычно не рассматривается как полностью соответствующий требованиям фреймворка.

Для RWA-проектов и стейблкоинов это означает, что Aave фактически начинает с самого базового вопроса:

Можно ли обращаться с этим токеном как с обычным ERC-20 без скрытых побочных эффектов для учёта, ликвидаций и залоговой системы?

Если ответ отрицательный, дальнейший анализ часто теряет смысл до устранения этой проблемы.

2. Оракулы (Oracle)

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

Технические требования

• В целевой сети должен существовать ценовой фид Chainlink, который используется напрямую либо через адаптер CAPO, если это необходимо.
• Количество десятичных знаков (decimals) в ценовом фиде должно соответствовать стандартам Aave.
• Ценовой фид должен работать в рамках ожидаемых параметров heartbeat и deviation threshold. Любые отклонения должны быть отдельно объяснены.
• По возможности должны быть определены аналогичные оракульные адаптеры из уже существующих развёртываний Aave.
• Необходимо проверить и задокументировать уровень риска соответствующего фида Chainlink (Chainlink Market Risk Tier).
• Для доходных активов (yield-bearing assets) должен использоваться CAPO там, где это требуется для ограничения предположений о росте цены или обменного курса.

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

3. Контроль доступа и управление активом (Asset Operations Access Control)

Актив должен иметь понятную систему контроля доступа и гарантии безопасности предложения токенов как на уровне ERC-20 контракта, так и на уровне вспомогательных (periphery) контрактов, способных влиять на:

• предложение токенов;
• балансы пользователей;
• возможность перевода токенов;
• процедуры погашения (redemption).

Помимо перечисления привилегированных ролей необходимо оценивать:

• кому принадлежат эти роли;
• насколько они сконцентрированы;
• создаёт ли их структура общие точки отказа (correlated failure modes).

Уровни безопасности ролей:

• Один приватный ключ (EOA), без задержек и мультисиг-защиты: 0
• Мультисиг без честного большинства подписантов: 1
• Мультисиг с честным большинством, без timelock: 2
• Мультисиг с timelock менее 48 часов: 3
• Мультисиг с timelock не менее 48 часов: 4
• DAO-управление ончейн + timelock: 5

Под слабой конфигурацией безопасности (weak security configuration) далее понимается любой держатель роли уровня 0 или 1.

Эта классификация должна использоваться при определении:

• лимитов экспозиции;
• требований к мониторингу;
• необходимых мер по устранению рисков.

3a. Карта ролей ERC-20 (ERC20 Role Mapping)

Эмитент обязан раскрыть и задокументировать все привилегированные роли контракта.

К ним относятся:

• owner/admin;
• default admin;
• minter;
• burner;
• pauser;
• blacklister;
• bridge/adaptor roles;
• любые иные специальные роли протокола.

Для каждой роли необходимо предоставить:

• адрес держателя;
• тип держателя;
• модель безопасности;
• административную иерархию назначения и отзыва ролей.

Концентрация ролей должна быть отдельно оценена.

3b. Карта вспомогательных контрактов (Periphery Role Mapping)

К вспомогательным относятся любые контракты, которые:

• владеют ролями токена;
• способны влиять на эмиссию;
• способны влиять на балансы пользователей;
• способны изменять ключевую функциональность токена.

Примеры:

• bridge adapters;
• minters;
• treasury controllers;
• fee receivers;
• redemption contracts;
• staking wrappers;
• другие привилегированные модули.

Эмитент должен:

• раскрыть все такие контракты;
• предоставить исходный код;
• раскрыть их административную структуру;
• подтвердить, что они не могут обновляться под более слабым контролем, чем сам токен.

3c. Логика эмиссии и сжигания (Minting and Burning Logic)

Актив должен обеспечивать высокую целостность предложения токенов.

Эмитент обязан раскрыть:

• кто может выпускать токены;
• кто может их сжигать;
• при каких условиях это происходит;
• существуют ли лимиты и ограничения.

Технические требования:

• Должны быть определены точные функции mint и burn.
• Необходимо раскрыть все авторизованные адреса.
• Эмиссия должна иметь жёсткие лимиты или периодические ограничения.
• Адрес, увеличивающий лимит эмиссии, должен отличаться от адреса, который этот лимит использует.
• Необходимо оценить максимальный объём возможной эмиссии в USD и сравнить его с потенциальной залоговой экспозицией Aave.
• Привилегированный адрес не должен иметь возможность сжигать токены с произвольных пользовательских кошельков.
• События mint и burn должны логироваться через события (events).

Особенно проблемными считаются случаи, когда:

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

Такие ситуации обычно требуют устранения либо серьёзно ограничивают рекомендации по листингу.

3d. Возможности паузы и чёрного списка (Pause and Blacklist Capability)

Механизмы паузы и блокировки адресов должны быть раскрыты, поскольку они напрямую влияют на ликвидации и вывод средств в Aave.

Требования:

• Должен быть определён владелец права паузы (pause/freeze).
• Должен быть определён владелец права чёрного списка (blacklist).
• Необходимо раскрыть адреса держателей этих полномочий и их модель безопасности.
• Blacklist-механизм не должен иметь возможности незаметно блокировать ликвидации Aave без ведома DAO.

Хотя подобные механизмы могут быть необходимы для некоторых активов, их влияние на работу Aave должно быть полностью понятно до листинга или расширения параметров.

3e. Обновляемость контрактов (Upgradeability)

Актив и его критически важные вспомогательные контракты должны иметь понятную и безопасную модель обновления.

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

Технические требования:

• Необходимо определить тип прокси:
• Transparent Proxy;
• UUPS;
• Beacon;
• либо неизменяемый контракт (Immutable).
• Должен быть определён Proxy Admin или иной орган обновления.
• Контроль обновления не должен находиться у адреса со слабой конфигурацией безопасности.
• Proxy Admin должен представлять собой мультисиг, timelock или DAO-механизм с проверенным исходным кодом и достаточными экономическими гарантиями.
• Задержка timelock должна быть раскрыта.
• История обновлений не должна содержать подозрительных или необъяснённых изменений.

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

4. Механизм обменного курса и доходности (Exchange Rate and Yield Mechanism)

Этот раздел применяется к:

• доходным активам (yield-bearing assets);
• обёрткам (wrappers);
• LST (Liquid Staking Tokens);
• LRT (Liquid Restaking Tokens);
• токенам хранилищ (vault tokens);
• аналогичным инструментам.

Технические требования

• Функция расчёта обменного курса (exchange rate) должна быть определена и задокументирована.
• В нормальных условиях обменный курс должен быть монотонно неубывающим, если только снижение стоимости не предусмотрено самой моделью актива (например, через слэшинг или отрицательную доходность).
• Курс не должен поддаваться манипуляции в рамках одной транзакции через:
• пожертвования (donations);
• flash loans;
• особенности бухгалтерского учёта.
• Размещаемый токен не должен использовать ребейзинг.
• Последствия слэшинга или отрицательного ребейза должны быть полностью понятны и отражены в параметрах риска.
• Процедура вывода базового актива должна быть прозрачной и пригодной для ликвидаций.
• Если требуется CAPO, для него должен быть установлен обоснованный лимит роста относительно ожидаемой доходности.
• Необходимо задокументировать точность расчётов и правила округления.

Что считается проблемой

Обычно требуют исправления либо серьёзно ограничивают листинг:

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

Для таких активов, как stETH, weETH, rsETH, ezETH и других LST/LRT, этот раздел фактически проверяет:

Насколько безопасно и предсказуемо растёт exchange rate и сможет ли Aave корректно ликвидировать позиции в стрессовой ситуации?

5. Архитектура токена (Token Architecture)

Актив должен иметь архитектуру, совместимую с интеграциями Aave и не содержать скрытых предположений относительно:

• предложения токенов;
• переводов;
• контроля доступа.

Технические требования

• Должна быть полностью понятна модель предложения:
• фиксированная эмиссия;
• инфляционная модель;
• эмиссия под контролем эмитента.
• Ограничения на переводы должны быть раскрыты и совместимы с принципами DeFi-композируемости.
• Контроль доступа не должен основываться на tx.origin.
• Контракт не должен позволять выполнять delegatecall в произвольные внешние контракты.
• Все привилегированные функции должны быть явно задокументированы и защищены системой прав доступа.
• Не должно существовать нескольких независимых точек выпуска одного и того же предложения токенов, включая:если между ними отсутствует прозрачный механизм учёта общего предложения.
• дублирующиеся деплойменты;
• старые версии токенов;
• миграционные контракты,

6. Риски мостов и кроссчейн-инфраструктуры (Bridge and Cross-Chain Risk)

Для активов, чья целостность предложения зависит от мостов, вводятся дополнительные требования.

Технические требования

Необходимо определить и задокументировать:

• исходную сеть (origin chain);
• каноническое предложение токена;
• представление токена в целевой сети;
• используемый мост или систему сообщений;
• конфигурацию валидаторов, аттестаторов, оракулов или DVN;
• лимиты скорости переводов (rate limits);
• механизмы эскроу;
• административный контроль и обновление моста.

Важный принцип

Проверка не должна ограничиваться только целевой сетью.

Если канонический токен в исходной сети:

• обновляемый (upgradeable);
• имеет функцию эмиссии (mintable);
• управляется слабыми механизмами доступа,

то эта слабость распространяется на всю кроссчейн-модель предложения независимо от качества самого моста.

Что считается серьёзным риском?

Особое внимание должно уделяться случаям, когда присутствуют:

• мосты со слабой моделью безопасности;
• отсутствие надёжной верификации;
• неограниченная эмиссия через мосты;
• слабый контроль Bridge Admin.

Такие риски должны напрямую отражаться в рекомендациях по:

• листингу;
• лимитам экспозиции;
• мониторингу.

7. Аудиты и история безопасности (Audit and Security History)

Актив должен иметь актуальную и релевантную историю проверок безопасности, охватывающую как сам токен, так и критические зависимости.

Технические требования

• Текущая развёрнутая версия должна быть проверена авторитетным аудитором.
• Не должно оставаться неустранённых замечаний уровня Critical или High.
• Дата аудита должна быть достаточно свежей относительно последних существенных изменений кода.
• Должна существовать bug bounty программа, соответствующая предполагаемому TVL актива.
• Все прошлые инциденты должны быть задокументированы вместе с:
• post-mortem отчётом;
• описанием исправлений.
• Развёрнутый код должен совпадать с последней аудированной версией по соответствующему commit hash.
• Эмитент должен иметь официальный канал коммуникации и обязаться заранее уведомлять команду Aave о существенных изменениях.

Что считается проблемой?

Обычно требуют исправления либо существенно ограничивают листинг:

• отсутствие аудита;
• наличие открытых Critical или High замечаний;
• прошлый эксплойт без документированного исправления.

Интересно, что если собрать разделы 1–7 вместе, то получится почти полный чек-лист для оценки любого RWA, стейблкоина, LST/LRT или мостового актива перед листингом в Aave: ERC20 → Oracle → Access Control → Mint/Burn → Yield Logic → Architecture → Bridges → Security History. Именно на этих пунктах сегодня чаще всего проваливаются новые активы.

8. Зависимости и композируемость (Dependencies and Composability)

Внешние зависимости должны быть задокументированы, поскольку они могут негативно повлиять на актив, даже если сам токен реализован корректно.

К таким зависимостям относятся:

• стейкинг-протоколы;
• хранилища (vaults);
• мосты;
• кастодианы;
• оракульные системы;
• валидаторы;
• операторы инфраструктуры;
• слои рестейкинга;
• механизмы погашения (redemption infrastructure).

Технические требования

• Все внешние зависимости должны быть идентифицированы.
• Каждая зависимость должна иметь собственную историю аудитов и эксплуатации в продакшене.
• Управление зависимостью не должно иметь возможности незаметно для ончейна нарушить работу актива.
• Очереди вывода средств и сроки вывода должны быть совместимы с предположениями Aave относительно ликвидаций.
• Необходимо раскрыть концентрацию среди:
• валидаторов;
• операторов;
• кастодианов.
• Там, где это применимо, должны быть количественно оценены сценарии:
• слэшинга;
• неплатёжеспособности (insolvency).

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

Ожидания от эмитента (Issuer Expectations)

Данный фреймворк охватывает только техническую сторону пригодности актива к листингу.

Предполагается, что в будущем он будет дополнен отдельным нетехническим фреймворком, который будет оценивать:

• юридическую структуру эмитента;
• раскрытие информации о компании;
• регуляторный статус;
• операционные процессы;
• юридическую природу прав на базовый актив;
• иные факторы, важные для DAO при принятии решения о листинге.

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

Если часть информации является конфиденциальной, она может быть раскрыта приватно соответствующему риск-провайдеру или сервис-провайдеру.

Однако публичное предложение по управлению всё равно должно содержать:

• краткое описание результатов проверки;
• итоговую оценку;
• описание остаточных рисков,

чтобы DAO могла принимать осознанные решения.

Интеграция в процесс управления (Governance Process Integration)

Фреймворк предлагается встроить в процесс листинга и расширения активов следующим образом.

1. Предварительная проверка (Pre-screening)

Подтверждаются:

• классификация AACF/AAcA;
• верификация контракта;
• наличие аналогичных листингов в Aave;
• базовая пригодность актива.

2. Технический обзор (Technical Review)

Проводится оценка актива по всем разделам фреймворка и выявляются существенные технические риски.

3. Координация с риск-провайдерами

Технические выводы сопоставляются с:

• параметрами рыночного риска;
• лимитами;
• конфигурацией оракулов;
• условиями листинга.

4. Публикация предложения

В governance-предложение включается стандартизированная таблица результатов проверки.

5. Контроль исправлений (Remediation Tracking)

Документируются:

• необходимые исправления;
• являются ли они обязательным условием листинга;
• либо могут быть выполнены уже после листинга.

6. Регулярное обновление оценки (Ongoing Refresh)

Проверка должна проводиться:

• ежегодно для всех активных активов;
• немедленно при существенных изменениях.

Под существенными изменениями понимаются:

• обновление контрактов;
• запуск в новых сетях;
• новые или изменённые мостовые маршруты;
• изменение держателей привилегированных ролей;
• изменение модели безопасности;
• изменение лимитов эмиссии;
• изменение критических зависимостей;
• инциденты безопасности актива или его ключевых компонентов.

Сервис-провайдеры и Aave Labs должны сообщать о таких изменениях DAO по мере их обнаружения.

Эмитенты обязаны уведомлять о них заранее в рамках своих постоянных обязательств.

Главная идея

Фреймворк не должен создавать лишние препятствия для простых и хорошо контролируемых активов.

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

Обращение с выявленными проблемами (Treatment of Findings)

Результаты проверки должны напрямую превращаться в управленческие и риск-менеджмент решения.

В зависимости от серьёзности проблемы последствия могут включать:

• снижение Supply Cap;
• снижение Borrow Cap;
• уменьшение LTV;
• запрет использования актива в качестве залога;
• дополнительный мониторинг;
• обязательные исправления со стороны эмитента;
• периодические повторные проверки;
• рекомендацию отложить листинг или расширение параметров.

Формальные технические отчёты могут использовать:

• качественные рейтинги;
• уровни серьёзности (severity labels);
• другие формы оценки,

чтобы передавать выводы риск-провайдерам и участникам управления.

Однако такие оценки являются частью конкретного отчёта и не считаются универсальными шкалами, установленными данным ARFC.

Если DAO всё же принимает риск?

Если DAO решает листить актив несмотря на наличие существенных нерешённых проблем, в предложении должно быть прямо указано:

• какой остаточный риск остаётся;
• почему DAO считает этот риск приемлемым.

Если посмотреть на весь документ целиком, то это фактически попытка Aave превратить листинг активов в стандартизированный due diligence-фреймворк, очень похожий на то, как банки или институциональные кастодианы оценивают новые финансовые инструменты. Особенно это заметно по разделам про:

• контроль эмиссии;
• апгрейды;
• мосты;
• оракулы;
• оффчейн-зависимости;
• раскрытие информации об эмитенте.

Для RWA, стейблкоинов, LST/LRT и кроссчейн-активов такой подход может стать новым де-факто стандартом листинга далеко за пределами самого Aave.

До!