Como revogar aprovações de tokens e porque deve fazê-lo

O que é realmente uma aprovação de token

Quando faz swap de um token na Uniswap, empresta ETH na Aave ou faz bridge de USDC entre cadeias, na verdade não entrega os seus tokens ao protocolo. Assina uma pequena mensagem on-chain que diz: "o contrato inteligente X pode puxar até N do token Y da minha carteira." Essa permissão assinada chama-se aprovação ERC-20 e vive on-chain para sempre, a menos que você, ou o próprio contrato, a cancele.

A razão pela qual as aprovações existem é técnica. Os tokens ERC-20 são ativos simples ao portador: não têm noção de "Alice empresta 100 USDC ao Bob." Só entendem saldos e allowances. Para permitir que um contrato de terceiros, como um router de DEX ou uma pool de empréstimos, mova os seus tokens por si, esse contrato tem de receber uma allowance, que é definida com duas funções: approve e increaseAllowance.

A maioria dos protocolos pede o valor máximo possível, o maior inteiro sem sinal de 256 bits (2^256 menos 1), porque isso lhes poupa de lhe pedir para assinar uma nova aprovação cada vez que interage. Do ponto de vista de UX, as aprovações infinitas são convenientes. Do ponto de vista de segurança, criam uma permissão que pode esquecer que alguma vez concedeu.

Porque é que as aprovações infinitas são perigosas

Uma aprovação infinita não é "risco infinito" por si só. É apenas tão perigosa quanto o contrato que detém a allowance. Se o protocolo que aprovou for bem auditado, testado ao longo do tempo e ainda operado pela mesma equipa, a aprovação é aproximadamente tão segura quanto o próprio protocolo. O perigo surge em três situações específicas, e são comuns o suficiente para serem levadas a sério.

Primeiro, os protocolos são hackeados. Um contrato inteligente pode ser explorado através de um bug de lógica, uma manipulação de price oracle ou um ataque de governance. Se o atacante conseguir chamar transferFrom contra uma lista de utilizadores aprovados, uma aprovação infinita transforma um bug do protocolo numa drenagem direta dos seus tokens. Isto não é hipotético: vários incidentes conhecidos em DeFi nos últimos anos incluíram caminhos de drenagem de tokens que se aproveitaram de allowances existentes.

Segundo, os projetos são abandonados e depois relançados por outra pessoa com o mesmo nome ou no mesmo endereço. Quando uma equipa abandona um contrato, o bytecode nesse endereço é apenas código. Se um novo owner ou mecanismo de upgrade permitir que um atacante se torne o admin, a sua aprovação antiga passa a apontar para uma entidade hostil.

Terceiro, e este é o que a maioria dos utilizadores subestima, os kits de drenagem de carteiras filtram ativamente carteiras com aprovações pendentes. Quando assina uma assinatura maliciosa num site de phishing, o kit não se limita a roubar o token que está na página; percorre todas as allowances ativas que a sua carteira já concedeu e puxa cada uma delas. O dano de um único clique de phishing escala com a quantidade de superfície antiga que tem. Menos aprovações abertas significa um raio de impacto mais pequeno.

Que aprovações são realmente seguras de manter

Nem todas as aprovações são uma bomba-relógio, e tentar ter zero aprovações é simultaneamente impraticável e inútil. O objetivo é reduzir a sua superfície de ataque, não destruir a capacidade de funcionamento da sua wallet. Uma regra de bolso razoável tem três níveis.

Mantenha as aprovações para contratos que utiliza ativamente, que são geridos por equipas reputadas, que foram auditados e que não foram explorados recentemente. Se continua a usar Aave ou Uniswap semanalmente, a aprovação que essas front-ends gerem faz parte do funcionamento do sistema. Revogá-la significa apenas voltar a assinar da próxima vez que fizer uma transação, o que custa gas e um pouco de atenção.

Reduza as aprovações infinitas em contratos que utiliza raramente. Wallets modernas como a Rabby, a Frame e a versão atualizada da MetaMask têm como padrão uma allowance finita com base no valor da transação. Se um contrato em que tocou uma vez ainda tem uma aprovação infinita de há dois anos, reduza-a para zero ou para um valor finito pequeno.

Revogue aprovações para tudo o que não reconhece, tudo o que apresente um nome de que nunca ouviu falar e, em especial, tudo em que o contrato não esteja verificado no Etherscan. Contratos não verificados com allowances ativas são o padrão isolado mais comum que os drainer kits exploram.

Como encontrar todas as aprovações que a sua wallet concedeu

Existem duas ferramentas que vale a pena confiar para esta tarefa, e cobrem praticamente todas as chains EVM em uso ativo. A primeira é o Revoke.cash, uma dApp open source criada especificamente para gestão de allowances. Liga a sua wallet, ela faz o scan da chain e lista todos os contratos que têm atualmente uma allowance não-zero sobre os seus tokens, agrupados por token. Cada linha mostra o spender, a allowance atual e uma ligação direta para a transação de revogação on-chain.

A segunda é o token approval checker do Etherscan, disponível no Etherscan para a Ethereum e nos block explorers equivalentes para chains como BNB Chain, Polygon, Arbitrum, Optimism e Base. Cole o endereço da sua wallet, clique no separador de aprovações e verá os mesmos dados com uma interface ligeiramente mais técnica. O Etherscan é útil como verificação cruzada porque o Revoke.cash ocasionalmente deixa passar allowances em tokens mais recentes ou menos comuns.

Qualquer que seja a ferramenta que utilize, o fluxo de trabalho é o mesmo. Leia cada spender. Se não o reconhece, marque-o para revogação. Se o reconhece, decida se ainda precisa dele e se quer deixá-lo infinito. Tenha em atenção que revogar é uma transação de escrita: custa gas, por isso faça-o em lotes num momento de taxas baixas, em vez de uma a uma nas horas de pico.

Como revogar aprovações de tokens passo a passo

Aqui está o fluxo de trabalho prático que utilizadores experientes de DeFi realmente seguem. Parte do princípio de que está a usar uma wallet de self-custody como Rabby, MetaMask, Frame ou Ledger Live e de que tem uma pequena quantidade de ETH na chain que está a limpar, suficiente para cobrir o gas.

Abra o Revoke.cash no seu browser. Ligue a wallet que pretende auditar. O site assume Ethereum mainnet por predefinição; se as suas aprovações estão noutra chain EVM como Arbitrum, Polygon ou BNB Chain, troque o seletor de rede no topo da página. O site irá então recolher todos os tokens que detém e todas as allowances ativas numa só passagem.

Leia a lista. Para cada spender que não reconhece, ou qualquer spender com o qual já não quer manter uma allowance permanente, clique no botão de revogação ao lado dele. A sua wallet abrirá um pedido de transação que define a allowance como zero. Confirme e pague a taxa de gas.

Para aprovações que quer manter mas quer reduzir, o Revoke.cash permite-lhe definir um valor personalizado em vez de zero. Um padrão comum é definir a allowance para o valor exato necessário na próxima transação, que as wallets modernas podem preencher automaticamente. Depois de as suas transações de revogação confirmarem, atualize a página e confirme que a allowance agora indica zero ou o novo valor finito.

Repita para quaisquer outras chains onde tenha feito atividade DeFi relevante. Muitos utilizadores ficam chocados ao descobrir aprovações em chains que usaram uma vez para um airdrop e esqueceram. Cada chain precisa da sua própria passagem, uma vez que as allowances não são cross-chain por predefinição.

Como definir aprovações finitas daqui em diante

O melhor hábito que pode criar depois de limpar a sua wallet é parar de assinar aprovações infinitas desde o início. A defesa está integrada na maioria das UIs de wallets modernas, mas tem de a notar.

Quando uma dApp pede uma allowance, olhe para o valor. Se o padrão é o número máximo de 256 bits, a sua wallet está a oferecer o caminho infinito antigo. Se o padrão é o valor exato do swap ou do depósito, a sua wallet está a oferecer uma aprovação finita. Tanto a Rabby como a Frame têm finito como padrão para contratos conhecidos. A MetaMask mudou para padrões finitos nas suas versões mais recentes, embora fluxos mais antigos ainda exponham a opção legada.

Se um contrato exigir uma aprovação infinita e não oferecer opção finita, trate isso como um sinal amarelo. Alguns contratos precisam genuinamente de uma allowance permanente, como agregadores DEX que encaminham através de múltiplos pools, mas a maioria não. Na dúvida, aprove o valor exato para a transação que está prestes a fazer e revogue ou reduza a allowance assim que a ação terminar.

Outro hábito prático é usar uma wallet "quente" separada para atividades de alto risco, como farming de airdrops, interações em testnet e assinatura de dApps desconhecidas, e uma wallet "fria" separada para holdings de longo prazo e posições DeFi grandes. A wallet quente leva com os cliques de phishing; a wallet fria só interage com protocolos auditados e bem conhecidos. Mesmo que um drainer kit esvazie a sua wallet quente, a sua stack principal está numa wallet com uma pegada de aprovações muito mais pequena.

Como isto se parece quando algo corre mal

Vale a pena ser concreto sobre o aspeto de um drain na prática, porque o medo de "as minhas aprovações vão ser exploradas" é por vezes tratado como abstrato. Imagine que assinou uma aprovação infinita para USDT num pequeno router de uma DEX há dezoito meses. A DEX encerrou, a equipa seguiu em frente, e o endereço do contrato foi posteriormente assumido por um deployer diferente.

Seis meses depois, visita um site com aspeto familiar, clica no que pensa ser uma aprovação rotineira e, na verdade, assina um permit ou uma autorização off-chain maliciosa. O drainer kit vê que a sua carteira ainda tem uma allowance infinita para esse router. Numa única transação, chama transferFrom e esgota todo o seu saldo de USDT. A transação é válida, a allowance era real, e não há rollback.

Agora imagine a mesma carteira, mas em que revogou a allowance de USDT para esse router seis meses antes e a substituiu por zero. O drainer kit analisa a sua carteira, não encontra nada para puxar relativamente a esse token, e segue em frente. O custo da revogação original foram uns cêntimos de gas; o custo de não revogar foi o seu saldo total de USDT. A conta não é subtil.

Como acompanhar o risco de aprovações de forma inteligente

A higiene de aprovações é uma das poucas áreas da segurança em cripto em que o utilizador tem mesmo controlo direto, mas é fácil de esquecer quando a sua carteira está "a funcionar". A Zippfeed acompanha notícias relacionadas com aprovações de tokens, incluindo exploits de protocolos, campanhas de drainer kits e atualizações de segurança de carteiras, com pontuação de sentimento (bullish, neutral ou bearish) e uma classificação de importância, para que consiga detetar novos padrões de ataque antes de chegarem à sua caixa de entrada em vez de depois de chegarem à sua carteira.