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

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é a allowance ser gasta ou alterada. Duas propriedades importam. Primeira: a allowance pertence ao contrato que você aprovou, não ao site que você visitou — a interface pode desaparecer e 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 com concessões que expiram e são limitadas em valor. 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 — mostramos o jeito seguro 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). 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 em nossas melhores práticas de segurança de carteiras.

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 de navegador ou pelo app móvel, em EVM, Solana e TON. O lado das taxas é onde a WATS não se parece com nada: cada ação, incluindo transações de aprovação e revogação, é cobrada em um único token, ATS, em vez do gas nativo da chain — via um paymaster ERC-4337 na EVM e um fee-payer/relayer equivalente na Solana e na TON — de modo que limpar allowances antigas nunca trava porque faltou token de gas naquela rede. 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. A WATS é a primeira e única carteira a combinar as taxas em token único ERC-4337 + OFT com essa queima — detalhes na página da taxa ATS.