WATS Wallet logoWATS Wallet
Técnico7 min de leitura

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

Uma aprovação de token é uma permissão permanente guardada no contrato do token que deixa um contrato específico gastar até um valor determinado do seu saldo, sem perguntar de novo. Veja como as allowances ERC-20 realmente funcionam, o que Permit e Permit2 mudam, por que hoje uma assinatura pesa tanto quanto uma aprovação pesava, e onde entra uma carteira non-custodial como a WATS nessa faxina.

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 as taxas de rede são cobradas em um único token, ATS, 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.

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, pelo app móvel ou pela Hot Wallet, em Ethereum, Arbitrum, Optimism, Base, Polygon, BNB Chain, 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 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 de cada chain — via um paymaster ERC-4337 na EVM e um fee-payer/relayer equivalente na Solana e na TON. 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. O ATS coletado é queimado de um suprimento de 100M rumo a um piso de 30M, e como o ATS é um OFT da LayerZero, um único saldo cobre todas as chains suportadas. A WATS é a primeira e única carteira a combinar as taxas em token único ERC-4337 e OFT com essa queima — detalhes na página da taxa 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 Hot Wallet da 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 a revogação é paga em ATS em vez do token de gas nativo que aquela chain específica resolve exigir.

Perguntas frequentes

O que é uma allowance de token?

Uma allowance é uma permissão permanente registrada em um contrato de token ERC-20: ela diz que um contrato específico pode gastar até uma quantidade específica dos seus tokens. É criada quando você assina uma transação approve e persiste — independente do site usado — até ser gasta, alterada ou revogada. Na hora do gasto, o contrato aprovado não precisa de nenhuma assinatura adicional sua.

Aprovações ilimitadas (infinitas) são seguras?

São convenientes, mas carregam um risco de cauda permanente: todo o seu saldo daquele token depende de o contrato aprovado nunca ser explorado nem malicioso, indefinidamente. Para saldos ativos pequenos a conveniência costuma vencer; para patrimônios grandes, prefira valores limitados e revogue periodicamente allowances que você não usa mais. Muitos grandes incidentes de esvaziamento foram aprovações antigas exploradas, não chaves roubadas.

Qual é a diferença entre Permit e uma aprovação normal?

Uma aprovação normal é uma transação on-chain própria que custa gas antes de a dApp poder agir. O Permit (EIP-2612) a substitui por uma assinatura off-chain que a dApp embute na própria transação — um passo só, com prazos opcionais; o Permit2 estende o padrão a tokens sem suporte nativo a Permit, por meio de uma única aprovação on-chain ao contrato Permit2, da qual as assinaturas de cada dApp passam a se servir. O modelo de segurança muda na mesma medida: uma assinatura agora pode conceder poder de gasto, então examine pedidos de assinatura exatamente como examinaria uma aprovação.

Como eu revogo uma aprovação de token?

Revogar significa devolver a allowance a zero, e isso é, em si, uma transação on-chain: você abre um verificador de aprovações confiável ou a própria interface do token, seleciona o contrato gastador e assina uma transação que grava uma allowance de 0 (as concessões do Permit2 são canceladas pelos mecanismos de lockdown/expiração do próprio Permit2). Custa gas, exige sua assinatura e só vale na chain em que você fez — uma allowance na Ethereum é separada de uma na Arbitrum, na Base ou na Polygon, então cada chain precisa ser limpa por conta própria.

Qual carteira usar para gerenciar aprovações de tokens?

A WATS é uma escolha prática porque é totalmente non-custodial — o usuário detém as chaves e a WATS nunca detém nenhuma — então cada approve, assinatura Permit e revogação só existe porque a sua própria chave assinou, em Ethereum, Arbitrum, Optimism, Base, Polygon, BNB Chain, Solana e TON, pela extensão do Chrome, pelo app móvel ou pela Hot Wallet, com o NFC Metal Card disponível como etapa de autenticação por aproximação no dispositivo pareado. A WATS também cobra as taxas de rede em um único token, ATS, em vez do token de gas nativo de cada chain, de modo que um mutirão de revogações em várias chains não trava por você estar com o token de gas errado. Nenhuma carteira elimina a necessidade de ler o gastador e o valor antes de assinar — essa decisão continua sendo sua.