EIP-7702: delegação de código em EOA e riscos

Uma EOA comum assina transações com uma chave privada e não tem código executável no próprio endereço. EIP-7702 permite que ela aponte para código já implantado em outro endereço. Quando uma operação alcança a conta delegada, o cliente carrega o código de destino e o executa no contexto da conta. O código fica em outro endereço, mas saldo, armazenamento e contexto de execução pertencem à conta que delegou.

Isso não transfere a conta para um novo endereço de contrato nem substitui a chave privada. Endereço e chave originais continuam os mesmos. Uma conta com marcador de delegação válido ainda pode iniciar transações comuns. O que muda é que chamadas podem executar lógica de conta; o padrão não divide automaticamente uma chave em funções mais seguras.

A especificação EIP-7702 define uma transação set-code tipo 4 e uma lista de autorizações. O guia Pectra do Ethereum.org também a descreve como um ponteiro para código já implantado. Uma etiqueta como “conta inteligente” na carteira não revela regras reais de validação, recuperação ou o código delegado.

Separe quem guarda a chave privada de quem implantou ou controla o código delegado. Confira se ele pode ser alterado, quem tem poder de atualização e o que pode fazer com ativos e armazenamento da conta. O próprio EIP não responde a essas questões de segurança.

A transação set-code é identificada pelo byte de tipo 0x04. Além dos campos normais da transação externa, ela inclui uma lista de autorizações. Cada tupla contém ID da chain, endereço do código, nonce da conta autorizadora e a assinatura que aprova a tupla. A autoridade assina a autorização; o remetente assina separadamente a transação externa. Os papéis podem pertencer à mesma conta ou a contas diferentes.

Como um remetente pode incluir a autorização válida de outra pessoa, confira exatamente o que a conta autorizadora está aprovando. O ID da chain normalmente limita a autorização a uma rede; o valor 0 permite um alcance mais amplo entre redes compatíveis. Isso não significa que a mesma autorização funcionará em qualquer lugar: a rede precisa suportar EIP-7702 e nonce e estado da conta precisam corresponder. Um alcance amplo pode, porém, permitir uso em outra rede compatível.

Uma tupla pode ser ignorada se o nonce não corresponder ou outra validação falhar. Um caractere errado no endereço de destino pode apontar para outro código. Compare rede, conta e endereço completo na tela de assinatura e em um explorador confiável. Um aviso vago de “atualização” ou “economia de gas” não explica a permissão concedida.

A documentação de transações do Ethereum.org descreve transações tipo 4 como portadoras de uma lista de autorizações. A transação externa ainda tem condições de gas e alguém que paga a taxa; ser enviada por outro endereço não torna a execução gratuita. Tipo 4 também é diferente de UserOperations e paymasters do ERC-4337, explicados no guia de contas inteligentes.

Depois de uma autorização válida, o código da EOA recebe um marcador formado pelo prefixo 0xef0100 e pelo endereço de destino. O cliente reconhece o marcador e carrega o código daquele endereço ao executar uma chamada. Assim, o endereço da conta mostrado na carteira pode ser diferente do endereço cujo código roda. Confira os dois.

O código é obtido da rede atual em que a delegação é usada. Um endereço de destino em outra rede não faz o código daquela rede executar aqui. O mesmo endereço de 20 bytes pode conter códigos diferentes, ou nenhum, em redes distintas. Confira implantação e código-fonte verificado em cada rede; nomes, ícones e endereços iguais não bastam.

O código delegado roda no contexto da conta autorizadora e pode usar seu armazenamento. Conforme a lógica, pode enviar ETH ou tokens, chamar contratos externos e mudar valores armazenados. EIP-7702 não acrescenta automaticamente regras como “somente este token” ou “uma chamada por dia”. Essas restrições precisam ser implementadas e impostas corretamente pelo sistema delegado.

Se o destino for um proxy ou puder receber atualizações, o código conferido hoje talvez não seja o código usado depois. Verifique administrador, poderes para trocar a implementação, atrasos e processo público de atualização. Um administrador desconhecido representa risco enquanto a delegação permanecer ativa.

O protocolo não limita automaticamente o código delegado a poucas permissões. Uma falha na validação pode permitir transferências, aprovações de tokens, chamadas externas arbitrárias ou mudanças no armazenamento. Um selo de auditoria não prova que o endereço e a versão exatos da solicitação correspondem ao código e ao escopo auditados.

As considerações de segurança do EIP alertam que a lógica delegada pode precisar vincular à assinatura proteção contra replay, destino e dados de chamada, valor em ETH e condições de gas. Se campos importantes faltarem, um patrocinador ou outra pessoa pode enviar uma solicitação diferente da intenção do signatário ou provocar uma falha. Confira quais chamadas o código valida e se terceiros podem contornar essas verificações.

Por exemplo, a carteira pode agrupar aprovação de token e troca em uma confirmação. Verifique se as operações são revertidas juntas, se a aprovação se limita ao valor necessário e se pode ser reduzida depois. Se um paymaster pagar as taxas, confira quem paga e em quais condições. Leia a prévia completa para que o rótulo “grátis” não esconda as chamadas e permissões autorizadas.

A segurança depende das permissões reais e do controle de atualização, não apenas da reputação do destino. Confira quais contratos a conta pode chamar, como as assinaturas são validadas, quem tem poderes de emergência ou atualização e se o código implantado corresponde à fonte verificada. Se o endereço for desconhecido ou vier de mensagem não solicitada, pare e consulte a documentação oficial da carteira.

EIP-7702 processa a lista de autorizações antes da execução da transação externa. A especificação diz que marcadores de delegação já processados não são revertidos quando a execução posterior falha ou dá revert. Não presuma que todo o estado volta ao início só porque o recibo indica falha. Confira o recibo e o código atual da conta separadamente.

Isso importa para chamadas agrupadas, inicialização e transações enviadas por patrocinador. A autorização pode ser válida enquanto uma chamada posterior falha: a delegação continua ativa embora a configuração ou ação esperada não tenha terminado. Se a própria tupla não era válida, talvez não tenha sido aplicada. Confira a transação tipo 4, a conta autorizadora, o nonce e o ponteiro de código atual, em vez de confiar em um único rótulo de sucesso ou falha.

O status “falhou” da carteira pode resumir uma falha na autorização, chamada externa ou outra etapa. Se não estiver claro, compare o hash da transação, a autoridade e o nonce assinados e o código da conta usando uma ferramenta confiável da rede. Uma nova tentativa pode encontrar um nonce alterado e invalidar a autorização anterior; verifique antes se houve envio duplicado ou já processado.

Essa diferença importa quando se espera que todos os passos de uma confirmação sejam desfeitos juntos. Testar em uma conta de teste ou de baixo valor mostra o comportamento, mas não comprova segurança do código. Antes de usar conta com fundos, saiba verificar escopo da chain, destino, dados de chamada e estado que pode permanecer após falha.

Uma nova autorização pode apontar para outro código. O EIP também define limpar o marcador por meio de autorização ao endereço nulo, deixando vazio o código da conta. Isso remove o marcador de delegação; não é um comando geral de limpeza ou recuperação.

Se o código delegado gravou valores no armazenamento da conta, limpar o marcador não os apaga automaticamente. Uma autorização de token registrada por contrato ERC-20 também é separada do código da conta. Uma aprovação ilimitada anterior talvez precise ser revogada no contrato do token. Limpar a delegação não desfaz tokens já enviados, mudanças em contratos externos ou transações concluídas.

O novo código pode reutilizar o armazenamento da conta. Se duas versões interpretarem os mesmos espaços de forma diferente, pode haver conflito. Confira o layout e o plano de migração antes de trocar. Sem compatibilidade, a conta pode travar ou o estado anterior se comportar de forma inesperada; o protocolo não oferece limpeza geral de armazenamento ao mudar o ponteiro.

Escolha a resposta conforme o problema. Se o código parecer malicioso, avalie rapidamente um fluxo de limpeza compatível com a carteira ou uma substituição confiável. Para permissões de token, consulte o guia de aprovações e allowances. Se chave ou frase-semente vazou, limpar o código não recupera a chave; siga o guia de recuperação da carteira e considere transferir ativos para uma conta segura.

Primeiro confirme na documentação oficial da carteira que ela aceita EIP-7702 na rede escolhida. Compare rede e ID da chain, conta, endereço exato de destino, código verificado e administradores de proxy ou atualização. Entenda se ID 0 amplia o escopo para outras redes ou se a assinatura fica limitada a uma. Se a tela de assinatura não estiver clara, consulte a documentação antes de aprovar.

Depois, diferencie assinatura de autorização, remetente da transação externa e pagador da taxa. Um remetente diferente não muda o que a conta autorizadora assinou. Patrocínio também não torna o código seguro nem limita chamadas ao esperado. Compare tipo de transação, lista de autorizações, destinos e dados de chamada e qualquer mudança de allowance com a prévia.

Se já houver delegação ativa, não confira apenas se a transação foi bem-sucedida. Inspecione o marcador atual e o endereço do código. Se forem diferentes do esperado, pare chamadas e aprovações adicionais e evite repetir autorizações de substituição aleatórias. Para taxas externas, veja o guia de taxas de gas do Ethereum; para nonce e transações pendentes de EOA, o guia de transações pendentes.

EIP-7702 padroniza um formato de transação que conecta uma EOA a código implantado. Agrupamento de chamadas, taxas patrocinadas, permissões de sessão e recuperação podem ser construídos sobre o mecanismo, mas dependem de códigos e serviços específicos. Nem toda carteira ou delegação usa as mesmas regras ou oferece os mesmos recursos.

Ver “conta inteligente” na interface não informa quem tem a chave, quem pode atualizar o código ou quem altera a recuperação. Confira implementação e configuração reais. Se a carteira não aceitar a rede ou o recurso, pode mostrar a delegação de forma diferente do esperado. Confirme a compatibilidade antes de mudar uma conta com fundos.

O anúncio da rede principal Pectra da Ethereum Foundation descreve EOA apontando para código delegado e a possibilidade de substituir ou revogar a autorização. As capacidades do padrão e a forma como uma carteira as apresenta são questões diferentes. UserOperations e paymasters do ERC-4337 são outro caminho de abstração de conta, não a própria autorização tipo 4.

Este guia explica a mecânica da conta e não recomenda uma carteira ou delegação específica. Defina primeiro o objetivo — agrupar chamadas, patrocinar taxas, usar permissões de sessão ou recuperar acesso — e identifique o código e serviço que implementam o recurso e o nível de confiança necessário. O guia de contas inteligentes e ERC-4337 cobre mecanismos relacionados.