No mundo das blockchains, os usuários frequentemente precisam conceder permissões (autorizações) que permitem que contratos inteligentes gastem tokens em seu nome. Por exemplo, ao usar uma exchange descentralizada (DEX) para trocar tokens, um usuário deve primeiro autorizar o contrato da exchange a transferir uma quantidade específica de tokens de sua carteira. Sob oERC-20Padrão, esse processo requer duas transações separadas na cadeia: uma para aprovação e outra para a transferência real do token. Esse processo de duas etapas não só é trabalhoso, mas também incorre em taxas de gás adicionais. Para melhorar tanto a experiência do usuário quanto a segurança, a comunidade Ethereum introduziu um mecanismo de autorização baseado em assinatura.Permissão(como EIP-2612), e posteriormente desenvolveu uma versão avançada chamada Permit2. Esses novos mecanismos permitem que os usuários concedam aprovações de token por meio de assinaturas off-chain, evitando a necessidade de transações adicionais on-chain.

Neste artigo, começaremos com o básico explicando como funcionam as aprovações tradicionais ERC-20 e suas limitações. Em seguida, mergulharemos em como o Permit e o Permit2 funcionam, destacando seus benefícios e compensações, e discutiremos como eles melhoram tanto a eficiência quanto a segurança. Também examinaremos possíveis riscos de segurança, especialmente ataques de phishing envolvendo assinaturas maliciosas, e oferecer dicas para se manter seguro. Se você é novo no blockchain ou está apenas começando sua jornada de investimento em criptomoedas, este guia tem como objetivo ajudá-lo a entender essas importantes inovações técnicas.

Fundamentos do Modelo de Autorização ERC-20

Antes de mergulhar no Permit, vamos primeiro dar uma olhada em como o modelo tradicional de autorização de token ERC-20 funciona e as limitações que ele apresenta.

Como funcionam as aprovações tradicionais ERC-20

ERC-20 é o padrão para tokens no Ethereum. Ele define funções como aprovar e transferirDe, que juntas permitem a autorização de token. Autorização aqui significa que um detentor de token (o proprietário) permite que outra conta, normalmente um contrato inteligente (o gastador), transfira uma certa quantidade de tokens em seu nome. O processo básico funciona assim:

1. O detentor do token chama a função approve(spender, amount) do contrato do token. Isso registra a permissão no mapeamento interno do contrato, geralmente expressa como allowance[owner][spender] = amount. Por exemplo, se o usuário A autoriza o contrato Uniswap a gastar até 100 tokens, o contrato armazenará allowance[A][Uniswap] = 100. Este passo requer uma transação on-chain e taxas de gás pagas por A.
2. DeleGate.iod Transfer (transferFrom): Mais tarde, quando o Uniswap (ou outro dApp) precisa gastar tokens em nome de A, ele chama transferFrom(A, B, quantidade) no contrato do token. O contrato verifica se a autorização[A][Uniswap] é suficiente. Se for, o contrato transfere a quantidade especificada de A para B e deduz essa quantidade da autorização.

Limitações e Desafios do Modelo de Aprovação

O modelo de dois passos acima permite que os usuários autorizem contratos para gerenciar seus fundos, sem nunca compartilhar suas chaves privadas. No entanto, esta abordagem tradicional também vem com vários problemas práticos:

Duas transações necessárias, experiência do usuário ruim
Cada vez que um usuário deseja usar um novo token em um dApp, ele deve primeiro enviar uma transação de aprovação separada antes de poder realmente realizar a ação desejada (como trocar ou apostar). Isso significa que sua carteira irá solicitar a confirmação duas vezes e cobrar taxas adicionais de Gas. Para iniciantes, esta etapa extra pode ser confusa e inconveniente.

Gerenciamento fragmentado de aprovação
Quando os usuários interagem com vários dAppsusando o mesmo token (por exemplo, negociando na Uniswap e depois depositando em um protocolo DeFi diferente), cada dApp requer uma aprovação separada, embora seja o mesmo token na mesma carteira. Isso leva a aprovações repetitivas, desperdiçando tempo e gás.

Além disso, uma vez que cada dApp gerencia suas próprias permissões de forma independente, os usuários têm pouco controle centralizado sobre suas aprovações. Algumas ferramentas, como Revoke.casheDeBank, permitindo que os usuários visualizem e gerenciem permissões de token, mas muitos usuários não estão cientes delas. E mesmo que estejam, revogar permissões ainda requer uma transação on-chain, o que adiciona custos. Como resultado, muitas aprovações antigas ou não utilizadas são simplesmente esquecidas.

Os riscos de aprovações ilimitadas
Para evitar transações de aprovação frequentes, muitos dApps sugerem que os usuários concedam aprovação ilimitada, permitindo que o contrato gaste todo o saldo de tokens do usuário, sem expiração. Embora essa abordagem economize esforço posteriormente, ela introduz sérios riscos de segurança: se o dApp ou contrato for comprometido, um atacante poderia drenar todos os tokens aprovados.

Esses desafios levaram os desenvolvedores a buscar melhores alternativas. Idealmente, os usuários só precisariam assinar uma vez (preferencialmente off-chain e sem taxas de gás) para completar tanto a aprovação quanto a ação. A aprovação também deve ser limitada em escopo e duração para minimizar os riscos potenciais. Essa é a motivação por trás da introdução do Permit ERC-20.

Permissão: Autorização baseada em assinatura ERC-20 (EIP-2612)

O conceito de Permit foi introduzido pela primeira vez porDAIcontrato de stablecoin e posteriormente padronizado como EIP-2612. Em resumo, o Permit permite que os usuários autorizem transferências de tokens usando assinaturas fora da cadeia, eliminando a necessidade de enviar uma transação de aprovação separada na cadeia. Vamos dar uma olhada mais de perto em como funciona e em seus recursos distintivos.

Como o Permit Works

A permissão é um mecanismo de autorização baseado em assinaturas digitais. Sob o padrão EIP-2612, os contratos de token ERC-20 que suportam a permissão adicionam uma função chamada permit() que se parece com isso:

função permitir(
proprietário do endereço, gastador do endereço,
uint256 valor, uint256 prazo,
uint8 v, bytes32 r, bytes32 s
) externo;

Aqui, proprietário, gastador e valor especificam quem dá permissão, quem recebe permissão e a quantidade permitida. prazo indica quando a assinatura expira. Os parâmetros v, r e s formam o ECDSAassinatura digital. Usando Permit, os usuários contornam a aprovação separada on-chain - eles simplesmente assinam a mensagem (sem pagar Gas) e incluem essa assinatura com sua transação para concluir a autorização em um passo.

Fluxo de Permissão

Comparado ao aprovar tradicional, o Permit remove a necessidade de uma transação extra na cadeia, economizando tempo e taxas de gás. Ele também permite controle detalhado sobre aprovações. Por exemplo, um usuário poderia assinar um Permit que permite gastar exatamente 50 USDC, válido por apenas 5 minutos. Mesmo se a assinatura for exposta, ela se torna inutilizável após o prazo, reduzindo o risco. Hoje, muitos protocolos DeFi, como trocas descentralizadas e plataformas de empréstimo, já suportam o Permit. Exemplos conhecidos incluem Uniswap V2/V3tokens LP, DAI, eUSDC, que implementaram o padrão EIP-2612, possibilitando aprovações baseadas em assinatura em um único passo.

No entanto, a maior limitação do Permit é que ele deve ser implementado diretamente dentro do contrato do token. Se o desenvolvedor de um token não adicionou o método permit() - o que significa que não suporta o EIP-2612 - então o Permit simplesmente não pode ser usado. Como o EIP-2612 foi introduzido apenas em 2020, muitos tokens mais antigos não o incluem e mesmo os tokens mais recentes nem sempre o adotam. Isso restringe a aplicabilidade do Permit: tokens não suportados ainda requerem o fluxo de aprovação tradicional.

Outra questão é que o software da carteira deve lidar e exibir corretamente as assinaturas Permit, que geralmente são formatadas usando EIP-712. A maioria das principais carteiras já oferece suporte a isso, mas algumas ainda mostram dados brutos em vez de mensagens legíveis, tornando difícil para os usuários entender o que estão assinando. Sem uma interface clara para EIP-2612, as carteiras podem dificultar a compreensão dos usuários sobre aprovações baseadas em assinaturas. Além disso, em casos de implantações paralelas (como contratos com endereços idênticos em diferentes redes), as assinaturas potencialmente poderiam ser reutilizadas em outros ambientes. Portanto, os usuários devem verificar se o ID da rede e o endereço do contrato em suas assinaturas correspondem ao ambiente atual para evitar que permissões concedidas para tokens na Rede A sejam utilizadas de forma indevida por contratos idênticos na Rede B.

Essencialmente, o Permit melhora significativamente a eficiência e flexibilidade das aprovações ERC-20, marcando um marco importante nos mecanismos de aprovação sem gás. No entanto, não é uma solução perfeita: requer suporte ao nível do token e introduz novos riscos. Em seguida, examinaremos como o Permit2 da Uniswap se baseia e amplia a base estabelecida pelo Permit.

Permit2: Contrato de Gerenciamento de Autorização Universal

À medida que o mecanismo de Permissão ganhou popularidade, surgiu um novo desafio: como estender a conveniência da autorização baseada em assinatura para tokens que não suportam Permissão? Para enfrentar esse problema e otimizar as experiências de autorização em vários cenários, a equipe Uniswap introduziu o Permit2 em 2022. Ao contrário de um recurso específico do token, o Permit2 é um contrato inteligente de gerenciamento de autorização independente. Ele atua como intermediário para autorizações de token, fornecendo funcionalidade de permissão unificada e aprimorada. Vamos analisar os princípios e recursos do Permit2.

Como o Permit2 funciona

Permit2 funciona como um serviço de retransmissão de autorização. Seu conceito principal é simples: os usuários concedem uma aprovação única ao contrato Permit2, que gerencia as subautorizações subsequentes para várias aplicações. Veja como funciona:

1. One-time Permit2 Authorization: Os usuários aprovam Permit2 para cada token usando o método tradicional approve(Permit2, max_amount). Uma quantidade grande ou ilimitada é recomendada, uma vez que esta é a aprovação principal. Uma vez concluído, o contrato Permit2 ganha a capacidade de chamar transferFrom em nome do usuário para esse token. Isso requer uma transação on-chain, mas só precisa ser feita uma vez.
2. Assinatura fora da cadeia para subautorização: Quando os usuários desejam interagir com um DApp (por exemplo, usando o Roteador Universal Uniswap para trocas de vários tokens), eles assinam uma mensagem de autorização fora da cadeia seguindo as especificações do Permit2. Esta assinatura inclui detalhes como o token permitido, quantidade, destinatário autorizado (como um contrato DApp específico) e tempo de validade.
3. Solicitação de Transferência de DApp Usando Assinatura: Quando um DApp recebe a assinatura do usuário e precisa usar tokens, em vez de chamar diretamente o contrato de token, ele chama as funções do Permit2 (como permitTransferFrom). Esta função verifica os dados da assinatura do usuário e confirma que a operação está dentro das permissões concedidas (token, quantidade, prazo). Após a verificação, o Permit2 usa sua aprovação principal para chamar transferFrom, movendo tokens do usuário para o destinatário especificado. Ponto chave: O contrato do Permit2 em si atua como o gastador, usando sua própria autoridade para transferir tokens, com uma etapa adicional de verificação de assinatura.
4. Conclusão da Operação: Uma vez que o Permit2 executa com êxito a transferência, os fundos se movem suavemente do usuário para o DApp ou endereço especificado. Do ponto de vista do usuário, eles fornecem apenas uma assinatura na transação, enquanto o contrato cuida de todas as ações subsequentes.

O fluxo de autorização do Permit2 é direto: os usuários só precisam conceder aprovação máxima ao Permit2 uma vez por token. Depois, ao interagir com aplicativos (como o Roteador Universal Uniswap ou outros protocolos), eles simplesmente incluem uma assinatura do Permit2 em sua transação para concluir a autorização e a transferência, sem aprovações adicionais na cadeia. O contrato do Permit2 verifica a assinatura e executa a transferência usando sua aprovação principal. (Fonte:Apresentando Permit2 & Roteador Universal)

Por meio desse modelo, o Permit2 estende o conceito de autorização baseada em assinatura do EIP-2612 a todos os tokens ERC-20, independentemente de implementarem o método permit() por si próprios. Desde que os usuários autorizem inicialmente o contrato Permit2, eles podem usar assinaturas para operações subsequentes. Notavelmente, a Uniswap projetou o Permit2 como um contrato sem proprietário e não atualizável, implantado com o mesmo endereço em toda a rede principal do Ethereum e em várias redes de Camada 2. Isso significa que todas as aplicações realmente usam a mesma instância do Permit2, alcançando a funcionalidade verdadeira de "autorizar uma vez, usar em todos os lugares".

Principais características do Permit2

Como um sistema de autorização de próxima geração, o Permit2 não apenas permite aprovações baseadas em assinatura para todos os tokens, mas também oferece recursos adicionais para melhorar a segurança e usabilidade. Aqui estão suas principais características:

Expiração Automática
Todas as autorizações do Permit2 podem incluir um carimbo de data/hora para expiração. Os usuários podem especificar quando sua subautorização deve expirar ao assinar. Uma vez que o prazo expire, o Permit2 rejeitará a assinatura, mesmo que a aprovação principal ainda esteja ativa. Isso aborda efetivamente o risco de aprovações indefinidas permanecerem não utilizadas.

Transferências de Assinatura Única
O Permit2 oferece um modo de transferência de assinatura direta, onde os usuários podem autorizar uma transferência de token específica para um destinatário usando apenas uma assinatura, sem a necessidade de definir uma permissão primeiro. Isso é perfeito para cenários de pagamento único: os usuários podem assinar uma mensagem autorizando a transferência de 100 tokens para o endereço de um amigo, e o amigo ou intermediário pode executar a transferência usando essa assinatura. Uma vez usada, a assinatura se torna inválida, não deixando permissões pendentes.

Aprovações em lote e transferências
O Permit2 prioriza a eficiência ao permitir o processamento em lote de várias aprovações ou transferências. Os usuários podem autorizar quantidades diferentes de vários tokens para um único protocolo com uma única assinatura, ou executar transferências de vários tokens em uma única transação. Isso economiza Gas e reduz etapas para usuários avançados.

Revogação de lote
Além das aprovações em lote, os usuários podem revogar permissões para vários tokens/aplicativos em uma única transação. Isso torna a limpeza das aprovações históricas muito mais conveniente.

Testemunho de Dados Adicionais
Permit2 inclui interfaces comopermitirTransferenciaTestemunhaDe que permitem que dados adicionais de verificação sejam incluídos em assinaturas. Isso suporta cenários mais complexos, como incluir detalhes específicos da transação nas assinaturas de ordem para evitar reutilização de assinaturas em contextos diferentes.

Através desses recursos, o Permit2 não apenas replica todos os benefícios do Permit, mas também aprimora a flexibilidade e os controles de segurança. A expiração automática e as transferências de assinatura de uso único, em particular, tornam a autorização mínima necessária a norma, reduzindo os riscos de longo prazo.

Para resumir, o Permit2 funciona tanto como uma extensão quanto como um aprimoramento do mecanismo de Permit tradicional. Vamos examinar as principais diferenças entre essas duas abordagens:

Adoção e Implementação do Ecossistema Permit2

Desde que a Uniswap introduziu o Permit2, inúmeros projetos integraram esse mecanismo, acelerando a padronização da indústria. De acordo com os dados mais recentes de Análise de Dunas, em abril de 2025, mais de 3,1 milhões de endereços da mainnet do Ethereum concederam autorização ao contrato Permit2, demonstrando sua adoção generalizada.

Permit2 Ecosystem e Status de Implementação. Fonte:Dune Analytics

Por exemplo, a Uniswap integrou o Permit2 ao seu Universal Router, permitindo trocas multi-token e NFT em uma única transação. Por meio do Universal Router, os usuários podem encadear várias operações em uma transação, como trocar três tokens por dois tokens de destino e comprar NFTs, com todos os requisitos de autorização manipulados por assinaturas Permit2. Isso simplifica significativamente o processo e reduz os custos totais de gás, mostrando o impacto direto do Permit2 na melhoria da experiência do usuário.

Além disso, com a implementação de código aberto do Permit2 em várias cadeias, um número crescente de carteiras e ferramentas DApp começaram a oferecer suporte a ele. Ferramentas de segurança como Revoke.cash atualizaram seus serviços para permitir que os usuários visualizem e revoguem os registros de autorização do Permit2. A Matcha também implementou o módulo de Transferência de Assinatura do Permit2, possibilitando um mecanismo de 'autorização única'.

Apesar desse progresso, a adoção generalizada do Permit2 enfrenta desafios. Por um lado, os desenvolvedores precisam de tempo adicional para integração: em comparação com o uso do aprovo do ERC-20 diretamente, a implementação do Permit2 requer o manuseio da lógica de assinatura, aumentando o overhead de desenvolvimento. Isso pode desencorajar equipes menores. Por outro lado, a educação do usuário é crucial: muitos DApps que usam o Permit2 precisam ensinar aos usuários sobre a importância das assinaturas. Atualmente, as vantagens unificadas do Permit2 parecem superar esses pontos de fricção, mas a penetração total no mercado ainda levará tempo.

Comparando Permit2 com Novas Soluções: Chaves de Sessão e ERC-4337

Ao longo dos últimos 8 anos, os mecanismos de autorização ERC-20 evoluíram de múltiplas transações para assinaturas sem gás e agora para contas inteligentes. Cada avanço buscou otimizar o equilíbrio entre a experiência do usuário (reduzindo os requisitos de transação e assinatura) e os custos de gás. Aqui está uma comparação dessas tecnologias:

Além do Permit2, duas soluções de autorização emergentes que valem a pena mencionar são Chaves de Sessão e ERC-4337 Abstração de Conta, cada um oferecendo abordagens distintas para o problema.

As Chaves de Sessão são particularmente únicas, pois não são um modelo de autorização estrito, mas sim um mecanismo de chave temporária no nível da carteira ou da conta. Em vez de modificar contratos de token, elas permitem que as carteiras gerem chaves privadas temporárias com limite de tempo e quantidade para operações específicas. Isso as torna ideais para compras de itens de jogos e micropagamentos únicos. Seu foco é reduzir os riscos de autorização única, projetadas especificamente para interações temporárias do usuário, ao contrário da abordagem de modificação de contrato do Permit/Permit2.

O ERC-4337 adota uma abordagem diferente, incorporando a lógica de autorização diretamente em contas inteligentes, permitindo que os usuários personalizem as condições de autorização e potencialmente pulem as etapas tradicionais de aprovação. Através de mecanismos flexíveis UserOperation e Paymaster, ele alcança maior segurança e experiência do usuário.

Olhando para as tendências futuras, é provável que estas diferentes soluções coexistam. No curto prazo, o Permit2 continuará a ser o padrão para DApps emergentes, melhorando a experiência do usuário por meio de autorizações únicas e, ao mesmo tempo, promovendo educação de segurança e suporte a ferramentas para reduzir os riscos de phishing. A médio prazo, à medida que o ERC-4337 e a abstração de contas se tornam mais difundidos na Camada 2 e mainnets, os usuários poderão se libertar das limitações tradicionais de aprovação do ERC-20, gerenciando as autorizações de forma mais precisa e inteligente, potencialmente reduzindo a necessidade de Permit2.

A visão de longo prazo é criar uma experiência de autorização tão fluida e intuitiva quanto a Web2, onde os usuários podem simplesmente clicar em um botão e todas as aprovações necessárias acontecem automaticamente em segundo plano, com prompts claros aparecendo apenas em situações de alto risco. Alcançar essa visão exigirá colaboração e inovação contínuas em todos os protocolos subjacentes, carteiras e dApps. O Permit2 representa um passo importante nesta jornada de transição, mas ainda há um longo caminho a percorrer antes de alcançar o estado ideal. Ao longo do caminho, tanto a comunidade quanto os desenvolvedores devem manter uma abordagem pragmática, compreendendo totalmente as forças e limitações de cada solução e trabalhando juntos para construir um ambiente de autorização mais seguro e amigável ao usuário.

No geral, o Permit2 oferece uma solução prática que pode ser implementada imediatamente, enquanto tecnologias como Chaves de Sessão e ERC-4337 apontam para melhorias mais fundamentais e de longo prazo na forma como a autorização é tratada.

Riscos de Segurança da Autorização Baseada em Assinatura

Assim como acontece com qualquer nova tecnologia, Permit e Permit2 introduzem não apenas novas eficiências, mas também novos riscos, especialmente em torno de ataques de autorização baseados em assinatura.

Em esquemas baseados em assinaturas como Permit2 e Permit EIP-2612, os designs de contrato principais incluem múltiplas camadas de proteção para evitar o uso indevido e ataques de repetição:

1. Proteção contra repetição não baseada em não

Permit2 mantém um contador de nonce separado para cada tupla (proprietário, token, gastador). Sempre que um usuário assina uma nova autorização, o nonce correspondente é incrementado. Se um atacante tentar reutilizar uma assinatura antiga, ela falhará porque o contrato verifica se o nonce já foi usado.

2. Cumprimento do prazo

Cada assinatura deve incluir um campo de prazo. Quando o contrato verifica a assinatura, ele garante que o tempo do bloco atual seja menor ou igual ao prazo. Se a assinatura tiver expirado, mesmo que seja válida, ela será rejeitada. Isso impede que autorizações de longo prazo sejam exploradas posteriormente.

3. Controle de Permissão Detalhado

As assinaturas Permit2 podem especificar um limite máximo. Antes de qualquer transferência de token ocorrer, o contrato verifica se o valor solicitado está dentro desse limite. O contrato não gasta automaticamente o valor total aprovado, permitindo que os usuários usem sua franquia em partes e reduzindo o risco de uma exploração de drenagem total.

4. Modos de Uso Único e em Lote

Além das aprovações baseadas em permissões em andamento, o Permit2 também suporta assinaturas de uso único via Transferência de Assinatura. Essas assinaturas são válidas apenas para uma transação e se tornam inválidas imediatamente após a execução. Isso é ideal para pagamentos únicos e impede que a assinatura seja reutilizada ou explorada posteriormente.

Essas proteções em camadas ajudam os esquemas de autorização do estilo Permit a melhorar a experiência do usuário e economizar gás, ao mesmo tempo que minimizam riscos clássicos como "ataques de repetição", "sobreautorização" e "validade de assinatura indefinida".

No entanto, mesmo com proteções seguras ao nível do contrato, a engenharia social (especialmente phishing) continua a ser a ameaça mais difícil de defender-se. Na próxima seção, vamos analisar táticas comuns de phishing e como os atacantes enganam os usuários para assinarem aprovações maliciosas que abusam do Permit2. Também ofereceremos dicas sobre como se manter seguro.

Como acontecem os ataques de phishing de assinatura?

O phishing de assinatura ocorre quando os invasores enganam as vítimas para que assinem mensagens específicas para obter o controle de seus ativos. Embora os ataques tradicionais possam envolver a execução de contratos ou transações maliciosas, na era da permissão, uma única autorização de assinatura maliciosa é suficiente para drenar fundos. Veja como esses ataques normalmente se desenrolam:

1. A vítima clica em uma versão falsa de um conhecido site DEX (site de phishing). Quando o usuário tenta interagir, o site solicita uma solicitação de assinatura da carteira, alegando que é para "confirmação de login" ou outros fins aparentemente legítimos. No entanto, essa solicitação é, na verdade, uma assinatura de autorização Permit2, concedendo ao contrato do invasor permissão ilimitada para retirar o USDC da vítima com um período de validade estendido.
2. A vítima, sem vigilância, assina o pedido diretamente. Neste ponto, nenhum gás é gasto e nenhuma atividade on-chain ocorre, não deixando traços suspeitos.
3. Uma vez que o atacante obtém a assinatura, ele imediatamente chama a função permit() do contrato Permit2 para enviá-la. Depois que o contrato Permit2 valida a assinatura, ele registra a autorização para o contrato do atacante sob o endereço da vítima (equivalente à vítima executando uma aprovação, mas concluída pelo atacante). Essa operação ainda pode passar despercebida pela vítima, já que sua carteira não mostra despesas - apenas o mapeamento de permissão de token é atualizado no blockchain.
4. Posteriormente, o atacante inicia imediatamente uma transação transferFrom(vítima, endereço_do_atacante, quantidade) em seu endereço, transferindo com sucesso o USDC da vítima usando a recente autorização Permit2. A vítima só percebe o roubo quando é tarde demais.

Nesses ataques, os usuários nunca executam transações de “transferência” ou “autorização” óbvias, mas seus ativos desaparecem misteriosamente. A chave está na assinatura em si se tornando a autorização. Os atacantes disfarçam cuidadosamente solicitações de assinatura para parecerem operações normais, diminuindo a guarda dos usuários. No entanto, uma vez assinado, é como entregar as chaves de seus ativos.

Ainda pior, alguns atacantes empregam métodos técnicos para aumentar o sigilo. Por exemplo, eles usam o mecanismo CREATE2 do Ethereum para gerar endereços de contrato maliciosos exclusivos para cada vítima. Isso torna as listas negras tradicionais ineficazes, pois cada ataque usa um endereço diferente.

Os incidentes de phishing de criptografia mais recentes envolvem autorização de assinatura. Por exemplo, Scam Sniffer's estatísticaA partir do início de 2024, mostram-se mais de $55 milhões em ativos roubados por meio de phishing de assinatura em apenas um mês. Desde a ativação do Permit2, os atacantes se tornaram mais agressivos ao induzir os usuários a assinar autorizações do Permit/Permit2, levando a inúmeras vítimas em um curto período. Claramente, quando a autorização de assinatura é abusada, pode ser devastadora e difícil de detectar.

Por que os riscos de phishing baseados em assinatura são maiores do que os métodos tradicionais?

As autorizações maliciosas tradicionais exigem que os usuários executem uma transação on-chain, onde as carteiras geralmente exibem avisos claros como “Você está autorizando XXX a usar seus tokens” e exigem taxas de gás. Usuários experientes tendem a ser mais cautelosos com isso. No entanto, solicitações de assinatura em interfaces de carteira muitas vezes são descritas apenas como “solicitações de assinatura de dados” e não como ações financeiras, fazendo com que os usuários baixem a guarda. Além disso, como as assinaturas não custam gás, os atacantes podem lançar tentativas de phishing em larga escala sem se preocupar com despesas - eles lucram mesmo com apenas algumas tentativas bem-sucedidas.

Além disso, diferentes carteiras exibem mensagens EIP-712 de maneiras diversas. Algumas carteiras modernas (como a mais recenteMetaMaskAnalise e exiba claramente os campos, mostrando mensagens como "autorize o contrato a gastar X quantidade de seus tokens." No entanto, muitas carteiras mostram apenas dados hexadecimais ou descrições simples, o que torna difícil para os usuários comuns verificar a autenticidade. Os atacantes exploram isso incorporando descrições enganosas nas mensagens (como se estivessem fingindo ser assinaturas de mint de NFT) para enganar os usuários a assinar.

Como as autorizações de assinatura não afetam imediatamente os ativos, as vítimas podem não detectar a ameaça imediatamente. Os atacantes podem cronometrar estrategicamente seus ataques. Em vez de executar imediatamente, eles podem esperar até que a carteira da vítima contenha mais ativos ou até um momento específico, o que complica os esforços de rastreamento. Com assinaturas que têm períodos de validade estendidos, os invasores também podem explorar movimentos de preços para maximizar seus ganhos, efetivamente dando-lhes uma opção de negociação gratuita. Esse risco explica por que as assinaturas de permissão geralmente impõem prazos curtos.

A capacidade da Permit2 de autorizar vários tokens com uma única assinatura torna particularmente desafiador para os usuários entenderem totalmente as implicações. Por exemplo, um site de phishing pode solicitar uma assinatura Permit2 enquanto realça permissões para apenas um ou dois tokens, mas incorporar secretamente autorizações extensas para tokens adicionais na mesma assinatura. Os usuários podem facilmente ignorar essas permissões ocultas se suas carteiras não exibirem todos os detalhes claramente. Além disso, os invasores costumam usar nomes de contratos enganosos como "WalletGuard" em suas assinaturas, mascarando contratos maliciosos projetados para roubar permissões de token.

Como os usuários podem se proteger de ataques de assinatura?

Lembre-se de que assinar é equivalente a dar consentimento—nunca permita que a ausência de taxas de gás o torne descuidado. Quando sua carteira solicitar uma assinatura, leia os detalhes da mensagem minuciosamente. Certifique-se de que o site ou DApp solicitando a assinatura é legítimo e que o conteúdo da mensagem está alinhado com suas ações pretendidas. Por exemplo, se você está simplesmente entrando em um site, a assinatura deve conter texto legível de login (como a maioria dos DApps usa), e não uma sequência de endereços e números de token.

Verifique se o software da sua carteira suporta a exibição de dados do EIP-712. Carteiras principais como MetaMask,TrustWallet, eLedger Liveestão melhorando sua experiência de exibição de conteúdo de assinatura. Por exemplo, o MetaMask agora pode analisar mensagens de permissão comuns em linguagem simples. Se sua carteira só mostrar dados hexadecimais longos ao assinar, considere alternar ou atualizar. Os usuários de carteira de hardware também devem manter seu firmware atualizado para suportar novos formatos, ou eles podem não ver as informações corretamente na tela.

Seja usando assinaturas de Permissão ou Permissão2, você geralmente pode ajustar parâmetros de autorização. Não assine quantidades ilimitadas (valor = 2^256-1) a menos que seja absolutamente necessário - em vez disso, autorize apenas a quantidade necessária mais um pequeno buffer. Além disso, não defina prazos muito distantes no futuro. Desta forma, mesmo que sua assinatura caia nas mãos erradas, as perdas potenciais são limitadas e a assinatura eventualmente expirará.

Desenvolva o hábito de verificar regularmente o status de autorização do seu endereço usando ferramentas como Revoke.cash, Etherscan Token Approval ou as funcionalidades integradas da sua carteira. Isso inclui aprovações tradicionais e permissões Permit2. Se você identificar alguma autorização suspeita ou desnecessária, revogue-a imediatamente. No caso do Permit2, esteja ciente de dois níveis de revogação: primeiro, a autorização mestra (sua aprovação para o próprio contrato Permit2, que você pode querer definir como 0 quando não estiver em uso); segundo, as subautorizações (permissões do Permit2 para vários DApps, que geralmente expiram automaticamente, mas podem ser encerradas antecipadamente se tiverem períodos de validade longos). Se você suspeitar que assinou um Permit suspeito, a ação mais segura é ajustar imediatamente o nonce: assine um novo permit para o mesmo gastador (mesmo com 0 de permissão) para invalidar a assinatura antiga em posse do atacante.

Sempre tenha cuidado ao visitar sites desconhecidos ou baixar aplicativos. Não clique em links desconhecidos, especialmente em "ofertas promocionais" ou "eventos de mint" compartilhados através de anúncios em redes sociais ou mensagens privadas. Muitas tentativas de phishing ocorrem através de contas oficiais falsas que postam links de atividades fraudulentas, levando a pedidos de assinatura. Faça disso um hábito digitar diretamente os URLs oficiais do DApp ou usar favoritos para evitar cair em sites falsos.

Em conclusão, encontrar um equilíbrio entre conveniência e segurança é crucial. Embora as tecnologias de permissão sejam convenientes, os usuários devem permanecer vigilantes sobre a prevenção de riscos. À medida que o ecossistema amadurece, produtos de carteira e plugins de navegador estão desenvolvendo proteção contra phishing de assinatura, como avisos para assinaturas envolvendo grandes quantidades. Nosso objetivo é mitiGate.io esses ataques por meio de aprimoramentos técnicos e educacionais no futuro.

Conclusão

Das limitações dos modelos tradicionais de autorização ERC-20 ao nascimento do Permit e, em seguida, à inovadora Permit2 da Uniswap, testemunhamos os esforços do ecossistema Ethereum para melhorar a experiência e segurança do usuário. O Permit2 simplifica significativamente o processo de autorização de tokens por meio de assinaturas off-chain, reduzindo os riscos de aprovações repetidas e permissões ilimitadas, enquanto introduz recursos úteis como mecanismos de expiração e operações em lote. No entanto, esses novos mecanismos trazem novas responsabilidades - os usuários precisam aumentar sua consciência de segurança, enquanto carteiras e DApps devem trabalhar juntos para proteger os usuários de ataques de assinatura. Olhando para o futuro, com o avanço tecnológico, como a abstração de contas, espera-se que o gerenciamento de autorização de tokens se torne mais simples e seguro.