Este é o tipo de bug que mantém as equipas de protocolo acordadas à noite. Um exploit de $5M no ZKSwap, possibilitado por uma única declaração deixada no lugar errado. Aqui está uma análise aprofundada de como isso aconteceu e como a monitorização onchain poderia tê-lo impedido. 🧵

1/ No dia 9 de julho, o GMX foi hackeado por $42M. Mas algo mais aconteceu nesse dia e quase ninguém notou: a ponte do ZKSwap foi silenciosamente drenada por $5M. A parte interessante? Não houve nenhuma exploração sofisticada envolvida. Apenas uma função crítica que não fez... nada.

2/ ZKSwap é um zk-rollup construído na Ethereum. Como muitos rollups, utiliza uma ponte para mover ativos entre L1 e L2. Como medida de segurança, a ponte inclui um "Modo Exodus", uma forma para os usuários recuperarem fundos sem precisar do operador. Em teoria, essa é uma ótima ideia. Na prática…

3/ O Modo Exodus permite que os usuários provem manualmente que possuíam tokens no último estado L2 verificado. É um mecanismo de fallback: sem confiança, auto-custodial, não interativo. Mas a implementação do ZKSwap tinha um erro fatal: A função responsável por verificar as provas não verificava nada. Literalmente.

4/ Aqui está o código que deveria ter parado o ataque 👇 À primeira vista, parece um verdadeiro verificador de zk-proof. Mas olhe de perto a primeira linha: return true; É isso. Nada mais é executado.

5/ O resultado? Cada "prova" de retirada (não importa quão falsa) passou na validação. O contrato aceitou reivindicações arbitrárias sobre saldos de tokens... e os creditou como se fossem reais. Transformou um mecanismo de fallback sem confiança em uma torneira desprotegida.

6/ O atacante não precisava de exploits sofisticados - apenas chamadas repetidas para exit() com dados falsos. Eles contornaram as verificações de saldo, retiraram através de múltiplos tokens e abusaram da lógica fraca de nulificadores para evitar a detecção. Tudo isso enquanto o contrato dizia: ✅

7/ Isto não foi um caso obscuro. Esta era a lógica central para a recuperação de ativos, deixada completamente aberta. E como o Modo Exodus raramente é ativado, o caminho quebrado passou despercebido... durante meses.

8/ Aqui está o que deveria ter acionado alarmes: • Modo Exodus sendo ativado após uma longa inatividade • Dezenas de chamadas de retirada acontecendo todas ao mesmo tempo • Aumento repentino nas mudanças de balancesToWithdraw Tudo isso era visível e poderia ter sido interrompido com monitoramento onchain em tempo real.

9/ Qual é a lição? • O código de emergência ainda é código de produção • Caminhos de fallback não ajudam se não funcionarem • Monitorização em tempo real não é opcional, é crítica para a sobrevivência