--- title: "Ataque de governança" description: "Um ataque de governança obtém poder de voto ou execução suficiente para aprovar mudanças prejudiciais pela via de governança autorizada." 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. # Ataque de governança > Somente para fins educacionais; não constitui recomendação nem aconselhamento de investimento. Investir pode causar perdas. ## Resposta direta Um ataque de governança obtém poder suficiente para votar, propor, cancelar ou executar e faz o protocolo realizar uma ação prejudicial por sua via de governança autorizada. As chamadas podem passar por todas as verificações dos contratos inteligentes. A falha está em permitir que o controle seja adquirido de forma barata, rápida ou sem responsabilização em relação ao valor submetido a ele. O poder de voto pode vir de tokens próprios, votos delegados, tokens emprestados, eleitores subornados, chaves comprometidas ou funções privilegiadas do governador e do timelock. Pontos de controle históricos impedem que o mesmo saldo vote outra vez após uma transferência e podem frustrar empréstimos feitos depois do snapshot. Eles não impedem votos obtidos antes dele, delegação concentrada, regras fracas de quórum ou um executor comprometido. Nem toda proposta impopular é um ataque: a governança existe para mudar regras. A questão de segurança é saber se alguém obteve controle desproporcional ou temporário, ocultou ou deturpou o efeito executável ou ultrapassou um limite de autoridade declarado publicamente. Devem ser examinadas as chamadas reais, o caminho mais barato para o poder decisivo, o tempo de reação e o valor ou controle máximo alcançável após a execução. ## Como funciona 1. Mapeie a autoridade desde o ativo de votação, passando por delegações e checkpoints, até o governador, timelock, administrador de proxy, tesouraria, funções de emergência e contratos de destino. A interface de governança não é o grafo de permissões. 2. Fixe a rede, os endereços, versões de implementação, modo do relógio, snapshot, limiar de proposta, cálculo do quórum, regra de contagem, atraso e período de votação, atraso de fila, validade, direitos de cancelamento e funções de execução. 3. Reconstrua o poder de voto no snapshot exato com leituras históricas como `getPastVotes`. Agrupe endereços controlados ou coordenados pelo mesmo agente e separe o saldo de tokens do peso delegado. 4. Decodifique cada ação: `targets`, `values`, `calldatas` e `descriptionHash`. Resolva proxies e seletores, inspecione chamadas em lote e compare a carga executável com a descrição legível. 5. Reproduza em um fork a criação, votação, entrada na fila e execução. Compare antes e depois saldos, propriedade, funções, permissões, implementações, configurações de oráculo, parâmetros de garantia e qualquer função recém-acessível. 6. Calcule o caminho de controle mais barato entre compras à vista, mercados de crédito, liquidez flash, empréstimos de balcão, delegação, incentivos de voto, hedge com derivativos, comprometimento de chaves e captura de funções privilegiadas. Inclua taxas, slippage, garantia, perdas no desfazimento e tempo de imobilização do capital. 7. Teste a resposta. Confirme quem pode cancelar ou pausar, quais evidências são necessárias, se a ação cabe no atraso, onde os usuários obtêm avisos oficiais e como a governança recomeça sem deixar uma chave de emergência ilimitada. Um governador de tokens típico passa por proposta, atraso, snapshot, votação, aprovação ou rejeição, fila, timelock e execução. As regras exatas dependem da implementação. Com checkpoints no estilo ERC-5805, é possível consultar o peso delegado em um momento passado; o relógio pode usar blocos ou timestamps. É preciso usar o relógio e a configuração implantados, sem presumir que a duração exibida ou o saldo de tokens sejam autoritativos. O timelock cria um prazo mínimo de aviso, mas não avalia a intenção nem torna a carga segura. Suas funções de proponente, executor, cancelador e administrador também são críticas. Se um administrador externo puder contornar o atraso, o timelock não é a autoridade final. Se ninguém puder cancelar uma ação maliciosa na fila, detectá-la não impede sua execução. ## Exemplos calculados - **Captura com baixa participação.** Um protocolo tem `100 million` tokens totais e `40 million` em circulação. Uma proposta exige `2 million` votos participantes, mais votos favoráveis que contrários e timelock de `6-hour`. Um agente compra `1.2 million` votos e recebe `1 million` delegados. Há `0.8 million` votos contrários; assim, seus `2.2 million` votos favoráveis aprovam uma chamada capaz de transferir `15 million USDC` da tesouraria. Ele controla `2.2 / 100 = 2.2%` da oferta total e `2.2 / 40 = 5.5%` da oferta circulante, mas `2.2 / 3.0 = 73.3%` dos votos lançados. Os parâmetros decisivos são participação, delegação, quórum, autoridade da carga e atraso, não o slogan `51%`. - **Limite do snapshot.** Se o peso for lido do saldo atual e a execução for imediata, uma transação pode tomar tokens, votar, executar e devolver. Ler o peso histórico imutável de um momento anterior à votação bloqueia esse caminho na mesma transação. Ainda permite capital emprestado ou delegado antes do snapshot; por isso, o atraso da proposta e a janela observável de aquisição continuam fazendo parte da defesa. - **Beanstalk em 17 de abril de 2022.** A Beanstalk Farms informou que um atacante usou um flash loan para explorar a governança do protocolo e subtraiu aproximadamente `$77 million` em ativos de usuários que não eram Beanstalk. O caso mostra que a liquidez flash financia o ataque, enquanto a fraqueza decisiva é permitir que poder econômico temporário alcance permissões valiosas de execução. ## Riscos e controles - **Poder efetivo concentrado.** Meça delegados e entidades coordenadas, não apenas endereços. Publique a fatia dos principais delegados, a distribuição da participação e a dependência de fundações, custodiantes, formadores de mercado e representantes. - **Regras fracas de proposta e quórum.** Compare limiares com poder ativo, oferta emprestável e exposição da tesouraria. Separe os requisitos de parâmetros rotineiros e atualizações ou transferências de alto impacto. - **Snapshots inseguros.** Use checkpoints históricos imutáveis e um relógio comum ao token e ao governador. Deixe atraso suficiente antes do snapshot para tornar visíveis acúmulos ou delegações anormais. - **Voto tardio ou surpresa.** Considere uma extensão mínima quando o quórum chegar perto do encerramento e monitore grandes mudanças de delegação durante todo o ciclo. - **Cargas opacas.** Publique chamadas decodificadas e simulações independentes. Separe ações arriscadas não relacionadas para que uma ação normal não esconda mudança de administrador ou transferência. - **Atraso de execução insuficiente.** Ajuste o timelock ao impacto e publique as operações na fila. O atraso deve comportar revisão, alertas, cancelamento ou pausa e uma saída confiável para o usuário. - **Funções de emergência excessivas.** Limite guardiões por função, valor, duração e padrão de revisão. Divulgue membros, limiares, rotação, evidências exigidas e processos de remoção e retomada. - **Caminhos de atualização não revisados.** Acompanhe administradores de proxy, beacons, inicializadores, implantações metamórficas e contratos atualizáveis depois de receber autoridade. - **Risco de execução entre redes.** Autentique governador e mensagem de origem, impeça replay, limite funções de destino, adicione atraso local a chamadas críticas e defina o comportamento durante falha ou suspensão da ponte. - **Monitoramento insuficiente.** Alerte sobre criação de propostas, concentração de votos, mudanças de quórum, fila e cancelamento, alterações de estado decodificadas, atualizações, concessões de funções, permissões e saídas da tesouraria. - **Resposta a incidentes falha.** Simule propostas maliciosas, perda de signatários, comprometimento do front-end, indisponibilidade da ponte e pausas indevidas. Registre quem decide, comunica, assina, verifica e restaura com segurança. - **Valor em risco ilimitado.** Limite transferências individuais e acumuladas, escopo de atualização, emissão, mudanças de garantia e permissões. Um voto aprovado não deve conceder automaticamente autoridade ilimitada. O resultado deve ser um registro de controle reproduzível: cada ação privilegiada, seu controlador, votos ou chaves necessários, primeiro horário de execução, caminho de cancelamento, fonte de monitoramento e valor máximo alcançável. Recalcule após atualizações, distribuições de tokens, mudanças de delegação, migrações de pontes ou variações relevantes de liquidez e participação. ## Equívocos comuns - **"O atacante precisa de 51% da oferta total."** A maioria dos sistemas depende de votos delegados ou participantes, quórum e regra de aprovação. O controle decisivo pode custar muito menos que metade da oferta. - **"Snapshots eliminam ataques de governança."** Eles impedem certos reusos de votos ou empréstimos de última hora, não empréstimos prévios, compras, concentração de delegação, suborno ou chaves privilegiadas comprometidas. - **"Um voto aprovado on-chain prova legitimidade."** Ele só prova que as condições do código foram atendidas. Não demonstra que descrição e carga coincidem nem que o resultado é seguro, justo ou compatível com compromissos públicos. - **"Um timelock mais longo é sempre mais seguro."** Só é útil se houver tempo para monitorar, analisar, cancelar ou pausar, comunicar e sair. Atraso excessivo também pode prejudicar manutenção urgente. - **"Adicionar um conselho de segurança resolve o risco."** O conselho pode acelerar a resposta, mas cria outro caminho de controle. Autoridade, responsabilização, remoção e falhas devem entrar no mesmo modelo de ameaças. ## Tópicos relacionados - [Formador de mercado automatizado AMM](/pt-br/crypto/amm/) - [DAO](/pt-br/crypto/dao/) - [Flash loan](/pt-br/crypto/flash-loan/) - [Token de governança](/pt-br/crypto/governance-token/) - [Carteira quente](/pt-br/crypto/hot-wallet/) ## Fontes - [Governance](https://docs.openzeppelin.com/contracts/5.x/api/governance) - OpenZeppelin Documentation (acesso: 2026-08-20) - [ERC-5805: Voting with delegation](https://eips.ethereum.org/EIPS/eip-5805) - Ethereum Improvement Proposals (acesso: 2026-08-20) - [Compound v2 Governance](https://docs.compound.finance/v2/governance/) - Compound Documentation (acesso: 2026-08-20) - [Beanstalk Governance Exploit](https://bean.money/blog/beanstalk-governance-exploit) - Beanstalk Farms (acesso: 2026-08-20) Source: https://wiki.fcontext.com/pt-br/crypto/governance-attack/index.mdx