---
title: "Como funciona um timelock de governança?"
description: "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."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Como funciona um timelock de governança?
> 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
- [DAO](/pt-br/crypto/dao/)
- [Ataque de governança](/pt-br/crypto/governance-attack/)
- [Pausa de emergência do protocolo](/pt-br/crypto/protocol-emergency-pause/)
- [Contrato proxy](/pt-br/crypto/proxy-contract/)
- [Timelock](/pt-br/crypto/timelock/)
## Fontes
- [Governance API: TimelockController](https://docs.openzeppelin.com/contracts/5.x/api/governance#TimelockController) - OpenZeppelin Documentation (acessado em: 2026-08-20)
- [Access Control: Delayed operation](https://docs.openzeppelin.com/contracts/5.x/access-control#delayed_operation) - OpenZeppelin Documentation (acessado em: 2026-08-20)
- [Timelock.sol](https://github.com/compound-finance/compound-protocol/blob/master/contracts/Timelock.sol) - Compound Finance (acessado em: 2026-08-20)
- [GovernorBravoDelegate.sol](https://github.com/compound-finance/compound-protocol/blob/master/contracts/Governance/GovernorBravoDelegate.sol) - Compound Finance (acessado em: 2026-08-20)
Source: https://wiki.fcontext.com/pt-br/crypto/governance-timelock-operation/index.mdx