Aprovações de tokens, allowances e Permit: o que você realmente assina

Uma aprovação de token é uma permissão on-chain guardada dentro de um contrato de token ERC-20 — uma allowance — que registra que um contrato específico pode gastar até um valor específico dos seus tokens, em qualquer momento futuro, sem perguntar de novo. Ela é criada por uma transação approve() e sobrevive à interação para a qual você a concedeu: o site pode desaparecer, a allowance fica. O Permit (EIP-2612) troca essa transação separada por uma assinatura off-chain que a dApp envia junto com a própria ação, e o Permit2 estende esse mesmo modelo, com prazo de validade e valor limitado, a tokens que nunca implementaram a EIP-2612 — ou seja, hoje uma assinatura já entrega poder de gasto, então pedidos de assinatura merecem o escrutínio que antes era reservado às aprovações. A defesa é pouco glamourosa: aprove valores limitados em vez de ilimitados e revogue allowances que você não usa mais. Em uma carteira totalmente non-custodial como a WATS — onde o usuário detém as chaves e a WATS nunca detém nenhuma — nenhuma aprovação, assinatura Permit ou revogação acontece sem que a sua própria chave assine, e como a WATS cobra as taxas de rede das chains EVM em um único token, ATS, ali uma transação de limpeza nunca fica adiada por falta do token de gas nativo daquela chain.

Por que as dApps pedem aprovação

Os tokens ERC-20 têm uma peculiaridade que molda metade da UX da Web3: um contrato inteligente não pode simplesmente pegar tokens do seu endereço, mesmo quando você quer. Uma DEX que troca seu USDC precisa primeiro da sua permissão explícita. Por isso tantas interações têm dois passos — primeiro uma transação de approve, depois o swap ou depósito de verdade. A aprovação não é uma formalidade; é uma concessão permanente de poder de gasto, e sobrevive à transação para a qual você a deu.

O que approve() realmente concede

Quando você assina uma aprovação, o contrato do token registra uma allowance: o endereço X (o contrato da dApp) pode gastar até N dos seus tokens, quando quiser, até essa allowance ser consumida, reduzida ou revogada. Duas propriedades importam. Primeira: a allowance vive no contrato do token e é concedida ao contrato que você aprovou — não ao site que você visitou, cuja interface pode desaparecer enquanto a permissão permanece. Segunda: nada em uma allowance exige sua participação na hora do gasto — uma vez concedida, o contrato aprovado pode puxar tokens em qualquer transação futura sem outra assinatura sua. É exatamente isso que torna as aprovações úteis — e exatamente isso que as torna uma superfície de ataque.

Aprovações infinitas: convenientes, e um risco permanente

Como cada aprovação custa gas, muitas dApps pedem uma allowance efetivamente ilimitada para que você nunca precise aprovar de novo. A conveniência é real, mas o acordo também: uma allowance ilimitada a um contrato significa que todo o seu saldo daquele token depende para sempre da segurança daquele contrato. Se o contrato for explorado anos depois — ou fosse malicioso desde o início — o atacante não precisa da sua chave nem da sua assinatura; a allowance que você concedeu basta. Muitos dos maiores incidentes de esvaziamento de carteiras não foram roubos de chaves, apenas aprovações antigas sendo descontadas.

Permit e Permit2: aprovações por assinatura

O refinamento moderno é o Permit (EIP-2612): em vez de uma transação approve on-chain, você assina uma mensagem off-chain que a dApp envia junto com a ação dela — uma transação em vez de duas, sem gas separado de aprovação, e a permissão pode ser limitada com um prazo. O Permit2 generaliza a ideia para tokens que nunca implementaram a EIP-2612, funcionando como um hub compartilhado de aprovações: você faz uma única aprovação on-chain comum ao próprio contrato Permit2 e, daí em diante, cada dApp é autorizada por uma assinatura que carrega o seu próprio valor e o seu próprio prazo. Vale ser preciso sobre essa troca: o Permit2 não acaba com as aprovações, ele as concentra — logo, a allowance permanente que você deu ao Permit2 é, ela mesma, uma aprovação a acompanhar. São melhorias genuínas, mas note o que elas mudam: assinaturas agora fazem o trabalho que transações faziam. Um site de phishing que faz você assinar a mensagem Permit errada consegue o mesmo resultado de uma aprovação maliciosa — então ler o que você assina importa mais do que nunca, não menos.

A superfície de ataque: drainers e allowances velhas

O abuso de aprovações vem em dois sabores. Ativo: sites drainer se passam por dApps reais e pedem aprovações (ou assinaturas Permit) disfarçadas de ações inofensivas como "resgatar" ou "verificar carteira". Passivo: allowances que você concedeu anos atrás a contratos legítimos ficam adormecidas até o contrato, suas chaves de admin ou seu caminho de upgrade serem comprometidos. Ambos são motivos para tratar o fluxo conectar-e-aprovar como o momento crítico de segurança da Web3; o jeito seguro de executá-lo está em como conectar sua carteira a uma dApp.

Higiene de aprovações que funciona de verdade

Três hábitos cobrem a maior parte do risco. Aprove valores limitados quando a dApp permitir, principalmente para saldos grandes — a aprovação extra depois é um seguro barato. Revise e revogue allowances periodicamente com um verificador de aprovações confiável, tratando o que você não usa mais como peso morto a remover — revogar é, em si, uma transação on-chain que devolve a allowance a zero, então custa gas e exige sua assinatura como qualquer outra. E mantenha patrimônios sérios em um endereço que simplesmente nunca assina aprovações, separado da sua carteira ativa de dApps. Mais hábitos em camadas no guia de melhores práticas de segurança de carteiras cripto. Quando aparecer um pedido de assinatura, leia-o por tipo antes de assinar:

• Aprovação de token (approve ou setApprovalForAll): confira o endereço do gastador e o valor; um valor ilimitado para um gastador que você não reconhece é sinal de alerta.
• Dados tipados EIP-2612 Permit ou Permit2: confira o gastador, o valor e o prazo; uma assinatura com um gastador desconhecido ou um prazo longo entrega poder de gasto sem nenhuma transação visível.
• Autorização EIP-7702: confira o endereço do delegado, porque assiná-la aponta o código da sua conta para esse contrato; se não reconhecer o delegado, rejeite, e veja como verificar e revogar uma delegação EIP-7702.
• Mensagem personal_sign simples: confira se o texto é legível e corresponde ao que você está fazendo, como uma mensagem de login de um site que você reconhece, e desconfie de dados hexadecimais ilegíveis apresentados como uma verificação inofensiva.

Onde a WATS se encaixa

Aprovações são assinaturas, e assinaturas são território da carteira. A WATS é totalmente non-custodial — você detém suas chaves, a WATS nunca detém nenhuma — então cada aprovação, assinatura Permit e revogação acontece apenas quando a sua chave assina, pela extensão do Chrome ou pelo app móvel, em Ethereum, BNB Smart Chain, Arbitrum One, Optimism, Base, Polygon, Gnosis, Celo, Mantle, Cronos, Solana e TON. Isso também define o limite honesto do que qualquer carteira pode fazer por você: a carteira mostra o pedido, mas só você decide se o gastador e o valor são os que você pretendia.

O lado das taxas elimina a outra desculpa comum para deixar allowances antigas de pé. Na WATS, nas chains EVM cada ação, incluindo as transações de aprovação e revogação, é cobrada em um único token, ATS, em vez do token de gas nativo da chain — via um paymaster ERC-4337; o modelo é o mesmo na extensão do Chrome e no app móvel. Solana e TON são chains totalmente suportadas na WATS; as transações na Solana pagam sua própria taxa nativa, em SOL, enquanto as taxas na TON também são pagas em ATS. Isso não é desconto: a rede continua recebendo o que lhe é devido e o custo subjacente não muda — o que muda é qual token paga. Seu saldo de ATS fica na BSC (BNB Chain) e, qualquer que seja a rede EVM em que a transação ocorra, a taxa é debitada desse saldo único. O ATS arrecadado é queimado e a oferta cai de 100M rumo a um piso de 30M. A WATS Wallet combina taxas em um único token, o ATS, cobradas por um paymaster ERC-4337 a partir de um único saldo na BSC, com essa queima — detalhes na página de taxas do ATS.

Então a versão prática deste artigo é uma rotina curta: prefira aprovações com valores limitados, leia o que uma assinatura Permit realmente autoriza antes de assinar e, uma vez por trimestre, abra um verificador de aprovações e limpe os gastadores que você não usa mais. O passo concreto é rodar essa rotina a partir de uma carteira que nunca se põe entre você e a chave: na WATS, na extensão do Chrome ou no app móvel, cada aprovação e cada revogação só existe porque a sua própria chave assinou — a WATS nunca detém nenhuma — e nas chains EVM a revogação é paga em ATS em vez do token de gas nativo que aquela chain específica resolve exigir.