Como é que o EIP-7702 afeta a segurança das carteiras? Compreender os riscos da delegação e do roubo de ativos

Última atualização 30-10-2026 13:22:19
Tempo de leitura: 6m
Explore de que forma o EIP-7702 altera a segurança das carteiras Ethereum, incluindo a delegação de contas, as autorizações maliciosas, os riscos de roubo de ativos e as formas de proteger os fundos.

A EIP-7702 é uma importante melhoria de protocolo no desenvolvimento da abstração de contas do Ethereum. Permite que carteiras EOA tradicionais deleguem a lógica de execução de contratos inteligentes através de autorização, permitindo que endereços comuns suportem transações em lote, patrocínio de gas e uma gestão de contas mais flexível. Ao contrário da criação de uma carteira de contrato inteligente inteiramente nova, a EIP-7702 preserva os endereços e ativos de carteira existentes dos utilizadores, alterando simultaneamente a forma como a conta executa transações.

No entanto, a expansão das capacidades das contas também altera o limite de segurança. No passado, os utilizadores concentravam-se sobretudo em saber se as suas chaves privadas tinham sido expostas, se as permissões de Approve de tokens estavam definidas demasiado altas e se as assinaturas de transações continham transferências anormais. A EIP-7702 introduz outro tipo de operação que os utilizadores precisam de compreender: através de uma única autorização, os utilizadores podem permitir que o seu endereço execute código de contrato especificado em transações subsequentes. Se esse código for malicioso ou se a delegação for controlada por um atacante, os riscos para os ativos podem ir além de uma única transação.

Por conseguinte, compreender a EIP-7702 exige mais do que centrar a atenção na experiência de abstração de contas que proporciona. É também necessário analisar como a autorização de delegação produz efeitos, que operações o código malicioso pode realizar e como os utilizadores comuns podem identificar e remover delegações perigosas. Este artigo aborda os princípios técnicos, as potenciais vias de ataque e as práticas de segurança de carteiras relacionadas com a EIP-7702.

Pontos principais

  • A EIP-7702 é uma funcionalidade de conta introduzida com a atualização Pectra do Ethereum. Permite que contas pertencentes externamente (Externally Owned Accounts, ou EOA) tradicionais executem lógica de contratos inteligentes através de delegação, sem exigir a transferência de ativos para um novo endereço.

  • A autorização EIP-7702 difere do Approve ERC-20 comum. A primeira pode alterar a lógica de execução de uma conta, enquanto o segundo geralmente concede a um gastador permissão para utilizar uma determinada quantidade de tokens.

  • O risco de uma delegação maliciosa não resulta necessariamente da exposição da chave privada. Mesmo que os utilizadores mantenham as suas chaves privadas, assinar uma autorização de delegação perigosa pode colocar os seus ativos em risco.

  • Uma delegação EIP-7702 não caduca automaticamente após a conclusão de uma única transação. A revogação ou substituição de uma delegação exige uma nova autorização válida, e a limpeza de uma delegação não permite recuperar ativos que já tenham sido transferidos.

  • Avaliar a segurança da EIP-7702 exige mais do que verificar a origem de uma assinatura. Exige também compreender as permissões, o comportamento do código e as capacidades de atualização do contrato delegado.

O que é a EIP-7702? Porque precisam as carteiras EOA tradicionais de execução delegada?

As contas Ethereum dividem-se principalmente em contas pertencentes externamente (Externally Owned Accounts, ou EOA) e contas de contratos inteligentes. As EOA são controladas por chaves privadas e podem iniciar transações. As contas de contratos inteligentes executam operações de acordo com o código implementado e podem suportar controlos de permissões e lógica de transações mais complexos.

As EOA tradicionais oferecem uma estrutura simples e ampla compatibilidade, mas as suas capacidades de execução são limitadas. Por exemplo, os utilizadores podem ter de assinar várias transações separadamente para concluir um conjunto de operações on-chain ou deter ETH para pagar as taxas de gas da rede. As carteiras de contratos inteligentes podem melhorar estas experiências, mas envolvem frequentemente a implementação de uma nova conta, a migração de ativos e requisitos adicionais de compatibilidade.

A EIP-7702 fornece uma solução diferente: permite que uma EOA delegue a execução do código da conta à lógica de um contrato inteligente num endereço especificado através de autorização. Os utilizadores podem aceder a algumas funcionalidades de contas inteligentes a partir do seu endereço de carteira existente, sem o alterar.

Ao nível do protocolo, a EIP-7702 introduz um novo tipo de transação e uma lista de autorizações. Uma autorização elegível pode definir o campo de código de uma EOA para um indicador de delegação especial que aponta para um endereço de contrato especificado. Quando outra transação chama essa conta, o Ethereum executa o código delegado de acordo com as regras relevantes.

Este design proporciona aos produtos de carteira uma maior flexibilidade para suportar operações em lote, validação flexível de transações, patrocínio de gas e gestão de permissões baseada em contratos. No entanto, a EIP-7702 não fornece automaticamente todas estas capacidades. A funcionalidade específica continua a depender da forma como o contrato delegado é implementado.

Como funciona a EIP-7702? Qual é a relação entre a assinatura de autorização e o contrato delegado?

A ideia central da EIP-7702 é separar a propriedade da conta da lógica de execução do código. Os utilizadores continuam a controlar as suas EOA através das chaves privadas existentes, mas podem utilizar uma autorização compatível com o protocolo para especificar o código de contrato que o endereço deve utilizar.

Os dados de autorização incluem normalmente o ID da cadeia, o endereço de destino da delegação, o nonce da conta e uma assinatura gerada pela chave privada da conta. Quando a rede processa uma transação que contém uma lista de autorizações, verifica a autorização e atualiza o estado de delegação da conta correspondente de acordo com as regras do protocolo.

Um processo típico de delegação EIP-7702 é composto por quatro fases:

  1. Selecionar o destino da delegação: a carteira ou aplicação determina o endereço de implementação do contrato inteligente que precisa de utilizar.

  2. Gerar a assinatura de autorização: o utilizador assina dados de autorização para o destino de delegação especificado com a chave privada da EOA.

  3. Processar a autorização on-chain: a autorização é incluída numa transação compatível com a EIP-7702. Após a verificação, a rede define o indicador de delegação da conta.

  4. Executar o código delegado: quando a conta é chamada posteriormente, o código do contrato de implementação especificado é executado de acordo com as regras da EIP-7702.

É necessário distinguir dois conceitos facilmente confundidos: uma assinatura de autorização não é exatamente o mesmo que uma assinatura de transação comum. Uma assinatura de transferência comum é geralmente utilizada para aprovar uma transação específica, enquanto uma autorização EIP-7702 define a implementação de código utilizada por uma conta. Pode afetar o comportamento de execução de várias transações subsequentes.

O endereço de destino da delegação não significa que o utilizador tenha fornecido a sua chave privada a esse endereço, nem que o proprietário desse endereço obtenha automaticamente permissão para transferir ativos. O risco real depende da forma como o código delegado processa a validação de transações, os pontos de entrada de execução e o controlo de acesso. Se o código permitir que um atacante execute operações sobre ativos sem autorização adicional do proprietário da conta, uma delegação perigosa pode tornar-se um ponto de entrada para o roubo de ativos.

Como funciona a EIP-7702? Qual é a relação entre a assinatura de autorização e o contrato delegado?

Em que difere a EIP-7702 do Approve ERC-20?

Nas transações DeFi tradicionais, os utilizadores recorrem frequentemente ao Approve ERC-20 para autorizar uma bolsa descentralizada ou outro contrato inteligente a utilizar um token específico. Por exemplo, um utilizador pode permitir que um contrato gaste até 100 USDC. Esta autorização é geralmente registada pelo contrato do token e controla a quantidade de tokens que um gastador específico pode utilizar.

A EIP-7702 funciona a um nível de autorização diferente. Não se limita a aprovar que um contrato gaste uma quantidade específica de tokens. Em vez disso, especifica qual o código de contrato inteligente que a conta executa. O código delegado pode incluir validação de transações, transferências de ativos, chamadas em lote e outras funções de gestão de contas, pelo que o seu potencial âmbito de impacto pode ser mais amplo.

Dimensão de comparação Approve ERC-20 Delegação EIP-7702
Função principal Autoriza um gastador a utilizar tokens Especifica o código de contrato executado pela conta
Âmbito da permissão Token específico e montante de autorização Depende da implementação do código delegado
Parte autorizada Endereço do gastador Endereço do contrato de implementação delegado
Afeta a lógica de execução da conta? Normalmente, não Sim
Como é revogada? Ajustar ou limpar a autorização do token Substituir ou limpar a delegação através de uma autorização válida
Risco principal A autorização do token pode ser utilizada indevidamente O código malicioso pode afetar os ativos e as operações da conta

Uma delegação EIP-7702 não significa que a propriedade da carteira seja transferida diretamente para um contrato. Uma implementação de delegação segura pode continuar a exigir uma assinatura válida do proprietário da conta e impor limites de transação, restrições temporais e outras medidas de proteção.

No entanto, se um utilizador autorizar um contrato malicioso, a sua lógica interna poderá permitir que um atacante execute operações que o utilizador não tencionava aprovar. Por conseguinte, em comparação com as autorizações Approve comuns, as verificações de segurança da EIP-7702 devem concentrar-se mais atentamente no próprio código do contrato, e não apenas no montante da autorização.

Como pode uma autorização EIP-7702 maliciosa conduzir ao roubo de ativos de uma carteira?

Um dos principais riscos de segurança da EIP-7702 é a possibilidade de os atacantes utilizarem phishing de assinaturas para induzir os utilizadores a aprovar delegações maliciosas. Os atacantes podem apresentar um pedido de autorização como uma atualização de carteira, verificação de conta, reivindicação de recompensa ou otimização de transação, levando os utilizadores a acreditar que estão a concluir uma assinatura comum.

Assim que um utilizador assina uma autorização válida que aponta para um contrato malicioso, o atacante pode submetê-la on-chain. É importante salientar que a própria assinatura de autorização não altera necessariamente o estado da conta de imediato. A delegação só produz efeitos on-chain depois de a autorização relevante ser incluída numa transação válida e passar na verificação.

Se o código delegado incluir uma função de transferência de ativos que um atacante possa chamar, o atacante poderá utilizar essa lógica de execução para transferir ETH ou outros tokens da conta.

Uma via de risco típica pode ser resumida da seguinte forma:

  1. Induzir uma assinatura: o atacante obtém a autorização do utilizador para um destino de delegação malicioso através de um site falso ou da interface de uma aplicação.

  2. Submeter a autorização: o atacante ou outro remetente de transação submete a autorização válida a uma rede compatível com a EIP-7702.

  3. Definir a delegação: depois de verificar a autorização, a rede faz com que a conta afetada execute o código de contrato especificado.

  4. Acionar lógica maliciosa: o atacante chama um ponto de entrada de execução explorável no código malicioso.

  5. Transferir ativos: a lógica maliciosa realiza transferências, operações com tokens ou outras ações perigosas no contexto da conta.

Como pode uma autorização EIP-7702 maliciosa conduzir ao roubo de ativos de uma carteira?

O perigo deste tipo de ataque reside no facto de os utilizadores poderem ver apenas um único pedido de assinatura sem perceber que este pode alterar a forma como a conta executa transações subsequentes.

Em 30 de outubro de 2026, ocorreu um incidente de segurança grave envolvendo carteiras quentes relacionadas com a Binance. A análise de incidente da TRM Labs concluiu que os atacantes utilizaram a delegação EIP-7702 na rede Ethereum para ligar as carteiras quentes relevantes a código de execução malicioso. Também observou transferências anormais de fundos noutras blockchains. Diferentes análises de segurança ainda contêm detalhes sobre a dimensão do ataque, a forma como as assinaturas foram obtidas e a via de intrusão inicial que exigem verificação adicional.

Este incidente demonstra que a EIP-7702 pode servir de infraestrutura para a automatização normal de carteiras, mas também pode ampliar as consequências da perda de controlo sobre os sistemas de autorização ou assinatura. No entanto, não prova que o próprio protocolo EIP-7702 contenha uma vulnerabilidade que permita a atacantes arbitrários contornar a verificação de assinaturas.

Porque podem os atacantes transferir ativos mesmo quando a chave privada do utilizador não foi exposta?

A educação tradicional sobre segurança de carteiras costuma enfatizar a proteção de frases-semente e chaves privadas, porque um atacante que obtenha uma chave privada pode forjar uma assinatura válida do proprietário da conta. No entanto, em cenários de interação com contratos inteligentes, a ausência de exposição da chave privada não garante que os ativos estejam seguros.

A razão é que os utilizadores podem assinar voluntariamente autorizações com consequências perigosas. No caso da EIP-7702, um atacante não necessita necessariamente de obter a chave privada diretamente. Se o atacante conseguir induzir o utilizador a assinar uma autorização de delegação maliciosa válida e satisfizer as condições para a execução on-chain, poderá conseguir influenciar o comportamento subsequente da conta.

Este risco é semelhante ao phishing de assinaturas tradicional, mas o alvo expandiu-se de uma única transação ou de uma autorização de token específica para a lógica de execução da conta.

Os atacantes também podem visar os sistemas de assinatura, os processos de aprovação de permissões ou os terminais operativos das carteiras empresariais. Se um sistema de assinatura for induzido a gerar uma autorização válida que não corresponde ao objetivo comercial pretendido, podem ocorrer consequências graves, mesmo que a chave privada subjacente não tenha sido diretamente exposta.

Por conseguinte, a segurança da carteira não pode depender exclusivamente da proteção da chave privada. O próprio processo de assinatura também tem de ser protegido. Os utilizadores precisam de saber se estão a assinar uma transferência comum, uma autorização de token ou uma delegação de código que possa afetar o comportamento da conta durante um período prolongado.

No caso das carteiras institucionais, as políticas de assinatura, as listas de permissões de contratos, as aprovações multipartidárias e a simulação de transações também têm de abranger as autorizações EIP-7702, em vez de dependerem apenas das verificações tradicionais do montante da transferência.

Uma delegação EIP-7702 caduca automaticamente? Como podem ser verificadas e revogadas autorizações de risco?

Uma característica importante da EIP-7702 é que o estado de delegação não é automaticamente limpo quando a transação que o define é concluída.

Depois de uma conta definir uma delegação com êxito, o indicador de código relevante geralmente mantém-se até que uma nova autorização válida o substitua ou limpe. Isto significa que a delegação pode permanecer ativa mesmo depois de o utilizador fechar o site, desligar a carteira ou concluir a transação original.

Ao nível do protocolo, os utilizadores podem utilizar uma nova autorização válida para definir o destino da delegação como o endereço zero, limpando assim o indicador de delegação EIP-7702. Os utilizadores também podem voltar a autorizar um contrato de implementação fidedigno, quando adequado.

Os passos seguintes podem ser utilizados para verificar e gerir uma delegação:

  1. Consultar o estado do código da conta: utilizar um explorador de blocos ou uma ferramenta de segurança de carteira fidedigna para confirmar se o endereço possui uma delegação EIP-7702.

  2. Verificar o contrato de destino: confirmar se a delegação aponta para o mesmo contrato de implementação publicado pelo produto de carteira utilizado.

  3. Avaliar o risco do contrato: verificar se o código foi auditado, se possui privilégios de administrador, se pode ser atualizado e se permite que terceiros realizem operações sobre ativos.

  4. Limpar uma delegação anormal: depois de confirmar o processo e as condições da rede, utilizar uma ferramenta fidedigna para submeter uma nova autorização válida que limpe ou substitua a delegação perigosa.

  5. Verificar riscos relacionados: verificar também as autorizações ERC-20, os registos de transações anormais e o estado da conta noutras cadeias.

Ao consultar o código de uma conta com uma delegação EIP-7702, os utilizadores podem ver um indicador especial que começa por 0xef0100, seguido do endereço de destino da delegação. Este é um método de identificação ao nível do protocolo. No entanto, os utilizadores comuns não precisam de analisar dados hexadecimais brutos por si próprios. Podem utilizar uma ferramenta fidedigna que apresente corretamente o estado da EIP-7702.

É importante salientar que revogar uma delegação não restaura ativos nem garante que a conta esteja totalmente segura. Se a chave privada, o dispositivo de assinatura ou o ambiente operativo já tiverem sido comprometidos, a limpeza da delegação, por si só, poderá não ser suficiente. No caso de uma conta suspeita de estar comprometida, deve ser considerada a interrupção da utilização do ambiente de assinatura relevante e, depois de garantir que é seguro fazê-lo, a transferência dos ativos restantes.

Em que difere o modelo de segurança da EIP-7702 das contas inteligentes ERC-4337?

A EIP-7702 e a ERC-4337 estão ambas relacionadas com a abstração de contas Ethereum, mas abordam o problema de formas diferentes.

A ERC-4337 utiliza componentes como UserOperation, Bundler e EntryPoint para fornecer uma estrutura de execução de transações para contas de contratos inteligentes, sem depender de EOA tradicionais para iniciar diretamente todas as operações. As regras de validação e execução da conta são implementadas por contratos inteligentes.

A EIP-7702 aborda principalmente a forma como as EOA tradicionais podem obter capacidades de execução de contratos inteligentes. Permite que os endereços existentes deleguem a execução de código de contratos, reduzindo a barreira para os utilizadores que pretendem adotar a funcionalidade de contas inteligentes.

Dimensão de comparação EIP-7702 ERC-4337
Objetivo principal Adicionar capacidades de execução de código às EOA existentes Fornecer uma estrutura operacional para contas de contratos inteligentes
Forma da conta Mantém o endereço EOA existente Utiliza normalmente uma conta de contrato inteligente
Mecanismo central Autorização de delegação ao nível do protocolo UserOperation e EntryPoint
Foco de segurança Destino da delegação e assinatura de autorização Lógica de validação da conta e permissões de execução
Relação entre ambas Podem ser utilizadas em conjunto Pode integrar-se com a EIP-7702

As duas não são substitutos completos uma da outra. Algumas arquiteturas de carteira podem utilizar a EIP-7702 para fornecer capacidades de execução de código às EOA existentes e, em seguida, combiná-la com a infraestrutura ERC-4337 para proporcionar uma experiência de conta inteligente mais abrangente.

Do ponto de vista da segurança, a EIP-7702 exige atenção a delegações maliciosas e engano por assinatura. A ERC-4337 exige atenção à lógica de validação de contratos de conta, aos módulos de execução, às permissões de atualização e aos riscos de infraestrutura relacionados. A segurança real depende da implementação específica, e não apenas da norma adotada.

Como podem os utilizadores comuns proteger-se contra phishing de assinaturas EIP-7702?

Para os utilizadores comuns, a chave para gerir os riscos da EIP-7702 não é evitar inteiramente a funcionalidade de contas inteligentes, mas reconhecer as alterações de permissões representadas por diferentes assinaturas.

  1. Os utilizadores devem distinguir entre assinaturas de transações, assinaturas de mensagens, autorizações de tokens e delegações de contas. Se a interface da carteira apresentar EIP-7702, Delegation, Set Code ou um aviso semelhante, deve confirmar-se que a operação necessita realmente de alterar a lógica de execução da conta.

  2. Deve ser dada especial atenção ao endereço de destino da delegação. Uma atualização normal de uma funcionalidade de carteira pode exigir a definição de um contrato de implementação de conta inteligente verificado, mas os utilizadores devem manter-se cautelosos quando um site desconhecido solicita a delegação para um endereço desconhecido. Mesmo que o código-fonte de um contrato esteja disponível publicamente, isso não significa necessariamente que a sua conceção de permissões seja segura.

  3. A credibilidade de um pedido de autorização não deve ser avaliada apenas pelo nome do site, pelo design da interface ou por uma ligação de redes sociais. Os atacantes podem utilizar páginas falsas de atualização de carteiras, anúncios de pesquisa ou páginas de frontend comprometidas para induzir os utilizadores a assinar.

  4. Sempre que possível, utilizar ferramentas de carteira que apresentem claramente o conteúdo da autorização e forneçam simulação de transações e alertas de risco. Se um dispositivo de assinatura apresentar apenas dados brutos que o utilizador não consegue compreender, deve evitar-se assinar sem confirmar o conteúdo.

  5. Considerar a segregação de contas com base no montante de ativos e nos cenários de utilização. Manter as detenções de longo prazo separadas das carteiras utilizadas para interações DeFi frequentes, airdrops ou novas aplicações pode reduzir, em certa medida, o potencial impacto de uma única autorização maliciosa.

É importante salientar que as carteiras de hardware podem melhorar a proteção da chave privada, mas não conseguem determinar automaticamente se uma delegação ativamente aprovada pelo utilizador é segura. A assinatura segura continua a exigir uma apresentação de informações fiável e uma avaliação informada por parte do utilizador.

O que significa a EIP-7702 para o futuro da segurança das carteiras e da abstração de contas?

A EIP-7702 desloca as contas Ethereum do modelo de execução relativamente fixo das EOA para contas programáveis mais flexíveis. Para os programadores de carteiras, isto significa que podem fornecer transações em lote, patrocínio de gas, gestão de permissões e execução automatizada, mantendo simultaneamente os endereços existentes.

No entanto, quanto maior for a capacidade de programação da conta, mais precisas terão de ser as verificações de segurança. No passado, os alertas de risco das carteiras centravam-se sobretudo nos destinos de transferências, montantes de transações e montantes de autorizações de tokens. No futuro, terão também de apresentar com precisão os destinos de delegação, as regras de validação dos contratos, as permissões de execução e os potenciais efeitos a longo prazo.

Do ponto de vista da conceção de produtos, as práticas de segurança da EIP-7702 podem desenvolver-se em três direções.

  • Transparência das autorizações. As carteiras precisam de ajudar os utilizadores a compreender o que uma delegação vai alterar, em vez de apresentarem simplesmente um endereço de contrato.

  • Privilégio mínimo. Os contratos delegados podem reduzir potenciais perdas através de controlos de acesso rigorosos, limites, períodos de caducidade e múltiplos mecanismos de verificação. No entanto, estas restrições têm de ser aplicadas de forma fiável pelo código efetivamente utilizado, em vez de dependerem apenas de apresentações no frontend.

  • Monitorização contínua de riscos. Uma vez que as delegações podem manter-se durante um período prolongado, as ferramentas de segurança de carteiras têm de suportar a deteção de delegações anormais, alterações no código dos contratos e operações suspeitas da conta, em vez de verificarem apenas no momento da assinatura inicial.

A importância da EIP-7702 não reside apenas na melhoria da experiência de carteira, mas também na expansão da segurança das contas para além da proteção tradicional de chaves privadas, abrangendo a gestão integrada da intenção de assinatura, da execução de código e das permissões contínuas.

Resumo

A EIP-7702 introduz capacidades de delegação de contratos inteligentes nas EOA Ethereum tradicionais, permitindo que os utilizadores acedam a funções de execução de contas mais flexíveis, mantendo os endereços de carteira existentes. Este mecanismo fornece uma nova base técnica para a abstração de contas, mas também altera o limite de segurança das carteiras tradicionais.

Ao contrário do Approve ERC-20, que controla principalmente autorizações de gasto de tokens, a autorização EIP-7702 pode alterar o código de contrato executado por uma conta. Se um utilizador assinar uma delegação maliciosa, um atacante poderá utilizar uma lógica de execução insegura para transferir ativos sem necessariamente obter diretamente a chave privada do utilizador.

Por conseguinte, avaliar se a EIP-7702 é segura exige mais do que verificar se a autorização foi assinada pelo utilizador. Exige também verificar o destino da delegação, as permissões do contrato, a origem da assinatura e o comportamento de execução subsequente. À medida que a funcionalidade de contas inteligentes for mais amplamente adotada, compreender a delegação de código e a gestão de permissões tornar-se-á uma parte importante da educação sobre segurança de carteiras.

Perguntas frequentes

O que é a EIP-7702?

A EIP-7702 é uma melhoria do protocolo Ethereum que permite que as EOA tradicionais deleguem a execução de código de contratos inteligentes através de autorização, fornecendo algumas funcionalidades de conta inteligente.

A EIP-7702 pode esvaziar automaticamente uma carteira?

Não. A EIP-7702 não é, por si só, uma funcionalidade que roube ativos automaticamente. Os principais riscos resultam de autorizações maliciosas, código delegado inseguro ou sistemas de assinatura comprometidos.

A autorização EIP-7702 é igual ao Approve ERC-20?

Não. O Approve ERC-20 geralmente concede a um endereço específico uma autorização para utilizar tokens, enquanto a autorização EIP-7702 especifica o código de contrato executado por uma conta. Os níveis de permissão são diferentes.

Uma delegação EIP-7702 pode ser revogada?

Sim. O proprietário da conta pode utilizar uma nova autorização válida para limpar ou substituir a delegação. No entanto, se a chave privada ou o ambiente de assinatura tiverem sido comprometidos, a revogação da delegação, por si só, não pode garantir a segurança.

Uma carteira de hardware pode impedir phishing EIP-7702?

Não completamente. Uma carteira de hardware ajuda a proteger a chave privada, mas os utilizadores podem continuar expostos a riscos para os ativos se confirmarem uma autorização maliciosa no dispositivo.

Como saber se uma carteira possui uma delegação EIP-7702?

É possível utilizar um explorador de blocos ou uma ferramenta de segurança compatível com a EIP-7702 para consultar o código da conta e o destino da delegação. Se for encontrado um endereço de delegação desconhecido, deve verificar-se a sua origem e permissões.

Autor: Learn Team
Exclusão de responsabilidade

* As informações não se destinam a ser e não constituem aconselhamento financeiro ou qualquer outra recomendação de qualquer tipo oferecido ou endossado pela Gate.

* Este artigo não pode ser reproduzido, transmitido ou copiado sem fazer referência à Gate. A violação é uma violação da Lei de Direitos de Autor e pode estar sujeita a ações legais.

Artigos relacionados

Modelo Económico do Token ONDO: De que forma impulsiona o crescimento da plataforma e o envolvimento dos utilizadores?
Principiante

Modelo Económico do Token ONDO: De que forma impulsiona o crescimento da plataforma e o envolvimento dos utilizadores?

ONDO é o token central de governança e captação de valor do ecossistema Ondo Finance. Tem como objetivo principal potenciar mecanismos de incentivos em token para integrar, de forma fluida, os ativos financeiros tradicionais (RWA) no ecossistema DeFi, impulsionando o crescimento em larga escala da gestão de ativos on-chain e dos produtos de retorno.
27-03-2026 13:52:50
Morpho vs. Aave: Análise aprofundada das diferenças de mecanismo e estrutura nos protocolos de empréstimos DeFi
Principiante

Morpho vs. Aave: Análise aprofundada das diferenças de mecanismo e estrutura nos protocolos de empréstimos DeFi

A principal distinção entre o Morpho e o Aave está no mecanismo de empréstimos. O Aave opera com um modelo de pool de liquidez, enquanto o Morpho baseia-se neste sistema ao implementar uma correspondência peer-to-peer (P2P), o que permite um alinhamento superior das taxas de juros dentro do mesmo mercado. O Aave funciona como protocolo nativo de empréstimos, fornecendo liquidez de base e taxas de juros estáveis. Em contrapartida, o Morpho atua como uma camada de otimização, aumentando a eficiência do capital ao estreitar o spread entre as taxas de depósito e de empréstimo. Em suma, a diferença fundamental é que o Aave oferece infraestrutura central, enquanto o Morpho é uma ferramenta de otimização da eficiência.
03-04-2026 13:09:48
Análise de tokenomics do JTO: distribuição, casos de utilização e valor de longo prazo
Principiante

Análise de tokenomics do JTO: distribuição, casos de utilização e valor de longo prazo

O JTO é o token de governança nativo da Jito Network. No centro da infraestrutura de MEV do ecossistema Solana, o JTO confere direitos de governança e garante o alinhamento dos interesses de validadores, participantes de staking e searchers, através dos retornos do protocolo e dos incentivos do ecossistema. A oferta fixa de 1 mil milhão de tokens procura equilibrar as recompensas de curto prazo com o desenvolvimento sustentável a longo prazo.
03-04-2026 14:07:21
Tokenomics da Morpho: Utilidade, distribuição e proposta de valor do MORPHO
Principiante

Tokenomics da Morpho: Utilidade, distribuição e proposta de valor do MORPHO

O MORPHO é o token nativo do protocolo Morpho, criado essencialmente para a governança e incentivos do ecossistema. Ao organizar a distribuição do token e os mecanismos de incentivo, o Morpho assegura o alinhamento entre a atividade dos utilizadores, o crescimento do protocolo e a autoridade de governança, promovendo um modelo de valor sustentável no ecossistema descentralizado de empréstimos.
03-04-2026 13:13:47
Jito vs Marinade: Análise comparativa dos protocolos de Staking de liquidez na Solana
Principiante

Jito vs Marinade: Análise comparativa dos protocolos de Staking de liquidez na Solana

Jito e Marinade são os principais protocolos de liquid staking na Solana. O Jito potencia os retornos através do MEV (Maximum Extractable Value), tornando-se a escolha ideal para quem pretende obter rendimentos superiores. O Marinade proporciona uma solução de staking mais estável e descentralizada, indicada para utilizadores com menor apetência pelo risco. A diferença fundamental entre ambos está nas fontes de ganhos e na estrutura global de risco.
03-04-2026 14:06:00
Zcash vs Monero: análise comparativa dos percursos técnicos de duas moedas de privacidade
Intermediário

Zcash vs Monero: análise comparativa dos percursos técnicos de duas moedas de privacidade

Zcash e Monero são criptomoedas orientadas para a privacidade on-chain, adotando abordagens técnicas essencialmente diferentes. Zcash utiliza provas de conhecimento zero zk-SNARKs para viabilizar transações "verificáveis mas invisíveis", ao passo que Monero recorre a assinaturas de anel e mecanismos de ofuscação para garantir um modelo de transação "anónimo por defeito". Estas distinções conferem características exclusivas a cada uma, impactando os respetivos métodos de implementação de privacidade, rastreabilidade, arquitetura de desempenho e capacidade de adaptação às exigências de conformidade regulatória.
14-05-2026 10:51:14