Компания Aave Labs опубликовала документ ARFC, в котором предлагается новая стандартизированная структура листинга (TALF) для Aave V3, V4 и Aave Horizon.
Aave Labs has published an ARFC proposing a new standardized Technical Asset Listing Framework for Aave V3, V4, and Aave Horizon.The framework establishes consistent technical requirements for asset listings, parameter expansions, and ongoing monitoring. pic.twitter.com/OO9hwJK80T— Aave (@aave) May 28, 2026
Она устанавливает единые технические требования к размещению актива, расширению параметров и постоянному мониторингу.
Команда предлагает ввести минимальный порог допуска. Цель — убрать разночтения при оценке, сделать критерии прозрачными и запустить постоянный мониторинг уже добавленных токенов.
Документ не отменяет анализ рыночных рисков, ликвидности, юридическую экспертизу и решения ДАО. Речь идет о базовом техническом фильтре, который должен применяться вместе с выводами риск-провайдеров и других участников экосистемы.
Фреймворк охватывает три сценария:
новые листинги;
активы с существенными изменениями параметров;
периодическую и внеплановую техническую переоценку.
Если токен существует в нескольких сетях, он должен соответствовать требованиям отдельно в каждой из них — с учетом реализации контрактов, мостов, оракулов, прав доступа и зависимостей.
На предварительном этапе актив обязан быть развернут и верифицирован в целевой сети, классифицирован в рамках Aave Asset Classification Framework и не относиться к запрещенным или санкционным категориям.
Если в протоколе уже есть сопоставимый инструмент, его предлагают использовать как ориентир при настройке оракулов, коэффициентов залога (LTV), порогов ликвидации и лимитов.
Жесткие требования к ERC-20
Один из центральных разделов посвящен совместимости токенов со стандартом ERC-20.
Aave Labs предлагает закрепить следующие требования:
предсказуемая работа функций transfer() и transferFrom();
отсутствие механики комиссий при переводе (fee-on-transfer);
запрет на ребейзинг без отдельной обертки;
отказ от хуков ERC777 и обратных вызовов ERC1363;
корректная поддержка десятичных знаков.
Возможность дополнительной эмиссии через flash mint не запрещается, однако ее необходимо раскрывать и подтверждать, что она не нарушает учет внутри протокола.
Контракт также не должен вводить ограничения по спискам разрешенных адресов на хранение и переводы.
Chainlink — базовый источник цен
В качестве основного источника котировок в целевой сети предлагается использовать Chainlink. Любая альтернативная схема должна быть отдельно обоснована.
Для доходных активов допускается использование CAPO, который ограничивает допущения о росте обменного курса или стоимости.
Отсутствие надежного механизма ценообразования, устаревшие данные или высокий инфраструктурный риск оракулов должны напрямую отражаться в рекомендациях по листингу, риск-параметрам и мониторингу.
Контроль эмиссии и привилегированных ролей
Отдельный блок посвящен правам доступа и выпуску токенов.
Aave Labs предлагает раскрывать все привилегированные роли как в контракте ERC-20, так и во внешних модулях, которые могут влиять на предложение, балансы, переводимость или погашение актива.
В перечне:
владелец (owner);
администратор (admin);
эмитент (minter);
сжигатель (burner);
оператор паузы (pauser);
оператор черного списка (blacklister);
роли, связанные с мостами и адаптерами.
Для этих ролей вводится шкала безопасности от Level 0 до Level 5. Наименее надежными считаются Level 0–1 — одиночный ключ без задержки исполнения или мультисиг без честного большинства.
В разделе выпуска и сжигания требуется документировать функции эмиссии, список авторизованных адресов, лимиты и временные ограничения. Отдельно оценивается worst-case mint exposure в долларах — относительно потенциальной залоговой экспозиции Aave.
Среди нежелательных сценариев:
неограниченная эмиссия;
возможность одновременно увеличить лимит выпуска и использовать его одним адресом;
произвольное сжигание токенов из пользовательских кошельков.
Риски паузы, черных списков и обновляемых контрактов
Функции паузы и черных списков выделены в отдельную зону риска. Они способны напрямую повлиять на ликвидации и вывод средств. Управление должно понимать, кто контролирует эти полномочия и может ли механизм блокировки адресов сорвать ликвидации в протоколе.
Для обновляемых контрактов потребуется раскрывать тип прокси, администратора обновлений, наличие таймлока и историю апгрейдов. Слабый механизм обновления прямо назван несоответствующим стандарту листинга.
Дополнительные требования для LST и LRT
Для LST, LRT, оберток и токенов хранилищ вводятся дополнительные требования к механике обменного курса.
Предлагается проверять:
возможность манипуляции курсом через донаты, флеш-кредиты или особенности учета;
наличие понятного механизма погашения;
достаточность вторичной ликвидности для ликвидаций.
Актив без прозрачного механизма погашения и достаточной ликвидности может получить существенные ограничения по листингу и риск-параметрам либо отправиться на доработку.
Инициатива продолжает курс, заявленный после инцидента с KelpDAO. В начале мая протокол сообщил о намерении пересмотреть стандарты оценки залога и листинга, расширив фокус с волатильности и ликвидности на кибербезопасность, совместимость и техническую архитектуру.
При этом ARFC не вводит автоматическую систему оценок и не содержит универсального перечня стоп-факторов. Технические отчеты могут включать качественные оценки и маркировку рисков, однако жестких порогов для автоматического отказа в листинге не предусмотрено.
Напомним, в мае лендинг-протокол Aave восстановил параметры обеспечения для wETH в шести сетях.
