Um projeto muda para um contrato novo, você abre a página de migração e, antes que um único token tenha se movido, a carteira pede para aprovar o antigo. O pedido parece um passo extra que alguém acrescentou ao fluxo. Não é. No ERC-20 essa é a única forma de entregar um saldo a alguém que não seja você, e saber lê-lo separa uma migração de uma carteira esvaziada.
O que a aprovação realmente concede
Uma aprovação é uma escrita em um registro que vive dentro do contrato do token antigo. Ela anota um único número para um par de endereços: quanto daquele token um gastador nomeado pode retirar da sua conta. Assiná-la não move nada, não envia nada ao projeto e não compromete você com nenhuma troca.
No padrão token ERC-20, esse registro é alcançado por duas funções. `approve` permite que um gastador saque da sua conta repetidamente, até um valor definido, e `transferFrom` é a chamada que de fato move os tokens de um endereço para outro. A especificação apresenta o par como um fluxo de saque que deixa contratos transferirem tokens em seu nome, e um contrato de migração é um desses contratos, sem qualquer posição especial.
Onde a anotação fica guardada pesa mais do que parece. A permissão fica no token antigo, não no contrato de migração, então ela sobrevive à página de migração, à própria troca e ao projeto. Fechar a aba não a apaga.
Por que o contrato de troca precisa pedir
Uma troca precisa tomar as unidades antigas antes de creditar as novas. O contrato não consegue alcançar sua conta sozinho, e sobre o seu saldo o contrato do token só escuta a conta que o detém.
A alternativa aparente é você mesmo enviar os tokens antigos ao contrato com uma transferência comum. Isso move os tokens de fato, e também falha: uma transferência simples chega como saldo sem nenhuma chamada acompanhando, então o contrato nunca é avisado da transferência e não tem contra o que creditar. O padrão ERC-223 foi escrito exatamente em torno dessa falha. Puxar com `transferFrom` dá ao contrato uma única chamada na qual ele recebe as unidades antigas e paga as novas, e essa chamada precisa de uma permissão antes.
Duas transações, e só a segunda troca
A aprovação e a troca são transações separadas, cada uma com o próprio gas. O ERC-2612 coloca o formato de forma direta: se um usuário precisa interagir com um contrato inteligente, então ele precisa fazer 2 transações, `approve` e a chamada do contrato que internamente chamará `transferFrom`.
Justamente por serem separadas, a primeira pode dar certo enquanto a segunda ainda falha. Uma janela de troca já encerrada, uma reserva de pagamento esvaziada, um contrato pausado: nada disso é visível para a aprovação, que apenas escreve um número e retorna. Uma aprovação confirmada não é prova de que a migração por trás dela funciona.
A armadilha inversa fica um passo adiante. Uma troca depois de uma simulação bem-sucedida ainda pode reverter on chain, porque a simulação responde a uma pergunta sobre o estado em um momento e não sobre o estado em que sua transação aterrissa. Quando a troca reverte, a permissão que você concedeu fica intacta e continua de pé.
Migrações que não têm motivo para pedir
Nem toda migração funciona com permissão. O formato que anunciaram a você deve bater com o pedido que você recebeu.
| Como a migração é conduzida | O que você envia | Cabe uma aprovação aqui |
|---|---|---|
| Um contrato de troca puxa suas unidades antigas | Uma aprovação e depois a chamada de troca | Sim |
| Você transfere os tokens antigos para um endereço divulgado | Uma transferência comum | Não |
| Detentores registrados são creditados a partir de um snapshot | Nada | Não |
| Uma plataforma converte o próprio saldo agrupado | Nada | Não |
A linha que deve fazer você parar é a terceira. Uma distribuição anunciada como automática não tem mecanismo algum que precise da sua permissão, então uma página que a pede está pedindo algo que a migração descrita não usa. Notar esse descompasso não custa nada e não depende do julgamento de ninguém sobre o site.
Os três campos do pedido que decidem tudo
Todo pedido de aprovação carrega os mesmos três campos, seja qual for o nome que a sua carteira dá a eles.
| Campo | O que ele concede | Contra o que conferir |
|---|---|---|
| Token | Em qual registro de contrato a anotação é escrita | O endereço do contrato antigo no anúncio do próprio projeto |
| Gastador | Qual endereço pode puxar da sua conta | O endereço do contrato de migração no mesmo anúncio |
| Valor | O teto do que aquele endereço pode levar | A parcela que você pretende trocar agora |
Compare os endereços por inteiro. Um endereço parecido pode compartilhar com o verdadeiro os primeiros e os últimos caracteres, e a diferença fica no meio.
O campo do gastador é o que carrega o prejuízo, e por isso um drainer de carteira não precisa quebrar nada. Ele coloca o próprio endereço nesse campo e deixa você assinar uma aprovação válida e bem formada. A transação é bem-sucedida exatamente como está escrita, e o saldo sai depois, no calendário do atacante e não no seu.
Quando o pedido é uma assinatura e não uma transação
Uma permissão nem sempre chega como transação. O ERC-2612 estende o padrão ERC-20 com uma função `permit` que permite aos usuários modificar o mapeamento allowance por meio de uma mensagem assinada, em vez de passar por `msg.sender`; um permit válido define a permissão daquele gastador no valor indicado, incrementa um nonce e emite um evento de aprovação.
A consequência é que uma tela com apenas uma mensagem para assinar, sem gas e sem transação pendente, consegue conceder exatamente o que uma transação de aprovação concede. No momento em que você assina, ela também não deixa nada no seu próprio histórico de transações, porque a mensagem assinada é enviada por outra pessoa.
Então leia um pedido de assinatura pelos mesmos três campos. Um permit nomeia o gastador e o valor que está definindo, mais um deadline que a especificação exige que o tempo do bloco atual não ultrapasse. Se uma página apresenta a assinatura como um login ou uma confirmação enquanto os dados tipados nomeiam um gastador e um valor, o que será executado são os dados tipados.
Valor exato ou ilimitado, e a permissão que fica para trás
Veja um exemplo. Uma carteira tem 10.000 unidades antigas e o projeto abriu uma troca. Aprovar 2.500, trocar essa parcela e conferir o que chega contra a proporção anunciada transforma a migração em algo observado, e não presumido. As 7.500 restantes precisam então de uma segunda aprovação, ou seja, mais um pagamento de gas, e esse é todo o custo do método.
Uma aprovação ilimitada elimina esse segundo pagamento e o troca por uma permissão permanente sobre aquele token enquanto a anotação existir. O contrato de migração mantém o direito de puxar quaisquer unidades antigas que cheguem à sua conta depois, incluindo um saldo de tokens antigos que você recupere anos mais tarde de uma carteira velha.
Termine limpando o que sobrou. Uma aprovação de valor exato é consumida pela troca para a qual foi concedida, enquanto qualquer coisa maior deixa uma anotação viva, e uma aprovação de tokens que sobrevive ao seu propósito é uma permissão que ninguém mais está observando. Zerar a permissão é em si uma transação com o próprio gas, então faça isso de forma deliberada assim que a migração terminar.
Em resumo
Uma migração pede uma aprovação porque o ERC-20 não lhe dá outro jeito de tomar seus tokens antigos. A aprovação em si é um número escrito no contrato do token antigo nomeando um endereço e um teto: ela não move nada, não prova nada sobre a migração por trás dela e não expira quando a página fecha.
Isso reduz todo o trabalho a três conferências. Este formato de migração precisa mesmo de uma permissão, o gastador é o endereço que o projeto divulgou, e o valor é a parcela que você pretendia trocar. Um pedido de assinatura responde às mesmas três, e uma permissão concedida sobrevive a tudo ao redor, então limpe-a quando a troca estiver feita. Para continuar aprendendo os fundamentos, acompanhe mais conteúdos da Bitbase Academy.
Leituras relacionadas
Outros artigos da Bitbase sobre este tema:
- Como revogar uma delegação de governança
- Como calcular a autonomia da tesouraria de um token
- Mecânica de oferta de um token
- O ATR e a medição da volatilidade
- Bandas de Bollinger explicadas
Aviso: Este artigo é conteúdo educacional da Bitbase Academy, fornecido apenas para fins informativos. Não constitui aconselhamento de investimento, negociação, tributário ou financeiro. Criptoativos são voláteis; avalie seu próprio risco. Escrito em setembro de 2026; consulte as informações oficiais mais recentes.
Fontes
[1] Ethereum Improvement Proposals, ERC-20: Token Standard, os métodos approve e transferFrom (status: Final) eips.ethereum.org
[2] Ethereum Improvement Proposals, ERC-2612: Permit Extension for EIP-20 Signed Approvals, seções Abstract e Specification (status: Final) eips.ethereum.org
[3] Ethereum Improvement Proposals, ERC-223: Token with transaction handling model, seção Motivation (status: Final) eips.ethereum.org
