EIP-7702 não é a causa principal do roubo de US$ 6,3 bilhões da Binance; o modo como a assinatura foi obtida é.

Horário de Pequim, 30 de outubro de 2026, 04:24.

Registros on-chain mostram que os fundos saíram do endereço 0x28C6…1d60. Esse endereço é chamado de Binance 14, uma das maiores carteiras quentes Ethereum da Binance, que realiza milhares de saques por dia. Essa transação transferiu 167.464 ETH, US$ 1,615 bilhão em USDT e mais de 60 tipos de tokens, avaliados em cerca de US$ 2,5 bilhões na ocasião. Restou apenas 1 ETH na carteira.

A taxa de gás foi de 0,0004 ETH, menos de US$ 1.

Três minutos antes, às 04:21, alguém submeteu uma transação do tipo EIP-7702 para esse endereço, contendo 50 autorizações com nonces de 18.914.775 a 18.914.824. 49 eram inválidas; 1 acertou. Um acerto significa: a partir desse instante, qualquer chamada ao Binance 14 executa o contrato implantado pelo atacante na noite anterior às 23:59 — um 'sweeper' não verificado com apenas uma função de limpeza.

Assim, o Binance 14 deixou de ser uma carteira. Tornou-se uma casca contendo o programa de outra pessoa.

Às 08:06, a delegação ainda estava ativa. Após 3 horas e 45 minutos, ninguém a revogou.

Além disso, 'revogar' essa delegação exige apenas que a mesma chave assine mais uma vez. Às 06:55 daquela manhã, a Binance ainda usava essa chave para transferir de volta à sua própria carteira os tokens espalhados que não tinham sido limpos.

O EIP-7702 é a causa principal do ataque?

A lógica do EIP-7702 é esta: permitir que um endereço comum (EOA) alugue o código de um contrato inteligente, mantendo inalterados o endereço, o saldo e a chave privada. O aluguel ocorre escrevendo 23 bytes no campo de código desse endereço — 0xef0100 seguido do endereço do contrato. Esses 23 bytes não são código executável; são um ponteiro. A partir daí, toda chamada a esse endereço faz com que a EVM carregue e execute o código apontado pelo ponteiro no contexto próprio desse endereço: address(this) continua sendo ele mesmo, e o saldo permanece o seu saldo.

Não há falha nele. Derek Chiang, fundador da ZeroDev e participante do EIP-7702, foi direto em sua declaração no dia do incidente: o EIP-7702 em si não tem vulnerabilidade, e usuários de carteiras que o suportam não precisam entrar em pânico. Ele acrescentou ainda: para um atacante usar o 7702, ele deve controlar a chave privada ou enganar a Binance para que assine uma autorização 7702.

Também não é a primeira vez que é usado como ferramenta de ataque. Após a atualização Pectra da Ethereum, a Wintermute descobriu, em poucas semanas, que mais de 97% das delegações 7702 na mainnet apontavam para quase o mesmo contrato 'sweeper'; pesquisas identificaram cerca de 3,66 milhões de transações de autorização, das quais aproximadamente 63% estavam ligadas a contratos maliciosos, com perdas confirmadas de US$ 2,3 milhões; a Blockaid verificou quatro incidentes 7702 no primeiro semestre de 2026, totalizando cerca de US$ 1,08 milhão, e previu que o primeiro caso de sete dígitos ocorreria dentro do ano.

O resultado alcançou dez dígitos, três ordens de grandeza acima de sua estimativa.

Isso levou muitos a atribuir o roubo de US$ 5,6 bilhões da Binance — o maior da história humana — ao EIP-7702. Mas realmente é um problema do 7702?

Como as Assinaturas Foram Obtidas

Antes de avançar, é preciso esclarecer um ponto: 50 autorizações significam 50 assinaturas — então como exatamente essas 50 assinaturas foram geradas?

Se o atacante tivesse obtido as chaves privadas completas, por que precisaria testar cegamente 50 nonces? Se as chaves sempre estiveram sob controle da Binance, por que 11 carteiras caíram simultaneamente em 12 minutos? Ainda não há explicação.

Vinte e quatro segundos após a varredura principal, a carteira quente Binance 16 transferiu 28.005,6 ETH, 55,7 milhões de USDT, 25,9 milhões de RLUSD e 84,5 WBTC, todos para o mesmo endereço receptor.

Em até 12 minutos, outras 10 carteiras quentes da Binance fizeram o mesmo em quatro blockchains: a Binance 55 na Optimism transferiu 44,2 milhões de OP; quatro carteiras na Arbitrum transferiram 74,6 milhões de ARB e 8.426 ETH; quatro carteiras na Avalanche transferiram 1,81 milhão de AVAX e 8,41 milhões de USDT.

Nenhuma dessas carteiras continha código. Cada transação foi uma simples transferência comum, assinada pela chave privada própria da carteira, inserida entre saques rotineiros.

Quem detém as chaves privadas não precisa adivinhar nonces cegamente. Verificar eth_getTransactionCount leva um segundo.

A pessoa que precisa gerar 50 autorizações cobrindo 50 nonces consecutivos de uma só vez é diferente: alguém que consegue obter assinaturas, mas não acessa o estado em tempo real da carteira; ou alguém que só pode enviar lotes de autorizações pré-montadas de uma vez, deixando o sistema tentá-las.

Mais notavelmente, essas 50 autorizações foram aprovadas simultaneamente numa única transação.

A empresa de segurança Blockaid avaliou que «a chave foi mal utilizada», não que a chave privada tenha sido extraída diretamente. Quit, VP de Blockchain da Yuga Labs, também aponta nessa direção: o atacante obteve «assinaturas autorizadas», não a chave privada, e usar um relayer para submissão pode ter sido justamente para ocultar a origem dessas assinaturas.

Shenyu mencionou um detalhe em seu resumo matinal: até as 06:55, a Binance ainda usava a mesma chave privada para assinar, transferindo fragmentos de tokens não varridos de volta para sua própria carteira.

Isso indica que a chave ainda estava sob controle da Binance naquela manhã.

Agora, às 10:26, a Binance divulgou sua avaliação preliminar: o laptop de um engenheiro DevOps pode ter sido comprometido, permitindo ao atacante acessar contêineres de serviço e submeter transações não autorizadas de saque; até o momento, não há evidências de vazamento da chave privada da carteira.

A perda não ocorreu na blockchain.

Portanto, o problema central não é o EIP-7702, mas a etapa anterior à assinatura.

Uma carteira quente assina milhares de transações por dia, logo deve ser automatizada; para ser segura, exige HSMs, MPC, multisignature e fluxos de aprovação. Assim, todo o modelo de segurança resume-se a uma frase: este processo consegue determinar, antes da assinatura, que «esta transação não deve ser assinada»?

O problema é que a maioria dos critérios de avaliação possui apenas duas colunas: valor e endereço.

A autorização 7702 não tem nenhum desses dois. Não envolve valor. O que ela altera não é «quanto transferir», mas «o que esse endereço representa».

Não é que a Binance não estivesse se defendendo.

Três dias antes do incidente, em 27 de outubro, ela divulgou proativamente algo relevante: na semana anterior, sua equipe de segurança havia interceptado múltiplos ataques ligados à Coreia do Norte. O método chama-se Entrevista Contagiosa — o atacante se passa por recrutador, usando entrevistas, testes de programação e frases como «instale primeiro uma ferramenta de desenvolvedor» para induzir vítimas a executar programas maliciosos; ao rodar, o programa abre portas para chaves, redes internas e movimentações subsequentes de fundos.

Mas falhou em impedir a pergunta «essa transação deve ser assinada?»