Ontem à noite, ao revisar os documentos de segurança do TermMax, percebi que os parâmetros-chave não passam a valer imediatamente após a alteração. As configurações do Vault do TermMax seguem três etapas: Submit → Wait → Accept. Primeiro, o CURATOR envia as mudanças; durante o período de espera, o GUARDIAN pode revisar ou cancelar a solicitação; e o Vault Owner mantém o poder de supervisão. Por padrão, o tempo de espera é de 1 dia, com configuração possível de 1 a 30 dias.
Eu interpretei isso como uma ordem de mudança para uma instituição de transações: o pedido fica lacrado, o controle de risco em serviço faz a revisão e só depois que o tempo termina é que a gravação/armazenamento é permitida. Mudanças na origem do oracle só podem ser enviadas e aceitas pelo DEFAULT_ADMIN_ROLE e são atualizadas separadamente por ativo; quando a fonte principal falhar, é possível alternar imediatamente para a fonte de backup. Esse desenho amplia a janela de observação e também faz com que a distribuição das três categorias de permissões entre nos exames de segurança.
O timelock apenas atrasa a configuração ou a troca de fonte de dados; ele não consegue provar que o preço atual está correto e nem substitui o monitoramento on-chain. Minha ordem de verificação é observar a fila de execução e o tempo restante; depois checar registros de cancelamento e endereços de função/papel; por fim, comparar a divergência entre a fonte principal e a de backup e o status da alternância. Se o GUARDIAN ficar por muito tempo sem revisar e as chaves de administração estiverem concentradas, esperar um dia apenas faz o risco se concretizar um dia mais tarde. A arquitetura fornece um freio; quem está olhando o painel ainda precisa responder pelos registros de execução.@TermMax
#termmax
Eu interpretei isso como uma ordem de mudança para uma instituição de transações: o pedido fica lacrado, o controle de risco em serviço faz a revisão e só depois que o tempo termina é que a gravação/armazenamento é permitida. Mudanças na origem do oracle só podem ser enviadas e aceitas pelo DEFAULT_ADMIN_ROLE e são atualizadas separadamente por ativo; quando a fonte principal falhar, é possível alternar imediatamente para a fonte de backup. Esse desenho amplia a janela de observação e também faz com que a distribuição das três categorias de permissões entre nos exames de segurança.
O timelock apenas atrasa a configuração ou a troca de fonte de dados; ele não consegue provar que o preço atual está correto e nem substitui o monitoramento on-chain. Minha ordem de verificação é observar a fila de execução e o tempo restante; depois checar registros de cancelamento e endereços de função/papel; por fim, comparar a divergência entre a fonte principal e a de backup e o status da alternância. Se o GUARDIAN ficar por muito tempo sem revisar e as chaves de administração estiverem concentradas, esperar um dia apenas faz o risco se concretizar um dia mais tarde. A arquitetura fornece um freio; quem está olhando o painel ainda precisa responder pelos registros de execução.@TermMax
#termmax