Ir para o conteúdo
Financial Context Wiki

Como funciona um timelock de governança?

Um timelock de governança transforma uma ação aprovada em uma operação publicamente observável que precisa aguardar antes da execução. Entenda como funcionam IDs, funções, atrasos, expiração, cancelamento e janelas de saída.

Atualizado

Somente para fins educacionais; não constitui recomendação nem aconselhamento de investimento. Investir pode causar perdas.

Resposta direta

Um timelock de governança é um controlador de execução, não outra votação. Depois que a governança autoriza um payload, um proponente autorizado agenda a operação exata. O contrato registra quando ela pode se tornar executável e rejeita a execução antes desse momento. Esse atraso torna uma atualização, mudança de parâmetro, transferência de tesouraria ou alteração de função pendente observável antes que entre em vigor.

O atraso anunciado é apenas uma parte do controle. Analise o ID da operação, o primeiro momento de execução, qualquer regra de expiração, a operação predecessora, o proponente, o executor, o cancelador, o administrador e todos os outros caminhos capazes de controlar o contrato-alvo. Um timelock de 48-hour não oferece uma janela de saída de 48-hour se a operação for agendada tarde, o monitoramento se atrasar, os saques demorarem mais ou outra chave privilegiada puder realizar a mesma alteração imediatamente.

Um timelock não decide se uma ação é legítima ou segura. Ele oferece tempo para pessoas e monitores automatizados decodificarem as chamadas, simularem seus efeitos, cancelarem ou pausarem quando autorizados, comunicarem a mudança e encerrarem posições quando houver uma rota real de saída.

Como funciona

  1. A autoridade é atribuída ao timelock. O timelock deve ser proprietário do contrato-alvo ou ter a função relevante nele. Se um governor não tiver autoridade sobre o alvo, a aprovação de uma proposta não muda nada; se um administrador separado mantiver autoridade paralela, esse caminho poderá contornar o atraso.
  2. Um proponente agenda uma operação exata. No TimelockController da OpenZeppelin, o ID de uma operação individual é o hash de target, value, data, predecessor e salt; as operações em lote calculam o hash dos arrays correspondentes, além da mesma dependência e do mesmo salt. Alterar qualquer campo cria um ID de operação diferente. O salt diferencia ações que, de outra forma, seriam idênticas.
  3. O atraso mínimo começa no agendamento. Uma votação bem-sucedida não necessariamente inicia o timelock. O agendamento registra um timestamp de prontidão usando um atraso que deve ser pelo menos igual ao mínimo atual do contrato. As operações da OpenZeppelin passam de Unset para Waiting, depois para Ready e, por fim, para Done após uma execução bem-sucedida.
  4. Dependências e permissões são verificadas na execução. Uma operação predecessora já deve estar em Done. Quem faz a chamada deve satisfazer a regra do executor, e a chamada ao alvo precisa ser bem-sucedida. Um executor não pode alterar o payload agendado. Conceder a função de executor a address(0) torna a execução permissionless após o vencimento do atraso, o que melhora a disponibilidade, mas permite que qualquer conta escolha o momento exato da execução assim que a operação se tornar elegível.
  5. O cancelamento devolve uma operação pendente ao estado inicial. Nos contratos atuais da OpenZeppelin, uma conta com CANCELLER_ROLE pode cancelar uma operação enquanto ela estiver pendente, inclusive quando estiver pronta, mas ainda não tiver sido executada. Um novo agendamento inicia um novo temporizador. A configuração das funções é importante: versões anteriores e outros timelocks podem atribuir o cancelamento ao proponente ou ao administrador.
  6. A expiração depende da implementação. O TimelockController da OpenZeppelin não tem expiração por período de carência integrada; uma operação pronta permanece pronta até ser executada ou cancelada. Já o Timelock da Compound v2 exige execução até, no máximo, eta + GRACE_PERIOD, e seu código-fonte define GRACE_PERIOD como 14 days. O Governor Bravo classifica uma proposta agendada como expirada depois desse limite.
  7. A administração também deve respeitar o atraso. A OpenZeppelin permite updateDelay somente por meio de uma chamada do timelock para ele próprio. Da mesma forma, uma implantação autoadministrada obriga as mudanças de função a passarem por operações agendadas. Um administrador externo temporário usado durante a configuração deve renunciar à função quando ela terminar; caso contrário, continuará sendo um caminho de confiança separado.

Para cada ação agendada, reconstrua um registro de controle a partir do estado e dos eventos do contrato: ID da blockchain, endereços do timelock e do alvo, ID da operação, payload decodificado, proponente, transação e timestamp de agendamento, atraso mínimo, momento de prontidão, expiração se houver, predecessora, política do executor, autoridade de cancelamento e status final da transação. Não deduza esses campos apenas a partir de um site de governança.

Exemplo prático

Suponha que uma proposta reduza o limite de liquidação de um mercado de empréstimos de 75% para 60%. A votação termina em Monday 12:00 UTC, mas um proponente só agenda a operação em Tuesday 18:00 UTC. O atraso agendado é de 48 hours, portanto o primeiro momento de execução é Thursday 18:00 UTC, e não Wednesday 12:00 UTC.

A operação contém o contrato de gestão de risco como target, value igual a zero em tokens nativos, os data codificados da mudança de parâmetro, nenhuma operação predecessora e um salt divulgado. O recálculo do hash a partir desses campos deve corresponder ao ID da operação emitido. Um endereço de mercado, limite ou salt diferente representa outra operação, mesmo que a descrição na interface pareça igual.

Assim, os usuários têm 48 hours a partir do agendamento, mas o tempo de saída utilizável é menor. Se o alerta chegar 6 hours depois do agendamento e uma fila de retirada de staking ou de saque levar 24 hours, restarão apenas 18 hours de margem:

usable response time = ready time - detection time - exit settlement time

Se uma multisig de emergência puder pausar os saques imediatamente, ela poderá reduzir perdas durante um incidente, mas também impossibilitar a saída antes da mudança agendada. Analise essa autoridade separadamente. Após a execução, verifique o armazenamento real do contrato-alvo e os eventos emitidos; uma transação de execução do timelock pode ser bem-sucedida mesmo que o resultado econômico esperado ainda tenha sido mal interpretado.

Riscos e controles

  • Autoridade que contorna o atraso. Liste proprietários, administradores de proxies, funções de controle de acesso, beacons de atualização, conselhos de emergência, módulos e executores entre blockchains. O caminho privilegiado mais curto determina o atraso efetivo.
  • Substituição do payload ou decodificação inadequada. Recalcule o ID da operação a partir dos campos brutos, identifique as implementações dos proxies, decodifique cada selector e argumento e simule o lote completo. O texto legível da proposta não é o payload executável.
  • Aviso insuficiente. Gere alertas a partir dos eventos on-chain de agendamento e cancelamento, não apenas de publicações em fóruns. Meça o aviso desde a confirmação do agendamento até o primeiro bloco ou timestamp executável e subtraia o tempo de detecção e de liquidação da saída.
  • Falha no cancelamento. Confirme quais contas podem cancelar, se estão operacionais, qual threshold exigem e se o cancelamento continua possível depois que a operação fica pronta. Ensaie a transação antes de um incidente.
  • Falha do executor ou manipulação do momento. Executores restritos podem ficar indisponíveis ou atrasar a execução intencionalmente. A execução aberta melhora a disponibilidade, mas permite que terceiros executem imediatamente no vencimento do atraso; portanto, preços relacionados, atualizações de oráculos e posições dos usuários devem estar seguros nesse limite.
  • Ações agendadas obsoletas. Onde não há expiração, operações antigas que estão prontas podem continuar executáveis indefinidamente. Monitore-as e cancele explicitamente as operações abandonadas. Onde houver um período de carência, monitore seu fim exato e exija um novo ciclo de governança após a expiração.
  • Risco de dependência e de lote. Verifique o ID da operação predecessora e a ordem do lote atômico. Uma única chamada que reverta pode bloquear um lote atômico; uma dependência incorreta pode travar permanentemente uma operação que, de outra forma, seria válida.
  • Administração insegura. Submeta as reduções de atraso, concessões de funções e substituição do timelock ao próprio timelock. Remova os administradores da implantação, preserve pelo menos um proponente e um executor viáveis e evite uma configuração que bloqueie o controle permanentemente.
  • Ausência de uma saída viável. Compare o atraso com filas de saque, finalidade de bridges, liquidez do mercado, poderes de pausa e congestionamento. Um atraso publicado não protege os usuários quando os ativos não podem sair antes da execução.

O padrão operacional é uma linha do tempo respaldada por evidências, não uma contagem regressiva exibida na tela. Arquive o evento de agendamento, as chamadas decodificadas, o resultado da simulação, os detentores das funções, o plano de cancelamento, os momentos de execução mais cedo e mais tarde, os canais de comunicação e o diff de estado após a execução.

Equívocos comuns

  • “O atraso começa quando a votação termina.” Normalmente, ele começa quando a ação aprovada é agendada, a menos que a implementação implantada vincule explicitamente esses momentos.
  • “Qualquer pessoa pode executar, então qualquer pessoa pode alterar a proposta.” Um executor aberto só pode acionar um payload já agendado cujo ID da operação e cujas condições correspondam.
  • “Pronta significa que a ação deve ser executada imediatamente.” Pronta significa elegível. A execução ainda exige uma transação, permissões, dependências satisfeitas e uma chamada bem-sucedida ao alvo.
  • “Todo timelock tem uma janela de execução.” A expiração varia conforme a implementação. A Compound v2 usa um período de carência; o TimelockController da OpenZeppelin não expira operações prontas por padrão.
  • “Um timelock longo elimina o risco de governança.” O atraso só ajuda quando monitoramento, compreensão, cancelamento ou pausa, comunicação e saída são viáveis antes da execução. Administradores paralelos e saques bloqueados podem anular esse benefício.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...