Você aprovou o contrato de troca, enviou o saldo do token antigo e o explorador marcou a transação em verde. O ticker anterior sumiu e nada tomou o seu lugar. Ou as novas unidades não existem, ou existem e nada as está desenhando. Esses dois casos parecem idênticos na tela de uma carteira e pedem respostas completamente diferentes.
O que uma troca concluída realmente atesta
Uma transação de troca confirmada diz que sua chamada chegou a um bloco e que a parte mais externa da execução não reverteu. É só isso. Um status do recibo de sucesso é uma afirmação sobre a chamada, não um inventário do que a chamada creditou.
Uma troca de migração tem duas pernas, e por isso essa lacuna pesa mais aqui do que em outros lugares. Uma perna retira suas unidades antigas. A outra paga as novas. O recibo cobre a transação como um todo, e um contrato pode ser escrito de modo que a segunda perna faça menos do que você esperava, ou nada, sem que a primeira se desfaça.
Então a pergunta a responder não é se a troca funcionou. É se agora existe um saldo novo escrito contra o seu endereço e, se existe, por que nada o desenha. São duas investigações separadas, e fazê-las nessa ordem evita discutir com um atendimento sobre um saldo que você já possui.
Onde o novo saldo fica realmente registrado
O novo token é um contrato comum com seu próprio livro, e o padrão de tokens ERC-20 registra sua posição nele duas vezes: uma como evento no momento do crédito e outra como valor que o contrato responde quando perguntado.
O evento é o Transfer, que pelo padrão DEVE ser disparado quando tokens são transferidos, inclusive em transferências de valor zero. Ele acrescenta que um contrato de token que cria novos tokens DEVERIA disparar um evento Transfer com o endereço do remetente definido como 0x0. Uma migração que emite contra o seu endereço deixa portanto uma transferência do endereço zero para você, e uma que paga a partir de uma reserva pré-financiada deixa uma transferência dessa reserva. De um jeito ou de outro há uma linha a procurar.
O valor é balanceOf, que o padrão descreve como retornando o saldo da conta de outra conta com um dado endereço de proprietário. É uma leitura, não custa nada e responde pelo presente, não pelo momento da troca. Abra o novo contrato em um explorador de blocos e chame balanceOf com o seu próprio endereço. O número devolvido é a resposta que vale.
| O que você pode ler | O que isso resolve |
|---|---|
| O status do recibo da troca | Apenas que a chamada externa não reverteu |
| Um evento de transferência para o seu endereço | Que novas unidades foram creditadas a você então |
| A leitura de balanceOf no novo contrato | Quanto você tem naquele livro agora |
| A lista de ativos da sua carteira | Nada sobre propriedade |
Por que o saldo pode ser seu e a carteira não mostrar nada
A última linha resolve a versão disso que sai de graça. Uma carteira não varre cada contrato da rede atrás do seu endereço. Ela desenha uma lista de ativos que mandaram acompanhar, e um contrato implantado na semana passada não está nessa lista até que algo o coloque lá.
É uma lacuna conhecida, não um defeito. A EIP-747, o padrão por trás do método wallet_watchAsset, o descreve como uma forma de permitir que um cliente sugira à carteira do usuário um token para acompanhar, e afirma que sem ele cada carteira precisa pré-carregar uma lista de ativos aprovados ou os usuários devem adicionar ativos manualmente. Uma migração produz exatamente esse caso.
A correção é adicionar o contrato à mão, com o endereço tirado do anúncio do próprio projeto e não de um resultado de busca ou mensagem de chat. Assim que a carteira passar a acompanhá-lo, o saldo aparece de imediato se já estava lá, porque nada da sua posição mudou. Se ainda ler zero, a exibição está descartada e todo o resto está na rede.
Quando a troca creditou um endereço que não é seu
Um contrato de troca precisa decidir a quem pagar, e esse endereço nem sempre é o que você tinha em mente. Se o contrato credita quem chama, a conta que assinou é a conta que recebeu, e essa é a errada quando duas contas estão abertas no mesmo perfil do navegador.
A versão mais difícil envolve um intermediário. Unidades antigas mantidas em uma plataforma centralizada ficam sob o endereço dela, e uma troca enviada de um endereço de depósito paga a quem esse endereço pertence. O mesmo vale para uma carteira de contrato inteligente ou uma multiassinatura. Leia o evento de transferência e observe o campo de destinatário: ele nomeia o endereço creditado, e se não for um dos seus, os tokens nunca iriam aparecer onde você está olhando.
Um caso puramente burocrático merece ser eliminado primeiro. Algumas migrações emitem o novo token em uma rede diferente da antiga, então o crédito cai em uma rede para a qual sua carteira não está apontada. Trocar de rede resolve isso em segundos.
Quando as unidades antigas saíram e nada voltou
Se o evento de transferência não existe e balanceOf lê zero enquanto o saldo antigo realmente sumiu, a perna do pagamento não rodou, e as razões são poucas.
A primeira é uma reserva vazia. Uma troca que paga com tokens pré-financiados em vez de emiti-los pode aceitar seu depósito e não pagar, porque a conta de onde ela paga foi esvaziada. É dessa falha que o prazo da janela de troca protege, e por isso ler a reserva antes de enviar pesa mais do que ler o anúncio.
A segunda é um valor menor que o esperado, e não ausente. Confira a razão de conversão e as casas decimais dos dois contratos antes de concluir que nada chegou. Uma carteira com 40.000 unidades antigas, em uma consolidação de uma unidade nova para cada quatro antigas, tem direito a 10.000 unidades novas, ou seja 25% do número a que estava acostumada. Em um contrato com outro valor de decimals, um crédito correto também pode aparecer com a vírgula em um lugar incomum.
A terceira é que as unidades antigas foram para um lugar sem perna de pagamento associada. Enviar tokens direto para um endereço de contrato em vez de passar pela interface que o chama não dispara a troca. O padrão torna isso possível porque approve permite a um gastador sacar da sua conta até um valor definido, e transferFrom serve a um fluxo de saque que permite a contratos transferir tokens em seu nome. Um contrato de troca espera puxar de você, não receber algo sobre o qual nunca foi avisado.
Migrações que uma plataforma executou pela sua conta
Um caminho diferente produz a mesma queixa por razões bem outras. Se você mantinha o token antigo em uma plataforma centralizada durante a migração, ela converteu o próprio saldo agrupado e reescreveu o registro da sua conta, e o evento apareceu como uma mudança de ticker sem nenhuma transação sua.
Nesse caminho não há transação de troca a inspecionar, então nenhuma das verificações na rede se aplica. O que se aplica é o cronograma da plataforma: uma suspensão de depósitos e saques do token antigo, uma conversão aplicada aos saldos das contas e uma retomada sob o novo ticker. Um saldo ainda não convertido durante essa suspensão está pausado, não perdido.
Os dois caminhos também escalam de formas diferentes. Uma plataforma que não creditou você é uma questão de suporte com uma contraparte nomeada. Uma troca na rede que não pagou não tem contraparte no circuito, porque o contrato executou o que foi escrito nele.
O que checar, em ordem
| Ordem | O que checar | O que uma resposta negativa elimina |
|---|---|---|
| 1 | Sua carteira está na rede em que o novo token foi emitido | Um problema de exibição por rede errada |
| 2 | Você adicionou à mão o endereço do novo contrato | A carteira não acompanhar um contrato novo |
| 3 | balanceOf responde para o seu endereço | Qualquer explicação restante por exibição |
| 4 | A troca carrega um evento de transferência para você | Um crédito que ocorreu e depois foi movido |
| 5 | Qual endereço esse evento nomeia | Um pagamento feito a um endereço de depósito |
| 6 | A razão e os decimals batem com o que chegou | Um crédito correto lido como errado |
| 7 | Uma plataforma executou a migração por você | Uma apuração na rede que nunca se aplicou |
Desça essa lista em vez de percorrê-la de lado. Cada linha remove uma classe de explicação, e as linhas de baixo só fazem sentido depois que as de cima estão resolvidas. As três primeiras não custam nada.
Um aviso acompanha todo o exercício. Uma carteira que parece ter perdido um saldo é exatamente a condição que os impostores procuram, e cada checagem acima é uma leitura pública que você faz de graça. Ninguém precisa da sua frase de recuperação para ler um saldo, e uma oferta de recuperar tokens migrados sumidos em troca dela é uma segunda perda fantasiada de conserto da primeira.
Em resumo
Uma transação de troca em verde atesta que uma chamada executou, e nada mais. O novo saldo está registrado no novo contrato, como evento de transferência no momento do crédito e como leitura de balanceOf depois, e ambos podem ser lidos sem perguntar a ninguém. Até você lê-los, não sabe se isto é um problema de exibição ou de pagamento.
Quando é de exibição a sequência é curta: mude para a rede certa, adicione o endereço do contrato à mão e o saldo já está lá. Quando não é, o evento de transferência nomeia o endereço de fato creditado, e esse campo separa um pagamento enviado à conta errada de um pagamento que nunca aconteceu. Defina qual dos dois você tem diante de si antes de enviar qualquer outra coisa a qualquer lugar. Para continuar aprendendo os fundamentos, acompanhe mais conteúdos da Bitbase Academy.
Leituras relacionadas
Outros artigos da Bitbase sobre este tema:
- Como calcular a autonomia da tesouraria de um token
- Mecânica de oferta de um token
- O que é um token de cripto? Tokens versus moedas explicados
- Muros de compra, muros de venda e profundidade do livro de ofertas
- Estratégia de trading de rompimento
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 (EIP-20, status Final) eips.ethereum.org
[2] Ethereum Improvement Proposals, EIP-747: wallet_watchAsset RPC Method (status Final) eips.ethereum.org
