O incidente de segurança da Binance chamou a atenção não apenas pela escala da atividade suspeita da carteira, mas também por um detalhe técnico visível pouco antes de grandes ativos Ethereum começarem a se mover: um lote de autorizações EIP-7702.
Esse detalhe rapidamente colocou o EIP-7702 no centro da discussão. O mecanismo de delegação de conta do Ethereum permite que uma conta de propriedade externa normal, ou EOA, execute temporariamente lógica de contrato inteligente. No incidente da Binance, pesquisadores de blockchain identificaram uma delegação EIP-7702 pouco antes de ativos serem transferidos de uma carteira quente vinculada à Binance.
Mas há uma distinção importante.
A presença de uma autorização EIP-7702 não prova, por si só, que o EIP-7702 foi explorado.
A investigação inicial da Binance, em vez disso, aponta para um comprometimento da infraestrutura operacional. A exchange disse que o laptop de um engenheiro de DevOps pode ter sido comprometido, permitindo que um atacante acessasse um contêiner de serviço e enviasse transações de saque não autorizadas. A Binance também disse que não encontrou evidências de que as chaves privadas da carteira tenham vazado.
Isso torna o incidente particularmente importante para entender a segurança moderna de carteiras. Uma chave privada pode permanecer dentro de uma infraestrutura protegida enquanto um atacante abusa de outro sistema que tem permissão para solicitar assinaturas legítimas.
Este artigo explica o que o EIP-7702 parece ter feito no incidente, por que relatos de múltiplas autorizações atraíram atenção e por que a diferença entre roubo de chave e comprometimento da infraestrutura de assinatura importa.
O que aconteceu no incidente de segurança da Binance?
Atividades suspeitas envolvendo carteiras quentes vinculadas à Binance começaram a atrair atenção em 30 de outubro de 2026.
Investigadores on-chain observaram grandes transferências de carteiras associadas à exchange para endereços recém-criados. As estimativas iniciais variaram consideravelmente à medida que os pesquisadores rastreavam transações em Ethereum, Bitcoin, Tron e outras redes.
A Binance posteriormente reconheceu um incidente de segurança e começou a investigar a origem das transações não autorizadas. A exchange suspendeu temporariamente depósitos e saques enquanto realizava verificações de segurança.
Em sua atualização de segurança de 30 de outubro, a Binance disse que sua investigação inicial sugeria que o laptop comprometido de um engenheiro de DevOps permitiu que um atacante obtivesse acesso a um contêiner de serviço e enviasse transações de saque não autorizadas.
A exchange estimou o impacto geral em aproximadamente US$ 6,3 bilhões naquela fase da investigação e disse que cerca de US$ 3 bilhões em ativos afetados haviam sido congelados on-chain. A Binance também declarou que cobriria as perdas usando seu fundo SAFU e fundos da empresa.
Mais importante para a discussão técnica, a Binance disse:
Não havia encontrado evidências de vazamento de chave privada da carteira.
Essa declaração muda a forma como a atividade EIP-7702 relatada deve ser interpretada.
Em vez de perguntar apenas se um atacante roubou uma chave privada de carteira quente, a questão mais relevante passa a ser se um sistema interno comprometido foi capaz de solicitar ou facilitar uma autorização válida a partir de uma infraestrutura de assinatura protegida.
Por que o EIP-7702 se tornou parte da investigação?
O EIP-7702 foi introduzido com a atualização Pectra do Ethereum para dar às contas de propriedade externa algumas das capacidades normalmente associadas a carteiras de contrato inteligente.
Tradicionalmente, uma EOA do Ethereum é controlada por uma chave privada. Ela pode assinar transações, transferir ativos e interagir com contratos inteligentes, mas sua própria conta não contém lógica de execução programável.
O EIP-7702 muda essa relação.
Ele permite que uma EOA autorize o código de outro contrato a atuar como sua lógica de execução, preservando o endereço Ethereum original.
Isso possibilita recursos úteis de abstração de conta, como agrupamento de transações, patrocínio de gas e sistemas de permissão mais avançados.
Também significa que uma autorização EIP-7702 merece substancialmente mais atenção do que uma aprovação de token convencional.
Durante a análise do incidente da Binance, pesquisadores relataram que um endereço financiado via Tornado Cash enviou múltiplas autorizações EIP-7702 envolvendo uma carteira quente Ethereum vinculada à Binance pouco antes de ocorrerem grandes transferências de ativos.
Uma autorização, segundo relatos, correspondia ao estado da carteira e tornou-se efetiva.
Aproximadamente três minutos depois, ativos significativos começaram a sair da carteira.
O momento naturalmente fez da autorização uma parte importante da investigação.
Ainda assim, isso não nos diz como a autorização válida foi obtida.
Como Funciona uma Autorização EIP-7702?
A maneira mais fácil de entender o mecanismo é pensar no EIP-7702 como permitir que uma conta Ethereum comum diga temporariamente:
"Use a lógica de execução deste contrato inteligente quando minha conta receber chamadas."
Um fluxo simplificado é assim:
Ethereum EOA
│
│ Assina uma autorização EIP-7702
▼
A delegação é atribuída
│
▼
Contrato inteligente delegado
│
│ Fornece lógica executável
▼
O EOA original pode executar
comportamento no estilo de contrato inteligente
A conta original não desaparece.
Seu endereço, saldos e histórico on-chain existente permanecem intactos. O que muda é o código que pode ser executado por meio dessa conta.
O EIP-7702 também inclui salvaguardas. As autorizações estão vinculadas ao estado da conta, incluindo um nonce, e podem ser substituídas ou revogadas. Portanto, não são instruções arbitrárias que qualquer pessoa pode anexar à carteira de outra pessoa.
Uma autorização válida ainda exige autorização criptográfica legítima da conta relevante.
Esse ponto é central para entender o incidente da Binance.
Se um atacante instala com sucesso uma lógica de delegação maliciosa, a questão de segurança importante não é simplesmente:
"O atacante usou o EIP-7702?"
É:
"Como o atacante obteve autoridade para criar uma autorização EIP-7702 válida?"
Por Que Foram Relatadas Múltiplas Autorizações EIP-7702?
Pesquisadores de segurança que examinaram as transações relataram que o atacante enviou um lote contendo aproximadamente 50 autorizações associadas a diferentes valores de nonce.
À primeira vista, "50 autorizações" pode soar como se 50 carteiras tivessem sido comprometidas.
Não é necessariamente o que aconteceu.
As contas Ethereum mantêm um nonce que muda à medida que as transações são executadas. Uma autorização EIP-7702 deve corresponder ao estado apropriado da conta.
Se um atacante sabe qual carteira deseja atingir, mas não consegue determinar de forma confiável qual nonce será válido quando uma transação chegar à rede, ele pode preparar autorizações para vários valores de nonce possíveis.
Apenas a autorização que corresponder ao estado válido da carteira teria sucesso.
Essa técnica às vezes é descrita como nonce spraying.
A implicação importante é que a existência de 50 entradas de autorização não significa necessariamente 50 permissões bem-sucedidas, 50 chaves privadas comprometidas ou 50 ataques separados a carteiras.
Em vez disso, o padrão pode ter sido projetado para aumentar a probabilidade de que uma autorização obtida anteriormente correspondesse ao estado da conta alvo quando enviada.
Isso cria outra pergunta:
Quem — ou qual sistema interno — tinha a autoridade para criar a assinatura subjacente?
É aqui que as descobertas preliminares da Binance se tornam especialmente relevantes.
Roubo de Chave Privada e Comprometimento da Infraestrutura de Assinatura São Problemas Diferentes
Muitas discussões sobre segurança de criptomoedas reduzem a proteção de carteiras a um único princípio:
Proteja a chave privada.
Isso continua essencial, mas carteiras institucionais são consideravelmente mais complicadas.
Uma exchange pode usar módulos de segurança de hardware, serviços de assinatura, mecanismos de política, serviços de saque, sistemas de controle de acesso e outras infraestruturas em torno da chave subjacente.
Um atacante pode, portanto, tentar comprometer o processo que solicita uma assinatura em vez de extrair a própria chave privada.
A investigação preliminar da Binance atualmente aponta muito mais para o segundo cenário.
A exchange disse que um laptop DevOps comprometido pode ter permitido acesso a um contêiner de serviço capaz de enviar transações de saque não autorizadas, ao mesmo tempo que declarou explicitamente que não encontrou evidências de vazamento de chave privada.
Essa distinção é significativa.
Uma chave privada protegida por hardware pode tecnicamente permanecer segura enquanto a infraestrutura ao redor produz uma assinatura para algo que nunca deveria ter sido aprovado.
O EIP-7702 Causou o Hack da Binance?
Com base nas informações atualmente disponíveis, não há evidência pública de que uma vulnerabilidade no próprio EIP-7702 tenha causado o incidente de segurança da Binance.
Essa distinção é crítica.
Um atacante usando um recurso legítimo do protocolo não significa automaticamente que o recurso estava quebrado.
Considere um exemplo mais simples.
Se um atacante obtém credenciais legítimas de uma conta bancária e inicia uma transferência por meio do sistema de pagamento normal do banco, o fato de a infraestrutura de transferência do banco ter executado o pagamento não prova que o protocolo de transferência em si era defeituoso.
Uma distinção semelhante se aplica aqui.
A EIP-7702 pode ter fornecido o mecanismo de execução por meio do qual uma conta devidamente autorizada pôde delegar seu comportamento a código malicioso.
Mas a EIP-7702 normalmente exige autorização válida.
A questão não resolvida é como essa autorização se tornou possível.
A explicação preliminar da Binance sugere que os investigadores estão examinando infraestrutura operacional comprometida, e não uma falha do protocolo Ethereum.
Portanto, a interpretação mais precisa neste estágio é:
A EIP-7702 parece relevante para o caminho de execução sob investigação, mas não foi estabelecida como a vulnerabilidade raiz.
O que foi confirmado e o que permanece sob investigação?
Como grandes incidentes de segurança evoluem rapidamente, distinguir descobertas confirmadas da análise em nível de transação é especialmente importante.
Essa distinção importa porque as transações de blockchain oferecem excelente visibilidade sobre o que ocorreu on-chain, mas não necessariamente revelam como um sistema interno de assinatura foi comprometido.
Pesquisadores podem observar delegações, transferências e interações com contratos.
Eles não podem determinar apenas a partir dos dados da blockchain se uma assinatura foi criada após o roubo de uma chave privada, se um serviço interno a solicitou legitimamente ou se um fluxo de trabalho comprometido fez com que um signatário protegido autorizasse instruções maliciosas.
Isso exige evidências de dentro da infraestrutura afetada.
Por que a infraestrutura de assinatura importa tanto quanto o armazenamento de chaves privadas
A segurança institucional de criptomoedas consiste cada vez mais em várias camadas.
A primeira é a segurança das chaves.
Onde a chave privada está armazenada? Ela pode ser extraída? Está protegida por um módulo de segurança de hardware ou outro sistema de custódia criptográfica?
A segunda é a segurança de assinatura.
Quais serviços têm permissão para solicitar assinaturas da chave protegida? Quais autenticações, políticas e mecanismos de aprovação esses serviços devem satisfazer?
A terceira é a segurança de autorização.
Mesmo que uma solicitação seja criptograficamente válida, o que exatamente a conta está sendo solicitada a autorizar?
Essa terceira camada se torna cada vez mais importante à medida que contas inteligentes e a delegação de contas se tornam mais capazes.
Uma transferência convencional de tokens pode mover uma quantidade fixa de um ativo.
Uma delegação pode, em vez disso, alterar como uma conta pode executar instruções futuras.
Para as equipes de segurança, a diferença significa que a validação de assinatura por si só não é mais suficiente.
O significado da transação também deve ser avaliado.
Por que a EIP-7702 muda as premissas de segurança das carteiras
A EIP-7702 é poderosa justamente porque amplia o que uma conta Ethereum comum pode fazer.
Uma carteira pode obter recursos programáveis sem migrar ativos para uma carteira de contrato inteligente completamente nova.
Para carteiras de consumidores, isso pode melhorar a usabilidade.
Para infraestrutura institucional sofisticada, pode oferecer suporte a políticas de execução mais avançadas.
Mas programabilidade adicional cria superfícies de autorização adicionais.
Uma aprovação maliciosa de ERC-20 normalmente concede a outro endereço permissão sobre um token.
Uma delegação maliciosa de EIP-7702 pode potencialmente influenciar como uma conta executa classes muito mais amplas de ações.
Isso não torna a EIP-7702 inerentemente insegura.
Significa que carteiras, exchanges e provedores de custódia devem tratar a autorização de delegação como uma operação de segurança de alto risco.
Uma assinatura EIP-7702 não deve ser avaliada apenas como criptograficamente válida.
Os sistemas de segurança também devem perguntar se o destino da delegação é esperado, se seu bytecode foi revisado, se a autorização solicitada se adequa ao comportamento normal da conta e se a política interna permite que essa conta delegue execução.
O que o post-mortem da Binance deve esclarecer?
A Binance afirmou que um post-mortem técnico detalhado será publicado assim que sua investigação for concluída.
Várias questões determinarão como o setor interpretará, em última análise, o incidente.
Primeiro, como o atacante obteve acesso ao caminho de assinatura?
A explicação preliminar de DevOps identifica uma parte potencialmente comprometida da infraestrutura, mas a cadeia completa desse acesso até uma autorização válida na blockchain continua sendo importante.
Segundo, qual foi o papel exato do EIP-7702?
Os investigadores precisarão determinar se a delegação era necessária para executar as transferências na Ethereum, como a autorização foi preparada e por que os controles internos a permitiram.
Terceiro, as chaves privadas chegaram a ser expostas?
A Binance afirma atualmente que não há evidências de vazamento de chaves privadas. Um relatório forense completo poderia fornecer mais detalhes sobre como as chaves foram isoladas da infraestrutura comprometida.
Por fim, qual controle deveria ter impedido a transação?
Para equipes de segurança institucional, esta pode ser a questão mais valiosa de todas.
Uma assinatura tecnicamente válida não deveria significar automaticamente uma transação operacionalmente válida.
Os sistemas de custódia mais robustos separam a autorização criptográfica da autorização de negócio.
O que isso significa para usuários comuns de carteiras Ethereum?
O incidente da Binance envolve infraestrutura institucional e não deve ser automaticamente interpretado como evidência de que carteiras Ethereum comuns estão expostas ao mesmo caminho de ataque.
Uma carteira pessoal de autocustódia e um sistema de hot wallet de exchange operam de maneiras muito diferentes.
No entanto, o EIP-7702 introduz uma lição importante também para usuários individuais:
Uma assinatura de delegação merece o mesmo nível de cautela que outras permissões poderosas de carteira.
Os usuários devem verificar cuidadosamente o que uma carteira está pedindo que assinem, especialmente quando um site desconhecido solicita uma delegação de conta.
Uma delegação maliciosa não deve ser confundida com uma assinatura comum de login.
Os usuários também devem confiar em interfaces de carteira consolidadas que identificam claramente solicitações de delegação e sinalizam contratos suspeitos.
O princípio fundamental de segurança permanece simples: não julgue uma assinatura apenas por ela transferir fundos imediatamente. Algumas assinaturas mudam o que uma conta terá permissão de fazer posteriormente.
A lição maior: a segurança de carteiras está indo além das chaves privadas
O incidente de segurança da Binance destaca uma evolução mais ampla na segurança da blockchain.
Durante anos, a suposição dominante do setor foi direta:
Proteja a chave, proteja a carteira.
Esse modelo está se tornando incompleto.
Carteiras institucionais modernas frequentemente dependem de camadas de infraestrutura ao redor da chave—APIs, serviços de assinatura, motores de saque, sistemas de políticas, controles de acesso e ambientes de execução automatizados.
Mecanismos de abstração de conta, como o EIP-7702, adicionam outra camada ao permitir que carteiras deleguem lógica de execução.
Como resultado, a segurança de criptomoedas depende cada vez mais de três questões separadas:
Quem controla a chave?
Quem pode solicitar uma assinatura?
E que autoridade essa assinatura realmente concede?
Um sistema pode ter sucesso na primeira questão e falhar na segunda ou na terceira.
Essa parece ser uma das questões mais importantes levantadas pela investigação da Binance até agora.
Perguntas frequentes
O EIP-7702 foi a causa do hack da Binance?
Não confirmado. As descobertas preliminares da Binance apontam para infraestrutura operacional comprometida, enquanto o EIP-7702 parece ter feito parte do caminho de autorização sob investigação.
As chaves privadas da Binance foram roubadas?
A Binance afirmou que não encontrou evidências de vazamento de chaves privadas da carteira em sua investigação inicial.
O que é o EIP-7702?
O EIP-7702 permite que uma EOA da Ethereum delegue lógica de execução a código de contrato inteligente, mantendo o mesmo endereço de carteira.
Por que várias autorizações EIP-7702 foram observadas?
Elas podem ter sido preparadas com diferentes valores de nonce para corresponder ao estado da conta de destino. Isso não significa necessariamente que várias carteiras foram comprometidas.
Os usuários comuns de Ethereum são afetados?
Não há evidências de um comprometimento de carteiras Ethereum em toda a rede. Os usuários ainda devem ter cautela com solicitações desconhecidas de delegação ou assinatura.
Revogar aprovações de tokens é suficiente?
Nem sempre. Aprovações ERC-20 e a delegação EIP-7702 são permissões separadas, portanto, remover uma aprovação de token não remove automaticamente a delegação da conta.
Conclusão
O aparecimento do EIP-7702 no incidente da Binance torna o mecanismo uma parte importante da investigação técnica, mas as evidências disponíveis não estabelecem que o próprio EIP-7702 tenha sido comprometido.
As descobertas preliminares da Binance, em vez disso, sugerem que um atacante pode ter comprometido o laptop de um engenheiro de DevOps, obtido acesso a um contêiner de serviço operacional e enviado transações de saque não autorizadas. A exchange afirma que não encontrou evidências de vazamento de chaves privadas de carteiras.
A distinção é importante.
Se um sistema de assinatura protegido puder ser induzido a autorizar instruções maliciosas, os atacantes podem não precisar roubar a chave privada de forma alguma.
O EIP-7702 pode aumentar as consequências de tal autorização porque permite que uma conta Ethereum delegue lógica de execução programável. Mas usar essa capacidade de forma maliciosa e encontrar uma vulnerabilidade no protocolo são duas coisas diferentes.
Até que a Binance divulgue seu post-mortem técnico completo, o EIP-7702 é melhor entendido como um componente no caminho de execução relatado — não como a causa raiz confirmada do incidente.
Para exchanges, provedores de custódia e desenvolvedores de carteiras, a lição maior já está clara: a segurança moderna de carteiras deve proteger não apenas as chaves privadas, mas também os sistemas que solicitam assinaturas e as permissões que essas assinaturas criam.
Aviso de Risco: Este artigo é apenas para fins informativos e educacionais. Criptomoedas e sistemas blockchain envolvem riscos técnicos, operacionais e de mercado. Os leitores devem verificar independentemente as informações de segurança e usar controles de risco apropriados ao gerenciar ativos digitais.
