Esse é o tipo de bug que mantém as equipes de protocolo acordadas à noite. Uma exploração de US$ 5 milhões no ZKSwap, habilitada por uma única instrução deixada no lugar errado. Aqui está um mergulho profundo em como isso aconteceu e como o monitoramento onchain poderia ter parado. 🧵

1/ Em 9 de julho, a GMX foi hackeada por US$ 42 milhões. Mas outra coisa aconteceu naquele dia e quase ninguém percebeu: a ponte do ZKSwap foi silenciosamente drenada por US $ 5 milhões. A parte interessante? Não houve nenhuma façanha extravagante envolvida. Apenas uma função crítica que fez ... nada.

2/ ZKSwap é um zk-rollup construído no Ethereum. Como muitos rollups, ele usa uma ponte para mover ativos entre L1 e L2. Como salvaguarda, a ponte inclui um "Modo Êxodo", uma maneira de os usuários recuperarem fundos sem precisar do operador. Em teoria, essa é uma ótima ideia. Na prática...

3/ O Modo Êxodo permite que os usuários provem manualmente que possuíam tokens no último estado L2 verificado. É um mecanismo alternativo: sem confiança, auto-custódia, não interativo. Mas a implementação do ZKSwap tinha uma falha 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 à prova de zk. Mas olhe atentamente para a primeira linha: retorne verdadeiro; É isso. Nada mais corre.

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

6/ O invasor não precisava de exploits sofisticados - apenas chamadas repetidas para exit() com dados inventados. Eles ignoraram as verificações de saldo, retiraram vários tokens e abusaram da lógica fraca do anulador para evitar a detecção. Tudo isso enquanto o contrato dizia: ✅

7/ Este não foi um caso obscuro. Essa era a lógica central para a recuperação de ativos, deixada completamente aberta. E como o Modo Êxodo raramente é acionado, o caminho quebrado passou despercebido... por meses.

8/ Aqui está o que deveria ter acionado os alarmes: • Modo Êxodo sendo acionado após longa dormência • Dezenas de chamadas de saque acontecendo de uma só vez • Aumento repentino nas alterações de saldos para retirar Tudo isso era visível e poderia ter sido interrompido com monitoramento onchain em tempo real.

9/ Então, qual é a lição? • O código de emergência ainda é o código de produção • Caminhos alternativos não ajudam se não funcionarem • O monitoramento em tempo real não é opcional, é crítico para a sobrevivência