Resumo da notícia
Ferramenta usa EIP-7702 para delegar controle de contas comprometidas.
Resgate ocorre em uma única transação, impedindo bots de drenagem.
Testes em Sepolia foram bem-sucedidos, mas riscos de front-running ainda exigem ajustes.
A rede Ethereum se prepara para dar um passo que, até pouco tempo atrás, parecia impossível: permitir que usuários recuperem ETH roubado por hackers, mesmo quando a carteira já está totalmente comprometida e monitorada por bots automáticos.
Nesta semana, uma proposta experimental apresentada pelo desenvolvedor conhecido como Morsy, abriu espaço para um novo mecanismo de resgate que promete driblar o problema mais frustrante enfrentado por vítimas de vazamentos de chave privada ou por esquemas de phishing, contratos inteligentes fraudulentos, entre outros.
De acordo com Morsy, o problema central decorre do uso de sweeper bots, programas desenhados para monitorar permanentemente uma carteira comprometida. Assim que qualquer quantia em ETH ou tokens chega ao endereço, seja por pagamento de taxas, recepção de airdrops ou desbloqueios automáticos, o bot envia uma transação de retirada com prioridade máxima. Esse movimento impede que o proprietário consiga agir, já que, para mover qualquer ativo, ele precisaria pagar gas, exatamente o tipo de ação que ativa o dreno instantâneo.
Morsy explica que “uma vez que a chave privada cai nas mãos do atacante, a conta se torna praticamente inutilizável”. Até mesmo enviar ETH suficiente para pagar a taxa de rede se torna inútil, porque o bot reage com mais rapidez do que qualquer tentativa humana. Isso cria uma situação paradoxal: a carteira pode ter saldo, mas o usuário legítimo não consegue tocá-lo.
Impedir roubos na carteira
A proposta anunciada tenta romper esse ciclo com uma abordagem inédita baseada na EIP-7702, implementada na atualização Pectra. A norma introduziu uma função importante: a capacidade de delegar temporariamente o controle de uma conta externa (EOA) para um contrato inteligente. Essa delegação abre espaço para que uma carteira comprometida seja manobrada de forma segura, desde que o processo ocorra sem depender de transações emitidas por ela mesma.
O mecanismo funciona de maneira coordenada e extremamente precisa. Antes de tudo, o usuário assina offline uma autorização que concede a um contrato de recuperação o direito de agir em nome da carteira comprometida. Como essa assinatura não passa pela rede, não aciona o bot de drenagem. Em seguida, uma segunda carteira, chamada de patrocinadora, assume os custos da operação. Esse ponto é crucial, já que qualquer tentativa de enviar ETH diretamente para a carteira vulnerável seria imediatamente interceptada pelos criminosos.
ETFs de Bitcoin registram maiores entradas de 2026 até agora enquanto o BTC sobe acima de US$ 97 mil
Com autorização e recursos garantidos, o contrato de recuperação executa, em uma única transação atômica, todas as etapas necessárias: utiliza a permissão assinada, acessa os fundos disponíveis, como tokens, recompensas de airdrops ou valores recém-desbloqueados, e transfere tudo para um novo endereço seguro. A operação ocorre como um bloco indivisível. Nada é enviado passo a passo, e não há janelas temporais para que o bot ou o hacker tentem interceptar a movimentação.
Segundo Morsy, essa execução atômica é o que torna o resgate possível. A carteira hackeada, em momento algum, transmite a transação; portanto, o bot não detecta nenhum evento acionável.
“A operação não dá margem para intervenção do atacante”, explicou o desenvolvedor ao apresentar o protótipo. Ele completou afirmando que, mesmo em casos extremos de vigilância contínua, a ação unificada evita qualquer disputa pela prioridade do bloco.
Os primeiros testes, realizados na rede de provas Sepolia, tiveram sucesso. Morsy relatou que o processo demandou inúmeras tentativas e ajustes, principalmente para lidar com cenários onde bots automatizados disputam cada fração de segundo com transações legítimas. Agora, o desafio passa a ser o ambiente real, onde bots são mais agressivos e redes congestionadas afetam o tempo de inclusão dos blocos. O desenvolvedor reconhece que ainda precisa corrigir um ponto delicado: a possibilidade de front-running da transação patrocinada, ou seja, a chance de um terceiro tentar antecipá-la e sabotar o processo.
