Plataformas Verificadas
Quick Links
Onde Permanecer Protegido
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
O predador mais lucrativo da Ethereum não foi hackeado. Nenhuma chave roubada, nenhuma seed phrase vazada, nenhum bug no código. Em 21 de junho de 2026, o bot que tirava cerca de US$ 60 milhões por ano das operações dos outros foi drenado em mais de US$ 7,5 milhões por aprovações de token que ele mesmo concedeu e esqueceu de fechar.
O perigo nunca foi a transação que ele assinou.
Foi a permissão que ele deixou de pé depois.
Este walkthrough fica com o Tao, a ponte entre estrutura e instinto na Kodex, aquele que lê um mecanismo devagar o bastante para sentir onde ele morde. Ele desmonta o que uma aprovação de token realmente concede, por que a permissão permanente sobrevive à operação que a criou, e como encontrar e revogar as que já estão na sua carteira.
Tao começa pela dele. Ele abre a lista de aprovações, o registro de cada contrato que já autorizou a mover seus tokens, e rola a tela. Uma DEX que ele usou uma vez em 2024. Uma bridge que testou e abandonou. Dois marketplaces de NFT. Um contrato de staking cujo nome ele não reconhece mais. Dezenove aprovações em aberto. Quatro delas ilimitadas.
Ele assinou cada uma. Não lembra de quase nenhuma.
"Nenhuma dessas é um ataque", ele diz. "É isso que me incomoda." Cada uma foi um clique normal em um dia normal. Cada uma continua ativa.
O que o Tao está olhando não é um pagamento. É uma permissão.
Quando você opera em uma DEX, o contrato da exchange precisa mover seus tokens por você. Tokens ERC-20 não deixam um contrato entrar na sua carteira por padrão, então primeiro você assina uma transação que diz: este contrato pode gastar até esta quantia deste token, em meu nome, a partir de agora. No código do token, essa chamada é o approve(spender, amount). Ela grava um único número, uma permissão de gasto, no contrato do token, ao lado do seu endereço.
Essa permissão é amarrada a três coisas: o token, a sua carteira, e o único contrato spender que você aprovou. Aprove um contrato diferente, ou um token diferente, e você gravou uma permissão separada. Nada liga uma à outra e nada faz a limpeza. É por isso que a lista cresce. Cada aprovação é a sua própria porta, e o contrato do token lembra de cada uma até você voltar e fechá-la.
Depois disso, o spender pega os tokens com uma segunda chamada, o transferFrom(), que puxa do seu saldo sem perguntar de novo. Esse é o sentido mais fundo de quem controla um token: posse on-chain não é quem segura a moeda, é quem tem permissão para movê-la.
A aprovação não é a operação.
É a concessão permanente que torna toda operação futura possível.
E ela não expira sozinha. A permissão que você gravou em 2024 é exatamente tão válida hoje, parada no contrato do token, esperando, até o dia em que você a zera.
Aqui está a pergunta que desmonta gente cuidadosa. Se você só assinou aprovações, nunca um saque, como algo sai da sua carteira sem a sua assinatura?
Porque o saque nunca foi seu para assinar.
O approve() é a transação que você vê. Ele cria a permissão. O saque roda no transferFrom(), chamado pelo spender, em cima da permissão que você já concedeu. Sem popup. Sem confirmação. Nada para você conferir, porque, do ponto de vista da blockchain, você já disse sim.
| O que acontece | approve() | transferFrom() |
|---|---|---|
| Você assina | Sim, uma vez | Não, nunca mais |
| Cria | uma permissão permanente | um saque que usa a permissão |
| Roda | no momento em que você aprova | a qualquer hora enquanto a permissão estiver aberta |
| Na sua carteira | um prompt de aprovação normal | nada para confirmar |
A assinatura é a porta.
O saque é alguém atravessando ela depois, enquanto você dorme.
É por isso que "eu conferi cada transação que assinei" não é proteção. A transação que esvazia a conta é justamente a que você não assina. É também por isso que um saque por aprovação é um bicho diferente dos golpes que roubam suas chaves: nenhum site de phishing pegou a seed phrase do Tao, nenhum malware copiou a chave privada dele. O atacante nunca precisa delas. Ele precisa de uma permissão que você já deu.
O jaredfromsubway.eth foi, por dois anos, o bot de sandwich mais ativo da Ethereum, citado em pesquisas por cerca de 70% dos ataques de sandwich na rede entre o fim de 2024 e o fim de 2025. Ele ganhava dinheiro fazendo front-running das operações dos outros. Era automatizado, rápido, e muito difícil de enganar.
Alguém o enganou com a própria lógica dele.
Ao longo de semanas, o atacante implantou 66 contratos de tokens falsos, imitações feitas para parecer WETH, USDC e USDT, embrulhadas em pools de liquidez desenhadas para ler como oportunidades lucrativas. O trabalho do bot era achar uma rota lucrativa e pegá-la. Para pegar essas rotas, ele aprovou contratos auxiliares controlados pelo atacante a gastar seus tokens. A crypto.news traçou como a armadilha se fechou: no começo, as aprovações pareciam inofensivas, porque cada operação usava a permissão na hora. Depois, o atacante montou rotas que deixavam a permissão aberta.
Esse foi o ataque inteiro.
A CoinDesk colocou o saque em mais de US$ 7,5 milhões, e a firma de segurança Blockaid confirmou o que ele não foi: não foi bug de contrato, não foi phishing, não foi vazamento de chave privada. O bot autorizou gastos em pools que não conseguia distinguir de falsas, e as permissões permanentes que deixou para trás foram varridas. WETH, USDC e USDT de verdade saíram, e passaram pelo Tornado Cash.
A armadilha funcionou porque dado on-chain carrega um ar de autoridade. É código de verdade em uma blockchain de verdade, e o bot confiou em uma pool de liquidez do mesmo jeito que todo mundo confia em uma transação confirmada. Forjado e falso não são a mesma coisa que parecer falso. Uma pool pode ser código genuíno, totalmente on-chain, e ainda assim ser isca. Ler o dado com perfeição não é defesa nenhuma quando o dado foi construído para ser lido.
Tao larga o café. "Ele conferia a mesma coisa que eu confiro", ele diz. "Se a operação é lucrativa, se o contrato é seguro. E morreu na permissão, não na operação."
A defesa do bot era a óbvia: conferir a transação na sua frente. A exposição dele era a permissão atrás dele. Tire os US$ 7,5 milhões e as pools falsas, e o mecanismo é o mesmo que está na carteira do Tao, e provavelmente na sua. Qualquer contrato que você já aprovou pode gastar até o limite da permissão, até você tomar essa permissão de volta.
As dezenove aprovações do Tao não chegaram todas de uma vez. Elas se acumularam do jeito que sempre acumulam.
Quatro forças enchem uma carteira de permissões abertas:
Esse é o mesmo ponto cego em que proteger sua carteira contra malware nas suas ferramentas vive: a ameaça raramente é a coisa que você está olhando. É a permissão confiável e sem graça que você concedeu uma vez e parou de pensar nela.
Uma aprovação esquecida não está dormente.
Está armada.
Não. E essa é a parte que dói.
Revogar uma aprovação zera a permissão. Fecha a porta contra o próximo saque naquela autorização. Não alcança de volta uma porta que já bateu. Tokens que foram puxados se foram, liquidados, finais, e on-chain não existe central para ligar nem transação para reverter.
Então revogar não é uma faxina que você faz depois que algo quebra. É o que você faz enquanto nada está errado, para que não haja permissão aberta esperando quando um contrato aprovado virar hostil. Você revoga antes de ser alvo, porque depois a única porta que sobra para fechar é a que o atacante já usou. Proteger a carteira, do jeito que proteger sua carteira explica, é um conjunto de hábitos que você constrói na calmaria, não na emergência.
A hora de fechar uma porta é antes de alguém atravessar.
Suas aprovações são públicas.
E fechá-las também.
Cada permissão que você concedeu está registrada on-chain, no seu endereço. Você pode ler a lista no verificador de aprovações de um block explorer, ou em uma das ferramentas de carteira que mostram o mesmo dado on-chain de forma mais clara, a revoke.cash entre elas. A Kodex não vende produto de revoke e não tem motivo para empurrar nenhum. O que importa é o hábito, não a marca.
Três movimentos:
Tao desce pelas dezenove. A bridge que ele abandonou: revogada. A aprovação ilimitada de USDC para uma exchange que ele não toca há um ano: revogada. As duas que ele ainda usa, ele limita a um valor fechado e mantém. Seis minutos. Alguns centavos de gas.
"É essa a defesa inteira que o bot não tinha", ele diz.
A lição dos US$ 7,5 milhões não é que o bot foi descuidado. Ele lia cada operação. É que ler a operação nunca foi o bastante, porque a exposição nunca foi a operação.
Então a disciplina é pequena e repetível. Antes de assinar uma aprovação, leia-a como quatro perguntas: qual token, quanto, para quem, por quanto tempo. Depois, coloque uma rodada de revoke em uma cadência, mensal, ou toda vez que terminar com um protocolo, do mesmo jeito que o Framework de Sobrevivência trata risco como algo que você gerencia antes de a posição virar contra você, não depois. Carregar menos permissões abertas é exatamente o tipo de exposição estrutural que o Pattern Intelligence da Kodex foi feito para revelar: o hábito silencioso e repetido que não custa nada até o dia em que custa tudo.
O bot que drenou todo mundo morreu em uma porta que deixou aberta. As aprovações esquecidas na sua carteira são a mesma porta.
Feche-as enquanto ainda são chatas.
Uma aprovação de token é a permissão que você concede a um contrato inteligente para gastar um token específico da sua carteira, até um valor definido, pela função approve(). É o que deixa uma DEX, uma bridge ou um marketplace mover seus tokens durante uma operação. A permissão fica ativa até você revogar.
Não. Desconectar encerra a sua sessão com um site, mas deixa intacta cada permissão que você concedeu no contrato do token. Um contrato aprovado ainda pode gastar em cima daquela permissão depois que você desconecta. Só uma transação de revoke on-chain zera a permissão.
Uma aprovação ilimitada define a permissão no valor máximo que o token permite, então o contrato pode gastar qualquer quantia daquele token, sem limite e sem prazo. Ela poupa você de reaprovar, e significa que um único contrato comprometido alcança todo o seu saldo daquele token. Uma aprovação limitada trava o gasto na quantia que você de fato precisa.
Não sozinha. Uma hardware wallet protege a sua chave privada, mas você ainda assina o approve() com ela, e assinar em um dispositivo não revoga uma permissão permanente. A proteção é ler as aprovações antes de concedê-las e revogar as que você não precisa, com hardware ou sem.
Uma rodada mensal é um ritmo razoável, mais um revoke toda vez que você parar de usar um protocolo ou terminar uma interação pontual. O objetivo é carregar o mínimo de permissões abertas possível, para que um contrato que vire hostil mais tarde não ache nada seu ainda autorizado.
