Um projeto muda para um novo contrato de token, anuncia uma janela de troca e a janela fecha. Meses depois você abre uma carteira antiga e o saldo do token antigo ainda está lá. Se ele ainda pode ser convertido não é uma pergunta com uma resposta só. Numa migração vencem três coisas diferentes, cada uma é aplicada em um lugar diferente e apenas uma delas é aplicada por código.
O que uma migração de token realmente move
Uma migração não move seus tokens para lugar nenhum. O contrato antigo continua rodando no próprio endereço, e seu saldo permanece no registro dele enquanto a rede funcionar. O que uma migração oferece é uma troca: você entrega unidades antigas a um contrato de troca ou a uma plataforma, e ela credita a você o direito equivalente em um registro novo.
Essa troca roda no encanamento comum dos tokens. No padrão ERC-20, `approve` permite que um gastador retire da sua conta até um valor definido, e `transferFrom` move tokens de um endereço para outro; o padrão apresenta esse par como um fluxo de retirada que permite a contratos moverem tokens em seu nome. Um contrato de troca é um desses gastadores, e a rede não lhe dá status especial.
Daí seguem duas coisas. Seu saldo antigo não se deteriora nem caduca sozinho, e o prazo nunca é uma propriedade dos tokens que você tem. O prazo pertence a quem está do outro lado da troca, pronto para pagar. A pergunta, então, não é se seus tokens venceram. É o que aconteceu com a contraparte.
Três coisas podem vencer, e não são a mesma coisa
Num anúncio de migração típico, a palavra prazo faz trabalho demais. Separe-a e aparecem vários relógios distintos, cada um aplicado em outro lugar.
O primeiro é a própria data anunciada, uma linha num blog ou um banner num aplicativo. Nada na rede a lê. O segundo é uma verificação escrita no contrato de troca, que se recusa a executar assim que o carimbo de tempo do bloco atual passa de um valor fixado no código. O terceiro é a reserva de tokens novos com a qual o contrato paga, e quem a aportou pode retirá-la quando o projeto considerar a migração encerrada.
| O que venceu | Onde é aplicado | O que seria preciso para reabrir |
|---|---|---|
| A data anunciada | Em lugar nenhum da rede | Nada, o contrato nunca a verificou |
| Uma verificação de carimbo de tempo no contrato de troca | O código do contrato | Um caminho de atualização, se foi previsto |
| A reserva de tokens novos | Um saldo na rede | Que alguém recarregue o contrato |
| Um atendimento de migração numa plataforma | A política interna dessa plataforma | Uma decisão dessa plataforma |
Tudo o que vem abaixo é como descobrir em qual linha você está.
Leia o contrato antes de considerá-lo fechado
As duas primeiras linhas você resolve sozinho e de graça. Abra o contrato de troca em um explorador de blocos e leia o código-fonte verificado. Se a função de troca não tiver nenhuma comparação com um carimbo de tempo de bloco, não há prazo no código, e a data anunciada nunca foi mais do que um comunicado. Nesse caso, uma troca enviada um ano depois roda exatamente como uma enviada no primeiro dia.
Se houver uma verificação de carimbo de tempo, essa é outra conclusão, e firme. O código de um contrato faz o que foi escrito nele, e uma condição que reverte depois de um momento fixado vai continuar revertendo. Nenhum chamado de suporte muda isso, porque não há ninguém para convencer: a recusa é uma linha de código executando como planejado.
A única ressalva é a atualizabilidade. Se a troca fica atrás de um proxy cuja lógica pode ser substituída, o prazo pode em princípio ser levantado por quem detém esse poder. Isso é uma decisão do projeto, não um direito seu, mas é a diferença entre uma porta fechada e uma porta soldada, e ler o contrato é como se distingue uma da outra.
Quando o contrato está aberto mas a reserva está vazia
Um contrato sem prazo ainda assim não paga de uma conta vazia. Os tokens novos precisam sair de uma reserva mantida no endereço de troca, e se o projeto escreveu uma função que varre o que sobra quando a janela fecha, ele pode esvaziar essa reserva. Depois dessa varrida, a função de troca pode continuar aceitando seus tokens antigos e mesmo assim falhar, porque atrás da perna de pagamento não há mais nada.
Vejamos um exemplo. Um projeto consolida à razão de uma unidade nova para cada dez antigas, e uma carteira tem 25.000 unidades antigas, então o direito é de 2.500 novas. Suponha que 96% da oferta antiga tenha passado durante a janela; os 4% restantes são justamente a parte que os atrasados reivindicam, e se o contrato ainda pode honrar essas reivindicações se resume ao saldo de tokens novos no endereço de troca. Esse saldo é público. Consulte-o antes de enviar qualquer coisa.
Este é o caso que pune o otimismo. Enviar tokens antigos para um contrato que não pode pagar você não o deixa onde estava: as unidades antigas foram para um endereço que nunca foi escrito para devolvê-las, e você não tem nada novo. Leia a reserva primeiro e, se estiver vazia, não envie.
Migrações que uma plataforma fez por você
Algumas migrações nunca tocaram sua carteira. Se você mantinha o token antigo numa plataforma centralizada durante a troca, a plataforma converteu o próprio saldo agrupado e reescreveu o lançamento da sua conta, então a migração apareceu na sua conta como uma mudança de ticker e mais nada.
Esse caminho tem o próprio relógio, e é política, não regra da rede. Uma plataforma anuncia uma janela de conversão, credita os saldos que chegam dentro dela e em algum momento para. O formato é conhecido da deslistagem de tokens: um aviso, uma janela e depois acesso fechado, com a recuperação posterior dependendo de a casa ainda manter um processo manual para retardatários.
Há aqui, portanto, duas perguntas e não uma, e elas têm respostas diferentes. Se a plataforma ainda vai creditar um depósito atrasado de tokens antigos é uma pergunta de suporte. Se o contrato de troca na rede ainda vai pagar é uma pergunta de código. Responda separadamente, porque um não de um lado nada diz sobre o outro.
O que sobra quando o caminho na rede fecha de vez
Suponha que o código esteja fechado, a reserva varrida e nenhum atendimento vá processar uma reivindicação atrasada. O token antigo não deixou de existir. É um saldo num contrato que continua rodando, ainda pode ser transferido e, portanto, vendido a quem quiser comprar, pelo preço que o mercado de um registro abandonado der.
Não procure um atalho enviando as unidades antigas para algum lugar que pareça promissor. Enviá-las ao novo contrato do token, ou ao próprio contrato antigo, é a mesma classe de erro que mandar cripto para o endereço errado: um contrato não tem chave privada e, se ninguém escreveu uma função para tirar tokens perdidos de dentro dele, ninguém consegue. O padrão ERC-223 foi escrito exatamente em torno dessa falha, observando que tokens enviados a um contrato com uma transferência simples chegam como um saldo do qual o contrato nunca fica sabendo.
O resumo honesto desse caso é que o tamanho da perda já está fixado, e cada transação seguinte só pode aumentá-lo. Segurar a posição não custa nada. Chutar um resgate pode custar o resto.
O prazo de migração é isca para impostores
Uma janela que vence cria pressa, um fluxo de detentores confusos e um motivo legítimo para um projeto pedir que as pessoas conectem uma carteira. Os atacantes não precisam inventar nada disso. Precisam apenas de um site sósia. Essa é a forma dos golpes de falsa identidade, e é por isso que um resultado de busca é o jeito errado de chegar a um portal de migração.
O mecanismo que um portal falso quer é o mesmo que uma troca real usa. Uma migração genuína pede uma permissão para que o contrato possa puxar seus tokens antigos, e as aprovações de tokens concedidas a um atacante fazem exatamente o que dizem: deixam aquele endereço levar o saldo que você aprovou. Conceda uma permissão limitada em vez de ilimitada, confira o endereço do contrato com o anúncio publicado pelo próprio projeto e chegue ao site pelo seu próprio favorito.
Uma regra atravessa a categoria inteira. Todo fato de que você precisa numa migração atrasada é lido de graça num explorador público: o código-fonte do contrato, a verificação de carimbo de tempo, o saldo da reserva. Quem cobra para reabrir uma migração fechada, ou pede uma frase de recuperação para isso, está vendendo a segunda perda e não o conserto da primeira.
Em resumo
Tokens antigos não vencem. Contrapartes vencem. Uma data anunciada não obriga ninguém na rede; uma verificação de carimbo de tempo no contrato de troca obriga todo mundo, inclusive o projeto; e uma reserva varrida fecha a porta com a mesma firmeza, deixando a maçaneta no lugar. Esses três casos parecem idênticos na tela de uma carteira e são completamente diferentes por baixo.
A ordem do trabalho é fixa. Leia o contrato de troca num explorador, procure a verificação de carimbo de tempo, depois leia o saldo da reserva naquele endereço e, se houve plataforma envolvida, pergunte a ela separadamente. Se tudo isso voltar fechado, o saldo antigo continua sendo seu e continua transferível, e nenhuma pressa deveria levar você a mandá-lo para um lugar que não consegue mandar nada de volta. 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
- Por que uma migração de token pede uma aprovação na carteira
- Migração de tokens concluída mas os novos tokens não aparecem
- Como calcular a autonomia da tesouraria de um token
- Futuros com margem em moeda vs. margem em USDT: qual contrato negociar
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-223: Token with transaction handling model, seção Motivation (status: Final) eips.ethereum.org
