De acordo com a Cryptopolitan, a 10 de junho, um atacante anónimo concluiu a criação, votação e execução de uma proposta de governação numa única transação, acumulando mais de 50% do supply circulante através do token Token of Power (TOP). Após cunhar grandes quantidades de novos tokens, esvaziou o Balancer V1 liquidity pool na Ethereum, extraindo 944,2 WETH (cerca de 1,58 milhões de dólares).
Mecanismo do ataque: como 8.192 TOP conseguiram assumir a governação numa única transação
A oferta total do token TOP é de 16.384 tokens. De acordo com a análise on-chain da Blockaid, o atacante acumulou 8.192,000001 TOP, ultrapassando precisamente o limiar de 50%, o que lhe concede poder de voto para aprovar uma proposta de forma unilateral. Como a aplicação Aragon Voting não tem time lock, o atacante, através de um contrato dedicado, completou três etapas numa única transação:
Criação da proposta de governação: exige a cunhagem de grandes quantidades de novos tokens TOP para o endereço do atacante
Voto aprovado: aprova unilateralmente a proposta com mais de 50% do poder de voto
Execução imediata e esvaziamento do liquidity pool: os tokens TOP recém-cunhados são convertidos para 944,2 WETH no Balancer V1 BPool
O BlockSec Phalcon confirmou o processo de execução da proposta e da cunhagem dos tokens. A Balancer, por si, não tem vulnerabilidade: o atacante apenas utilizou o liquidity pool para converter tokens TOP com a oferta artificialmente ampliada para WETH.
Caminho dos fundos: carregamento no Tornado Cash e estado da rastreabilidade on-chain
De acordo com a análise on-chain da Blockaid, a fonte inicial dos fundos da carteira do atacante foi o Tornado Cash; o ataque foi concluído numa única transação através de um contrato dedicado. No momento em que a notícia foi divulgada a 10 de junho de 2026, 944,2 WETH continuam ainda rastreáveis on-chain, mas a fonte inicial dos fundos no Tornado Cash acrescentou dificuldade na recuperação dos fundos e na confirmação da identidade do atacante.
Causa raiz: ausência de configuração de governação, não falha em código de smart contract
A causa raiz deste incidente é uma falha ao nível da configuração de governação, e não um erro tradicional em smart contracts — todas as funções dos contratos funcionaram conforme o desenho. As configurações específicas em falta incluem:
Sem time lock: não há período de espera após a aprovação da proposta, impossibilitando outros detentores de tokens de reagirem
Sem limiar de quórum para atraso: não exige uma percentagem mínima de detentores de tokens para participar na votação
Sem atraso na criação de propostas: a proposta pode ser concluída desde a criação até à execução na mesma blockchain block
A oferta total do TOP é apenas de 16.384 tokens, pelo que o custo para obter controlo maioritário é extremamente baixo. A documentação oficial da Aragon explica claramente que as permissões de chamada para operações sensíveis, como a cunhagem de tokens, devem ser restringidas a endereços autorizados, mas a configuração do TOP não aplicou este requisito.
Estado até ao momento da publicação: ausência de declarações, fundos ainda on-chain
A reportagem da Cryptopolitan confirma que, até 10 de junho de 2026: a equipa do Token of Power não emitiu qualquer declaração sobre esta vulnerabilidade; a Aragon também não emitiu qualquer declaração; 944,2 WETH continuam rastreáveis on-chain.
Perguntas frequentes
Porque é que este ataque foi classificado como uma «vulnerabilidade de governação» e não como uma «vulnerabilidade de smart contract»?
Vulnerabilidades tradicionais em smart contracts significam que o atacante contorna a lógica prevista através de falhas no código. Neste caso, todas as funções dos contratos foram executadas conforme o desenho — as votações de governação funcionaram normalmente e a cunhagem de tokens correspondeu às autorizações configuradas para a DAO. A vulnerabilidade reside no facto de a configuração da DAO do TOP permitir que um único detentor controle totalmente o processo de governação sem qualquer atraso temporal, o que é uma falha de configuração, e não um erro de código.
O protocolo Balancer deve assumir responsabilidades?
Conforme confirmado pelas análises da Blockaid e do BlockSec Phalcon, o protocolo Balancer não tem qualquer vulnerabilidade. O atacante utilizou funções normais de troca de tokens, convertendo tokens TOP com supply artificialmente ampliada para WETH; o Balancer, como ferramenta de liquidity pool, foi apenas aproveitado, não sendo o alvo do ataque nem a fonte da vulnerabilidade.
Que configurações de governação podem impedir este tipo de ataque?
Com base na documentação oficial da Aragon e na análise on-chain deste incidente, as seguintes três configurações podem prevenir ataques semelhantes: time lock (definindo um período de espera entre a aprovação e a execução de uma proposta); quórum obrigatório (exigindo uma percentagem mínima de detentores para participar na votação); atraso na proposta (permitindo votar apenas após um período após a criação). No momento em que a notícia foi divulgada a 10 de junho de 2026, o TOP não implementou nenhuma das configurações acima.
