Shadow Governance e Compra de Votos DeFi: Análise On-Chain

Esqueça as discussões públicas nas threads do Discourse: hoje, os hacks de governança no ecossistema DeFi migraram direto para pools de liquidez anônimas e grupos fechados no Telegram. É lá no privado que o destino de bilhões de dólares é selado no intervalo de pouquíssimos blocos.

Tentar mandar um ataque de 51% direto num protocolo de governança comprando tokens nativos no mercado aberto (tipo UNI ou AAVE) é dar tiro no pé do ponto de vista financeiro. O slippage absurdo e as dinâmicas de staking vão mandar o preço do token pra lua instantaneamente. Fica infinitamente mais barato "alugar" o poder de voto alheio apelando para os famigerados Voter Bribes (subornos de governança). Só que quando essa brincadeira sai de plataformas transparentes como Votium ou Hidden Hand e vai para o mercado balcão (OTC) ou contratos inteligentes fechados, entra em cena o Shadow Governance — uma governança paralela capaz de rapar a tesouraria de um projeto ou mudar parâmetros de risco críticos sem que a comunidade perceba nada.

Anatomia da Governança Sombra: Das Curve Wars aos pools anônimos

Essa mecânica de subornos estourou de vez com a chegada da arquitetura veTokenomics (vote-escrowed), criada pela Curve Finance. Ao travar CRV por até 4 anos, você recebe veCRV, que dita o direcionamento das emissões de tokens para as pools de liquidez. Os projetos sacaram rápido: em vez de gastar uma fortuna comprando CRV e travando capital por anos, sai muito mais em conta pagar uma "taxa semanal" direto para os detentores de veCRV votarem na pool que eles querem impulsionar.

Foi assim que nasceram os mercados públicos de suborno:

• Votium (focado no ecossistema Convex/Curve)
• Hidden Hand da Redacted Cartel (atendendo Balancer, Frax, Aura)

Mas para os grandes players e baleias, o suborno oficial tem uma falha grave: ele é 100% público. Qualquer analista de dados abre o dashboard e vê exatamente quem tá pagando pra qual pool.

Na Governança Sombra, a jogada é outra:

• Flashloans Governance Interception: Uso de empréstimos relâmpago para tomar o controle de protocolos sem trava ve num único bloco. O atacante puxa o empréstimo, passa a proposta com o colateral temporário e liquida a dívida na mesma transação.
• Off-Chain / OTC Bribe Matching: Acordos de bastidores onde grandes detentores institucionais de tokens ve recebem stablecoins, altcoins ou cotas em contratos SAFT diretamente em carteiras custodiantes em troca de votos via delegação.
• Private Dark Pools (Wrapped Voting Power): Encapsulamento de tokens de governança em smart contracts que separam o valor econômico do token do seu direito de voto. Os direitos de voto são tokenizados e leiloados em esquemas fechados (como Dutch Auctions).

Casos Reais: O rastro de destruição da governança oculta

Caso 1: O Ataque ao Beanstalk Farms (Abril de 2022) — US$ 182 milhões

Embora tecnicamente rotulado como um hack via Flashloan, a essência do ataque foi uma "tomada de governança sombra relâmpago". O hacker pegou um flash loan de US$ 1 bilhão em Lido stETH, BEAN e outros ativos via Aave, abocanhou mais de 70% do poder de voto (Voting Power) na proposta BIP-18 (Beanstalk Improvement Proposal) e drenou todo o tesouro da DAO num piscar de olhos.

Onde estava o vetor da Governança Sombra: O protocolo contabilizava votos instantaneamente com base no saldo de tokens do bloco atual, sem nenhum Timelock (delay de execução) e sem exigir staking prévio.

Caso 2: A Sequestro da Governança do Tornado Cash (Maio de 2023)

Um agente malicioso submeteu uma proposta de governança usando, na superfície, a mesma estrutura lógica de uma proposta anterior já aprovada. Só que havia código malicioso camuflado ali dentro. Assim que a comunidade votou a favor, o atacante usou a instrução selfdestruct para trocar a lógica do contrato da proposta no mesmo endereço (via CREATE2), mintou 1,2 milhão de votos TORN falsos para si mesmo, assumiu controle total da DAO e levou US$ 2,1 milhões da tesouraria.

Onde estava o vetor da Governança Sombra: O invasor usou contratos metamórficos (técnica oculta de execução de código) para burlar a auditoria visual das propostas e alterar a lógica de execução pouco antes da votação.

Como rastrear a Governança Sombra direto na blockchain

Identificar a compra de votos no mercado balcão não é tarefa fácil, mas qualquer acordo feito fora da rede precisa ser executado on-chain em algum momento — e é aí que fica o rastro. A análise se resume a detectar anomalias no comportamento de carteiras grandes (baleias) e contratos de delegação.

Análise comparativa: Suborno Legítimo vs. Governança Sombra

Workflow prático para monitoramento on-chain

Para pegar movimentações suspeitas no pulo, engenheiros backend e analistas de dados focam no monitoramento das seguintes anomalias:

• Monitoramento de Padrões de Delegação (Delegate Tracking): Escutar o evento DelegateChanged(address indexed delegator, address indexed fromDelegate, address indexed toDelegate). Se um holder do top 20 repassar seu poder de voto para uma carteira virgem a 2 ou 3 blocos do fim da janela de votação, o alerta vermelho de acordo OTC acende na hora.
• Rastreamento de fundos vindos de Mixers: Se o endereço receptor das delegações receber stablecoins ou tokens nativos de mixers anônimos poucas horas antes de votar, a chance de ser um pagamento por "voto encomendado" é altíssima.
• Aproveitamento de Mempool e MEV (MEV-driven Voting): O famoso "snip" da proposta no último bloco. Os atacantes enviam a transação privada diretamente para o block builder (via Flashbots, por exemplo) para esconder o acúmulo de votos até o bloco ser minerado.

Script em Python para detectar anomalias em delegações

Abaixo está um script leve em Python utilizando a biblioteca web3.py. Ele monitora a transferência repentina de grandes volumes de poder de voto em contratos ERC20Votes (padrão Compound/OpenZeppelin) antes do encerramento das votações.

import time
import logging
from collections import defaultdict
from web3 import Web3
# Configuração de logs
logging.basicConfig(level=logging.INFO, format="%(asctime)s [%(levelname)s] %(message)s")
RPC_URL = "https://eth-mainnet.g.alchemy.com/v2/YOUR_API_KEY"
RAW_TOKEN_ADDRESS = "0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984" # UNI
# Margem de segurança contra reorgs da rede (12 blocos ~= 2.5 minutos)
SAFE_CONFIRMATIONS = 12
BATCH_STEP = 1000
ABI = [
   {
       "inputs": [],
       "name": "decimals",
       "outputs": [{"type": "uint8"}],
       "stateMutability": "view",
       "type": "function"
   },
   {
       "inputs": [],
       "name": "totalSupply",
       "outputs": [{"type": "uint256"}],
       "stateMutability": "view",
       "type": "function"
   },
   {
       "anonymous": False,
       "inputs": [
           {"indexed": True, "name": "delegate", "type": "address"},
           {"indexed": False, "name": "previousBalance", "type": "uint256"},
           {"indexed": False, "name": "newBalance", "type": "uint256"}
       ],
       "name": "DelegateVotesChanged",
       "type": "event"
   },
   {
       "anonymous": False,
       "inputs": [
           {"indexed": True, "name": "delegator", "type": "address"},
           {"indexed": True, "name": "fromDelegate", "type": "address"},
           {"indexed": True, "name": "toDelegate", "type": "address"}
       ],
       "name": "DelegateChanged",
       "type": "event"
   }
]
# 1. Validação de conexão RPC
w3 = Web3(Web3.HTTPProvider(RPC_URL))
if not w3.is_connected():
   raise ConnectionError("RPC indisponível. Cheque sua API key ou o status do nó.")
# 2. Checksum e instanciação do contrato
token_address = w3.to_checksum_address(RAW_TOKEN_ADDRESS)
contract = w3.eth.contract(address=token_address, abi=ABI)
# 3. Leitura de parâmetros dinâmicos
try:
   TOKEN_DECIMALS = contract.functions.decimals().call()
   TOTAL_SUPPLY = contract.functions.totalSupply().call()
   logging.info(f"Token carregado. Decimals: {TOKEN_DECIMALS} | Total Supply: {TOTAL_SUPPLY / (10 ** TOKEN_DECIMALS):,.0f}")
except Exception as e:
   logging.warning(f"Falha ao ler parâmetros do token, aplicando fallback padrão: {e}")
   TOKEN_DECIMALS = 18
   TOTAL_SUPPLY = 1000000000 * (10 ** 18) # Fallback para 1B
# Lidar de anomalia: 100.000 tokens
VOTE_THRESHOLD = 100000 * (10 ** TOKEN_DECIMALS)
def get_logs_batched(event_obj, from_block, to_block):
   """Busca logs em lotes de forma segura. Retorna (logs, is_success)."""
   all_events = []
   for start in range(from_block, to_block + 1, BATCH_STEP):
       end = min(start + BATCH_STEP - 1, to_block)
       try:
           logs = event_obj.get_logs(fromBlock=start, toBlock=end)
           all_events.extend(logs)
       except Exception as e:
           logging.error(f"Erro na busca de logs entre blocos {start}-{end}: {e}")
           return [], False
   return all_events, True
def analyze_governance_shifts(from_block, to_block):
   """Analisa a movimentação de votos calculando o impacto no Total Supply."""
   vote_changes, ok1 = get_logs_batched(contract.events.DelegateVotesChanged, from_block, to_block)
   delegations, ok2 = get_logs_batched(contract.events.DelegateChanged, from_block, to_block)
   if not (ok1 and ok2):
       return False  # Falha no fetch, o ponteiro do bloco NÃO avança!
   # Mapeia múltiplos eventos DelegateChanged dentro da mesma transação
   delegation_map = defaultdict(list)
   for d in delegations:
       tx_hash = d.transactionHash.hex()
       delegation_map[tx_hash].append({
           "delegator": d.args.delegator,
           "from": d.args.fromDelegate,
           "to": d.args.toDelegate
       })
   for event in vote_changes:
       prev_bal = event.args.previousBalance
       new_bal = event.args.newBalance
       delta = new_bal - prev_bal
       if abs(delta) >= VOTE_THRESHOLD:
           tx_hash = event.transactionHash.hex()
           delegate = event.args.delegate
           
           # Métricas relativas ao Total Supply
           fmt_delta = delta / (10 ** TOKEN_DECIMALS)
           fmt_new = new_bal / (10 ** TOKEN_DECIMALS)
           share_of_supply = (new_bal / TOTAL_SUPPLY) * 100
           delta_share_of_supply = (abs(delta) / TOTAL_SUPPLY) * 100
           # Níveis de severidade
           severity = "PICO CRÍTICO" if share_of_supply >= 1.0 else "ATENÇÃO"
           logging.warning(f"[{severity}] Alteração no Voting Power: {fmt_delta:+,.0f} tokens ({delta_share_of_supply:.3f}% da emissão)")
           logging.info(f"    Delegado: {delegate}")
           logging.info(f"    Poder total do endereço: {fmt_new:,.0f} votos ({share_of_supply:.3f}% do Total Supply)")
           logging.info(f"    Hash da Tx: {tx_hash}")
           contexts = delegation_map.get(tx_hash, [])
           if contexts:
               logging.info(f"    Causa: TROCA DIRETA DE DELEGADO ({len(contexts)} eventos na Tx)")
               for ctx in contexts:
                   logging.info(f"      • Delegador: {ctx['delegator']} | {ctx['from']} -> {ctx['to']}")
           else:
               logging.info("    Causa: Variação de saldo no delegado atual (Transfer / Claim / Mint / Burn)")
           
           print("-" * 75)
   return True
def start_realtime_monitoring(poll_interval=12):
   """Daemon em tempo real mantendo a janela de confirmações seguras."""
   latest_block = w3.eth.block_number
   last_processed_block = latest_block - SAFE_CONFIRMATIONS - 1
   logging.info(f"Iniciando daemon. Bloco seguro inicial: #{last_processed_block} (Confirmações = {SAFE_CONFIRMATIONS})")
   while True:
       try:
           current_block = w3.eth.block_number
           safe_block = current_block - SAFE_CONFIRMATIONS
           if safe_block > last_processed_block:
               success = analyze_governance_shifts(last_processed_block + 1, safe_block)
               if success:
                   last_processed_block = safe_block
               else:
                   logging.warning("Intervalo não processado completamente por falha de RPC. Tentando novamente no próximo ciclo.")
       except Exception as e:
           logging.error(f"Falha crítica no loop principal: {e}")
       time.sleep(poll_interval)
if __name__ == "__main__":
   start_realtime_monitoring(poll_interval=12)

Como proteger seu protocolo contra a Governança Sombra

O ecossistema DeFi vem evoluindo para rebater esse tipo de vetor. Apenas auditar a sintaxe dos smart contracts não basta mais; a arquitetura do modelo de governança da DAO precisa ser defensiva por design.

• Implementação de Timelocks com poder de Veto: Nenhuma alteração de código pode ser executada instantaneamente. Uma janela mínima de 48 a 72 horas garante tempo hábil para que um Conselho de Segurança (Security Council via multisig) passe a canetada e pause propostas maliciosas.
• Adoção de modelos ve com trava gradual: Quando os tokens estão travados sem opção de saída rápida, o custo financeiro para orquestrar um ataque relâmpago fica proibitivo.
• Governança Otimista (Optimistic Governance): Padrão adotado por projetos como Moonwell e Lido, onde as propostas passam por padrão, e a comunidade só precisa votar caso queira exercer o direito de veto.
• Governança de Token Duplo (Dual-Token Governance): Separação dos direitos de decisão entre os detentores de tokens de utilidade e os provedores de liquidez ou usuários do sistema (como no Dual Governance do Lido, onde stETH holders podem travar decisões arbitrárias dos LDO holders).

A governança sombra nada mais é do que o resultado inevitável da transformação do direito de voto em um ativo financeiro negociável. Aqui na EXMON, a missão dos nossos engenheiros e analistas blockchain é monitorar esse tipo de anomalia na mempool e na camada de smart contracts antes que se tornem uma ameaça, entregando um ambiente 100% seguro e transparente para nossa comunidade.