Aprovações de tokens: as permissões que você não para de conceder

Sempre que você interage com um app DeFi — um swap em uma DEX, um depósito em um mercado de empréstimos, uma bridge de um ERC-20 — quase certamente concedeu uma aprovação de token. A maioria dos usuários assina essas transações em segundos e esquece delas. Ainda assim, esse único approve é uma das coisas mais consequentes que você faz na Ethereum: ele entrega a um smart contract uma permissão permanente para mover seus tokens, muitas vezes sem nova confirmação. Este guia explica o que é uma aprovação de token, por que dApps as pedem, os riscos dos allowances ilimitados e o que tudo isso significa quando você assina aprovações pela SSP.

Por que aprovações existem

Tokens ERC-20 não ficam guardados "dentro" da sua carteira como ETH. Um contrato de token ERC-20 é um livro-razão: um mapeamento de endereços para saldos. Quando você tem 1.000 USDC, o que existe on-chain é uma linha no contrato de USDC dizendo que seu endereço possui 1.000 unidades.

Como o saldo vive dentro do contrato do token, só esse contrato pode movê-lo. Quando você manda USDC para um amigo, sua carteira chama diretamente a função transfer do token.

Mas uma DEX, onde um contrato diferente (o router) precisa puxar USDC do seu endereço para executar um swap, não consegue enfiar a mão no contrato do token e pegar seu saldo. ERC-20 resolve isso com um padrão de delegação em dois passos:

1. Você chama approve(spender, amount) no contrato do token. Isso define um allowance: um registro de que o spender está autorizado a mover até amount dos seus tokens.
2. O spender depois chama transferFrom(yourAddress, destination, amount) no contrato do token. O contrato verifica o allowance, decrementa-o e move os tokens.

A aprovação é a chave. Sem ela, o router não consegue tocar nos seus USDC.

O que está sendo realmente concedido

Leia approve(spender, amount) ao pé da letra. Você está dizendo ao contrato ERC-20: "este endereço pode sacar até essa quantidade dos meus tokens, a qualquer momento, em qualquer número de transações, até que eu mude isso."

Daí seguem algumas coisas:

• Permissão permanente, não ação única. Uma vez concedido, o spender não precisa da sua assinatura de novo para puxar tokens até que o allowance acabe ou seja revogado.
• Por token. Aprovar o router da DEX para USDC não permite que ele toque no seu DAI; você precisa de uma aprovação separada para DAI.
• Por spender. Um contrato diferente — mesmo da mesma dApp — tem seu próprio allowance.
• Sem expiração. ERC-20 não tem um prazo embutido. Um allowance definido em 2023 segue ativo em 2026 a menos que tenha sido consumido ou revogado.

Você pode inspecionar qualquer allowance em um block explorer como o etherscan lendo a função allowance(owner, spender) do contrato do token.

O padrão do allowance infinito

Se aprovações são por valor, por que quase toda DEX pede um número enorme — geralmente 2^256 - 1, exibido como "unlimited" ou MaxUint256 — em vez do valor que você está trocando?

A resposta é UX e gas. Se uma DEX pedisse um allowance novo igual ao tamanho do trade em cada swap, você pagaria uma transação de aprovação toda vez e teria de confirmar duas transações para o que parece uma única ação. Pedir um allowance ilimitado uma vez deixa você fazer swaps livremente depois, com apenas uma transação por trade.

É genuinamente conveniente. Também é genuinamente mais arriscado. Um allowance ilimitado significa que o contrato spender está autorizado a drenar todo o seu saldo atual desse token — e qualquer saldo futuro — a qualquer momento, sem que você assine mais nada.

Para um contrato conhecido, auditado e imutável, o risco prático costuma ser baixo. Para uma dApp recém-deployada, um proxy upgradable ou um contrato desconhecido, um allowance ilimitado é uma superfície bem maior do que a operação que você pretendia.

O risco real: uma chave permanente para seus tokens

O perigo das aprovações não está na transação de aprovação em si. Está no que vem depois. Considere alguns cenários:

• O contrato spender tem um bug. Um atacante explora sua lógica transferFrom e toda carteira com um allowance não zero é drenada.
• O contrato spender é upgradable. Quem controla as chaves de upgrade publica nova lógica que puxa tokens de qualquer um com allowance ativo.
• Você aprovou um clone malicioso. Um site de phishing imitou a URL de uma dApp real, e o contrato que você aprovou estava sob controle do atacante desde o começo.
• As chaves de assinatura do spender estão comprometidas. O contrato oficial está ok; a carteira do operador não, e os allowances são exercidos por um intruso.

Em todos os casos, você não assina nada quando o drenage acontece. A aprovação que você deu semanas antes é a única autorização de que o atacante precisa. "Aprove só o que você precisa e revogue o que não usa mais" não é paranoia; é o mesmo princípio de não deixar cópia das chaves de casa com cada prestador de serviço que você contratou.

Como aprovações se acumulam silenciosamente

Uma carteira ativa por um ou dois anos em DeFi acumulou dezenas de aprovações: cada DEX, cada agregador, cada depósito em mercado de empréstimos, cada marketplace de NFT, cada bridge. Os usuários quase nunca voltam para revogar. O resultado é uma longa cauda de permissões permanentes, muitas ilimitadas, muitas concedidas a contratos com os quais o usuário não interage mais.

Essa é a superfície de ataque silenciosa. Ela não aparece em nenhuma transação isolada; é o resíduo acumulado do uso normal. Auditar e podar essa lista é um dos hábitos de segurança mais eficazes em autocustódia — o próximo artigo mostra exatamente como em revogando aprovações de tokens pela SSP.

Um padrão mais novo: EIP-2612 permit

ERC-20 é anterior a boa parte do DeFi moderno, e a dança de duas transações approve-e-depois-swap já era reconhecida como inconveniente há tempos. EIP-2612 introduziu uma alternativa para tokens que a adotam: em vez de enviar uma transação approve on-chain, o usuário assina uma mensagem off-chain (um permit) autorizando um spender, um valor e um prazo específicos. A dApp envia essa assinatura junto com o swap em uma única transação.

permit é eficiente em gas, escopado (carrega um valor e uma expiração explícitos) e mais difícil de deixar pendurado porque o prazo o força a expirar. Nem todo ERC-20 suporta — USDC e DAI sim, muitos tokens mais antigos não — mas onde está disponível costuma ser mais seguro do que um allowance approve de longa duração. Dito isso, assinaturas permit também podem ser alvo de phishing: um site malicioso pedindo que você "faça login" pode encaixar um permit por baixo. Leia o que está assinando.

O que isso significa dentro da SSP

A SSP é uma carteira multisig 2-de-2 autocustodial: cada transação on-chain é cossinada pela extensão SSP do navegador e pelo app móvel SSP Key. Na Ethereum e nas redes EVM suportadas pela SSP (Polygon, Base, BNB Smart Chain, Avalanche), isso é implementado como um smart account ERC-4337 com assinatura Schnorr agregada — mas, na camada de aplicação, uma aprovação se parece com qualquer outra transação.

Algumas coisas para ter em mente:

• Uma aprovação é uma transação que seu 2-de-2 precisa cossinar. Quando uma dApp pede approve, a SSP a mostra como qualquer outra tx. Você vê o endereço do spender e o valor solicitado nos dois dispositivos antes de confirmar.
• Uma vez concedida, o spender não precisa mais da SSP para agir. O multisig protege o momento da aprovação, não a permissão permanente depois. Se você aprovar um allowance ilimitado para um contrato malicioso, seu multisig não vai te salvar do drenagem posterior.
• Olhe o endereço do spender. dApps às vezes atualizam routers; se o spender na tela de aprovação não bate com o contrato esperado, pare e verifique.
• Aprovações iniciadas via WalletConnect têm a mesma cara. Seja a dApp pedindo dentro da página ou via WalletConnect, o fluxo e os riscos são idênticos.

Hábitos que vale a pena cultivar

Algumas práticas concretas mantêm a superfície de aprovação administrável:

• Prefira o menor allowance viável. Quando uma dApp oferece "valor exato" versus "unlimited", o exato é a opção padrão mais segura para contratos que você não usa regularmente.
• Trate aprovações ilimitadas como compromissos. Reserve-as para um pequeno conjunto de contratos em que você confia e que usa muito. Para tudo o mais, escope.
• Audite periodicamente. Uma vez por trimestre, liste suas aprovações ativas em cada rede e revogue tudo o que não usa mais. Ferramentas como revoke.cash tornam isso rotina.
• Desconfie de dApps desconhecidas. Um protocolo novo sem histórico de auditoria pedindo um allowance ilimitado é a combinação de maior risco em DeFi.
• Proteja as chaves que concedem aprovações. O multisig da SSP eleva a barra, mas a higiene básica ainda vale — veja boas práticas para a frase semente.

O modelo mental para levar daqui

Uma aprovação de token não é um clique; é uma chave. Cada uma fica na fechadura até você removê-la, e cada uma confere a quem a tem a capacidade de mover tokens que você ainda nem ganhou. Usados com cuidado, allowances são o encanamento que faz a DeFi funcionar. Tratados como cliques descartáveis, são o acúmulo lento de riscos que você esqueceu que assumiu.

Entenda a permissão que está concedendo, prefira concessões escopadas onde a dApp permitir e pode podar suas aprovações permanentes em um ritmo regular. Para mais detalhes de protocolo, a documentação do padrão ERC-20 em ethereum.org é a referência canônica. Novo no uso da SSP em Ethereum? Nosso guia Ethereum na SSP cobre o básico.