Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
A votação Aave V4 concederia poderes de emergência não utilizados
Os eleitores do Aave DAO estão decidindo se devem delegar controles de risco V4 limitados em Ethereum e Avalanche para Risk Stewards, ferramentas que permitem que operadores aprovados façam mudanças restritas sem passar por uma votação de governança completa em cada atualização. A proposta também atribuiria funções de emergência sem demora que o atual software de administração não pode usar.
O Votação instantânea abriu em 3 de setembro às 15h46 UTC e está programado para fechar hoje, 6 de setembro, no mesmo horário. A aprovação não ativaria o sistema por si só. Aave Labs disse que as cargas correspondentes ainda precisariam ser executadas através do Conselho de Segurança V4.
O código também não está sendo apresentado como totalmente auditado. Em seu proposta de governançaAave Labs disse que os contratos do Risk Steward estavam passando por uma auditoria da Certora e que o trabalho estava em fase de finalização.
A tensão central da proposta é entre a autoridade atribuída agora e a funcionalidade disponível posteriormente. Cada Administrador de Risco receberia funções de gerenciamento de risco Hub and Spoke, além de funções de emergência Hub and Spoke. Essas quatro funções não teriam atraso na execução após serem concedidas.
Entretanto, a liberação em consideração não chama nenhum dos seletores de emergência, e o documentação atual do administrador não expõe esses métodos. As permissões de emergência permaneceriam inertes até que uma versão futura adicionasse suporte. Atribuir as funções agora permitiria que a versão posterior respondesse a uma emergência sem esperar por outro ciclo de governação para ter acesso.
O redesenho mais amplo de permissões dividiria os controles do configurador Hub and Spoke de cada instância V4 em cinco categorias granulares: duas funções de controle de sinalizadores, uma função de listagem, uma função de emergência e uma função de gerenciamento de risco. Os seletores fora dessas categorias permaneceriam com funções residuais de administrador de domínio. Os administradores de domínio existentes receberiam as novas funções para que seu alcance atual fosse preservado.
O definições de função propostas limitar a categoria de emergência a ações de segurança unidirecionais. As chamadas de hub podem desativar ou interromper ativos e Spokes. As chamadas faladas podem pausar ou congelar reservas individuais ou todas as reservas. Essas funções não podem reativar, interromper, retomar ou descongelar o mercado afetado. As funções separadas de controle de bandeira, que podem mudar de estado em ambas as direções, não seriam concedidas aos Administradores de Risco.
As atualizações de rotina dos parâmetros funcionariam sob diferentes controles. A proposta estabelece tempos de espera mínimos de 36, 48 ou 72 horas, dependendo do parâmetro, e limita o quanto cada atualização pode movê-lo. Os mesmos limites seriam aplicados ao Ethereum e ao Avalanche e cobririam configurações de taxas de juros, fatores colaterais, configurações de liquidação e limites máximos de oráculos. Eles não restringem os seletores de emergência.
Essa separação explica por que o plano pode combinar uma manutenção limitada mais lenta com autoridade de emergência imediata no papel. Também cria uma questão de responsabilização porque as funções de atraso zero estariam em vigor antes que o administrador pudesse exercê-las. Os participantes do fórum solicitaram justificações públicas, relatórios pós-acção, revisões periódicas e relatórios sobre a frequência e a dimensão das acções dos administradores. Nenhuma dessas medidas é um requisito da proposta atual.
Se o Snapshot for aprovado e o Conselho de Segurança executar as cargas úteis, a mudança imediata seria o acesso sem demora aos controles de parâmetros limitados. Os poderes de emergência unilaterais estariam pré-posicionados para uma futura libertação do administrador, mas ainda não seriam utilizáveis.
