A Web3 DAO é uma falsa proposição? Análise aprofundada de por que Bonk sofreu um ataque de governança.

Autor: Biteye; Fonte: X, @BiteyeCN

O quê? Um atacante conseguiu drenar um tesouro de US$ 20 milhões de uma DAO com apenas US$ 4 milhões?

Na madrugada de ontem, a BONK DAO sofreu um ataque de governança. O atacante explorou falhas de design como o baixo limite de governança do BONK, mecanismo de maioria simples e a ausência de atraso de execução (Timelock) para transferir ativos do tesouro por meio de uma proposta maliciosa.

Mas, afinal, como deveria ser o processo de governança de uma DAO madura? Por que protocolos como Aave, ENS e Lido reduzem riscos com governança em múltiplas camadas, enquanto a BONK é mais vulnerável a ataques de governança?

Este artigo detalha o processo de governança de DAOs em cinco etapas: Proposta → Discussão na Comunidade → Teste de Temperatura no Snapshot → Votação On-chain → Execução com Timelock

1. Etapa de Proposta (Proposal)

No ecossistema de DAOs, a etapa de proposta é o ponto de partida de todas as ações de governança.

O conteúdo central de uma proposta formal geralmente abrange ajustes de parâmetros do protocolo, listagem de novos ativos, alocação de fundos do tesouro (Treasury), atualizações de contratos, modificações em planos de incentivo e reestruturação das regras de governança.

Para equilibrar a eficiência da governança e evitar propostas irrelevantes, os principais protocolos estabelecem diferentes limites de detenção ou delegação de tokens para os proponentes:

• Aave: Limite alto, exige cerca de 0,5% do poder de voto do AAVE.
• ENS: Propostas executivas exigem 100.000 ENS delegados; propostas sociais, cerca de 10.000 ENS.
• Lido: Exige discussão prévia no fórum e cumprimento de limite mínimo de 1.000 LDO.
• BONK: Limite baixo, apenas 100M Bonk (US$ 425,99), o que também foi a razão do ataque de governança à Bonk.

2. Etapa de Discussão na Comunidade (Governance Forum)

A discussão comunitária é uma etapa de pré-triagem antes da votação formal. A maioria das DAOs maduras exige que as propostas entrem primeiro no fórum oficial de governança, passando por discussão pública para:

• Divulgação do plano e coleta de opiniões: permitir que a comunidade conheça o conteúdo da proposta com antecedência e faça questionamentos.
• Otimização da proposta: ajustar parâmetros e detalhes de execução com base no feedback, melhorando a qualidade da proposta.
• Filtrar propostas de baixa qualidade: evitar que propostas maliciosas ou imaturas sigam diretamente para votação on-chain.

No entanto, nem todas as DAOs têm esta etapa. Por exemplo, a BONK DAO não possui um processo formal de Governance Forum; as propostas BIP são submetidas e votadas diretamente via Solana Realms.

DAOs maduras geralmente formam uma barreira de proteção de governança por meio de múltiplos mecanismos como Governance Forum, Snapshot e Timelock. Já DAOs do tipo Meme, como a BONK, preferem votação direta para aumentar a eficiência das decisões, mas isso também reduz a barreira para ataques.

3. Teste de Temperatura no Snapshot (Votação Off-chain)

Antes da votação on-chain formal, muitas DAOs realizam primeiro uma votação off-chain via Snapshot, como um teste de intenção da comunidade.

Esta etapa é geralmente chamada de: Temperature Check (Teste de Temperatura)

Principais funções:

• Reduzir custos de votação: votações off-chain não exigem pagamento de Gas, permitindo participação de baixo custo para membros da comunidade.
• Validar consenso antecipadamente: observar se a proposta recebe apoio suficiente, evitando que planos imaturos sigam diretamente para execução on-chain.
• Otimizar direção da proposta: com base nos resultados da votação e feedback da comunidade, ajustar detalhes do plano.

Se o teste de temperatura no Snapshot não for aprovado, geralmente significa que a comunidade não atingiu consenso suficiente, e a proposta é interrompida ou devolvida para modificação, não avançando para a votação on-chain formal.

E foi justamente por não ter projetado essa importante camada de segurança (Snapshot) que a BONK DAO foi facilmente invadida pelo "ladrão".

4. Votação On-chain Formal (On-chain Governance)

Após a discussão na comunidade e o teste de temperatura no Snapshot (se o projeto adotar esse processo), a proposta entra na etapa de governança on-chain formal.

Esta etapa é executada pelo framework de governança on-chain, como:

• Contrato Governor (comum no ecossistema Ethereum)
• Aragon (framework de gerenciamento de DAOs)
• Realms (framework de governança da Solana)

Para garantir a seriedade e segurança da votação on-chain, o contrato inteligente verifica rigorosamente dois indicadores principais durante a liquidação.

Quórum mínimo de participação: Como linha vermelha de segurança da governança da DAO, o Quorum define a quantidade total mínima de votos necessária para que uma proposta seja legalmente válida.

Se o total de tokens participantes da votação não atingir o mínimo, mesmo que os votos a favor sejam 100%, a proposta é rejeitada diretamente.

Por exemplo, em um modelo com 100 milhões de tokens no total, se o Quorum for definido como 5%, serão necessários pelo menos 5 milhões de tokens participando da votação. As configurações de Quorum das principais DAOs variam:

• Lido estabeleceu um limite alto de 5% do fornecimento total (cerca de 50 milhões de LDO)
• Aave (cerca de 2% do fornecimento total) e ENS e BONK (1% do fornecimento total) são mais convencionais
• Optimism é mais flexível, ajustando-se dinamicamente entre 3% e 30% dependendo do tipo de proposta.

Condição de aprovação: Após atingir o Quorum (participação mínima), a proposta também precisa satisfazer a proporção de votos a favor necessária para ser aprovada formalmente.

A maioria das DAOs adota, para governança cotidiana, o sistema de maioria simples (Simple Majority), ou seja: votos a favor (YES) > votos contra (NO)

No entanto, para mudanças importantes que envolvem regras centrais do protocolo, como modificar a constituição da ENS, ajustar parâmetros-chave de governança ou atualizar o protocolo subjacente, as DAOs geralmente adotam o sistema de supermaioria (Super Majority).

Exigindo uma proporção maior de votos de apoio, como: 2/3 (aproximadamente 66,7%) ou mais de votos a favor; ou uma proporção ainda maior.

Esse mecanismo evita que poucos grandes detentores de tokens, usando maioria simples, promovam alterações significativas que afetem todo o protocolo.

Outra razão importante para o ataque de governança à BONK são seus parâmetros de governança relativamente frouxos.

O quórum mínimo de participação exige apenas 1% do fornecimento total de BONK em poder de voto para que a votação seja válida. E a condição de aprovação adota o sistema de maioria simples: YES > NO

Isso significa que o atacante não precisa controlar a maioria absoluta do BONK; basta controlar cerca de 1% do fornecimento e garantir que sua proposta obtenha apoio majoritário para forçar a execução da governança.

5. Execução com Atraso de Timelock e Execução On-chain (Execution)

DAOs maduras geralmente não executam a proposta imediatamente após a aprovação da votação; em vez disso, adicionam um mecanismo de Timelock: Aprovação da votação → Espera do Timelock → Execução on-chain.

O Timelock serve para dar à comunidade um tempo de amortecimento, permitindo que os membros possam:

• Verificar o código da proposta;
• Identificar riscos potenciais de ataque;
• Organizar oposição ou tomar medidas de emergência.

Após o período de espera, a proposta é executada automaticamente pelo framework de governança.

Uma razão importante para o ataque de governança à BONK é a ausência de um processo padrão de atraso de execução via Timelock em seu fluxo de governança: aprovação da votação → execução direta.

No evento de ataque de governança BIP #76, o atacante explorou exatamente a falta de mecanismo de atraso de execução no processo de governança da BONK, executando a operação maliciosa rapidamente após a aprovação da proposta.

Considerações Finais

O ataque de governança à BONK revela um problema de longa data no DeFi: Se ninguém participa da governança, uma DAO realmente precisa existir?

Quando a governança comunitária se torna uma mera encenação, a DAO é realmente necessária? Na verdade, a baixa participação na governança torna a estrutura da DAO mais um fardo ineficiente do que uma garantia para o protocolo.

Quando o poder real de governança está concentrado nas mãos de poucos, e a maioria dos usuários são apenas espectadores silenciosos, buscar uma descentralização nominal aumenta os custos de decisão e expõe o protocolo a enormes brechas de segurança.

Talvez devêssemos admitir que nem todos os projetos precisam de uma DAO. Assim como no mundo empresarial maduro, deixar que os tomadores de decisão centrais controlem a direção geral muitas vezes gera maior eficiência executiva e maior capacidade de resistência a riscos. Após o furor da descentralização, precisamos retornar ao essencial: a solidez de um protocolo depende frequentemente de responsabilidades claras e equipes de execução focadas, não de votações populares hipócritas.