Ончейн-запись Aave фиксирует три выдачи RISK_ADMIN_ROLE в ACLManager V3 Ethereum
Ключевые выводы
- •Все три выдачи исходили от адреса Executor управления Aave и были зафиксированы в ACLManager V3 Ethereum.
- •Два получателя от 2 сентября, 0xbe28...7744 и 0x529e...F6c5, не были полностью идентифицированы на момент публикации записи.
- •Выдача от 30 сентября была передана верифицированному контракту RiskSteward и связана с активацией Risk Stewards на Aave V4 через AIP-523.
- •Держатели RISK_ADMIN_ROLE могут изменять ряд параметров риска, включая лимиты, параметры ликвидации и факторы резервов, но не могут приостанавливать или активировать резервы.
- •AIP-523 ограничивает делегированные полномочия через отзывность, жесткие границы параметров и периоды ожидания во всех поддерживаемых развертываниях V4.

Расшифрованная ончейн-запись, опубликованная на форуме управления Aave, документирует три выдачи роли RISK_ADMIN_ROLE, исполненные в контракте ACLManager Aave V3 Ethereum в период со 2 по 30 сентября 2026 года. Согласно записи, все три выдачи исходили от адреса Executor управления протокола, и одна из них напрямую связана с предложением, активирующим Risk Stewards в Aave V4.
Что показывает расшифрованная запись
Пост с расшифровкой ончейн-данных управления (ACLManager RISK_ADMIN_ROLE grants, Sep 2026 — decoded) идентифицирует три отдельных события выдачи, зафиксированных в контракте ACLManager — центральном реестре контроля доступа архитектуры V3. ACLManager — это контракт, через который Aave V3 назначает и управляет административными ролями в протоколе, поэтому записи в нем определяют, кто обладает делегированными полномочиями в отношении параметров риска. В архитектуре управления Aave контракт Executor исполняет одобренные предложения в блокчейне. Все три транзакции исходили от 0x5300A1a15135EA4dc7aD5a167152C01EFc9b192A — Executor управления, согласно расшифрованному посту.
Две выдачи были зафиксированы на блоке 25 891 729 2 сентября 2026 года в адреса 0xbe28...7744 и 0x529e...F6c5. Точные контракты-получатели этих двух адресов были отмечены в первоисточнике как неподтвержденные; согласно ончейн-расшифровке, их роль и назначение не были полностью верифицированы на момент публикации.
Третья выдача, на блоке 26 089 561 30 сентября 2026 года, была направлена верифицированному контракту RiskSteward с развернутым кодом объемом около 20 061 байта. Эта выдача напрямую связана с AIP-523, "Activate Aave Risk Stewards on Aave V4" (предложение управления), которое было исполнено примерно в ту же дату.
Почему RISK_ADMIN_ROLE важна для надзора за протоколом
Роль RISK_ADMIN_ROLE находится ниже уровня полного управления в иерархии контроля доступа Aave. Её держатели могут обновлять настройки фактора резервов, лимиты предложения и заимствования, коэффициенты loan-to-value, пороги ликвидации, бонусы за ликвидацию и конфигурации категорий E-Mode без запуска отдельного голосования по каждому изменению. В совокупности эти параметры определяют, сколько актива может войти в рынок, как обеспечению уделяется внимание при ликвидациях и как группируются активы со скоррелированным ценовым поведением для повышения эффективности заимствований. Держатели RISK_ADMIN_ROLE не могут приостанавливать или возобновлять резервы, а также полностью активировать или деактивировать их; эти действия остаются за ролями с более высокими привилегиями.
Практическое следствие — скорость. Управляющие рисками протокола, действующие под RISK_ADMIN_ROLE, могут реагировать на рыночные условия, изменения ликвидности или аномалии оракулов в течение часов, а не ждать многодневного цикла управления. На практике роль используется часто: согласно посмертному разбору инцидента rsETH от апреля 2026 года, Risk Stewards Aave V3 уже исполнили около 295 отдельных изменений параметров по резервам V3.
AIP-523 расширяет архитектуру на Aave V4
AIP-523 расширяет эту модель на Aave V4 на Ethereum, Avalanche и Base. Предложение предоставляет ограниченные, отзывные полномочия RISK_ADMIN_ROLE, сдерживаемые жесткими лимитами параметров, а не только репутацией получателя, а фреймворк Risk Stewards Aave V4 был разработан для закрепления этих ограничений на уровне блокчейна.
В рамках фреймворка V4 лимиты предложения и заимствования могут быть увеличены не более чем на 50% за одно обновление Risk Steward, согласно обсуждению AIP-523 на форуме управления.
Периоды ожидания добавляют второй слой ограничений. Изменения процентных ставок и лимитов хабов требуют 36-часового ожидания; параметры споков и обеспечения — 72 часов; обновления ценовых лимитов оракулов попадают в диапазон 48–72 часов. Эти интервалы призваны предотвратить быстрые изменения, которые могут быть использованы или накопиться в значительные структурные сдвиги без ведома сообщества.
Вопросы управления и открытые вопросы
Вопрос дизайна, поставленный сентябрьскими выдачами, состоит не в том, полезна ли роль — она явно полезна, — а в том, сохраняет ли сообщество управления содержательную возможность проверки после введения роли. Участник форума MconnectDAO задал прямой вопрос: "как Aave обеспечит, чтобы обсуждение в сообществе оставалось содержательным, а не только формальным процессом одобрения?" Проблема носит структурный характер: голосование, предоставляющее открытую роль контракту, фактически предварительно авторизует все будущие изменения параметров в рамках закодированных границ этого контракта.
Участник Roch33 описал базовый уровень прозрачности, который частично решил бы эту проблему, предложив логировать каждое изменение параметра с предыдущим и новым значением, применяемым одобренным управлением лимитом, использованным источником данных и обоснованием обновления. Такой уровень раскрытия в блокчейне и на форуме позволил бы сообществу проверять, являются ли действия Risk Steward защитными реакциями на рыночные данные или постепенным расширением границ.
Два получателя от 2 сентября, 0xbe28...7744 и 0x529e...F6c5, остаются открытым вопросом. Пост с ончейн-расшифровкой отметил их идентичность как не полностью подтвержденную, и существующие публикации не разрешили, какие контракты или сервис-провайдеры представляют эти адреса. Пока это не установлено, сообщество не может в полной мере оценить масштаб делегированных полномочий, связанных с событием выдачи от 2 сентября на блоке 25 891 729. Наиболее конкретные последующие шаги — подтверждение этих получателей, раскрытие последующих изменений параметров относительно одобренных лимитов и любые последующие действия управления по этим выдачам.
Для выдачи RiskSteward от 30 сентября, связанной с AIP-523, возможность отзыва — ключевая черта дизайна. Executor управления, выдавший роль, может отозвать её последующим предложением, а закодированные в самом контракте лимиты параметров служат защитным механизмом против дрейфа параметров даже без отзыва роли. Сочетание отзывности и встроенных лимитов призвано удерживать делегированные полномочия по риску в подчинении у управления. Обзор архитектуры V4 за 2026 год от Aave подробно описывает, как протокол обрабатывает межсетевую делегацию рисков в рамках нового фреймворка.