A cunhagem deu certo, mas o NFT não aparece na carteira

A página de cunhagem disse que foi um sucesso. O explorador mostra um sinal verde ao lado da taxa que você pagou. A galeria da carteira está vazia. Aqui três sistemas respondem a três perguntas diferentes, e só um deles é a cadeia. Antes de concluir que algo deu errado, separe a pergunta sobre se um token existe da pergunta sobre se um aplicativo está disposto a desenhá-lo.

O que uma transação de cunhagem bem-sucedida atesta

Uma transação confirmada diz a você 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 produziu.

Uma cunhagem é uma função de contrato como qualquer outra. Ela pode terminar sem reverter e mesmo assim não ter criado nada para você: um laço em lote que pulou o seu registro, uma chamada interna que o contrato absorveu de propósito, uma função pagável que ficou com a taxa e creditou outro endereço. O recibo não separa esses casos de uma cunhagem comum, porque nunca lhe pediram isso.

Então a pergunta não é se a transação funcionou. É se agora existe um token com o seu endereço escrito no nome dele. Esse fato fica registrado em outro lugar, e fica registrado duas vezes: uma como evento no momento da criação e outra como valor que o contrato devolve quando perguntado.

O evento que diz que um token foi criado

No padrão de tokens ERC-721 a cunhagem não é uma operação à parte. É uma transferência sem remetente. O padrão define um único evento Transfer, emitido quando a propriedade de qualquer NFT muda por qualquer mecanismo, e determina que esse evento é emitido quando tokens são criados e quando são destruídos: no primeiro caso o campo do remetente fica em zero e no segundo fica em zero o campo do destinatário.

Isso dá a você uma coisa exata para procurar. Um evento de transferência na transação de cunhagem, do endereço zero, para o seu endereço, carregando um identificador de token, é a cadeia dizendo que um token foi criado e atribuído a você. A ausência dele informa tanto quanto.

O ERC-1155 segue a mesma convenção nos próprios eventos: ao cunhar tokens, o argumento do remetente deve ser definido como o endereço zero. O formato da prova, portanto, não muda entre os dois padrões, ainda que o suporte das carteiras em torno deles possa mudar.

A leitura que decide de quem ele é

O evento é o registro de um momento. A propriedade agora é uma leitura à parte, e o ERC-721 responde a ela diretamente. Chame ownerOf com um identificador de token e o contrato devolve o endereço que ele registra como dono. O padrão acrescenta que tokens atribuídos ao endereço zero são considerados inválidos e que consultas sobre eles lançam erro, de modo que uma chamada que falha em vez de devolver um endereço é ela própria uma resposta: nenhum token com esse identificador está atribuído a ninguém no momento.

Ao lado dela, balanceOf conta os tokens que um endereço tem naquele único contrato. Em uma coleção de 10.000 identificadores, ownerOf responde exatamente pelo identificador que você nomeia, e balanceOf responde quantos tokens daquele contrato estão no seu endereço sem que você precise adivinhar identificadores. Nenhuma das duas leituras depende de haver um marketplace, uma galeria ou uma imagem disponível.

A última linha é a que resolve toda essa situação. Não existe um campo na cadeia para dizer se um aplicativo exibe o seu token, e é por isso que uma galeria vazia nunca é, sozinha, prova a respeito de propriedade.

Por que o token pode ser seu e a carteira não mostrar nada

A galeria de uma carteira não é uma leitura ao vivo da cadeia. Nada em nenhum dos dois padrões permite pedir a uma cadeia todos os tokens que um endereço tem em todos os contratos, então carteiras e marketplaces rodam indexadores: eles observam os eventos de transferência, anotam o que veem e servem esse registro a você. O que você percorre é a tabela deles, não o contrato.

Quatro coisas nessa tabela podem deixá-la vazia enquanto o contrato diz outra coisa. O indexador pode ainda não ter processado o seu bloco, e nesse caso a galeria se preenche sozinha. A coleção pode estar filtrada como spam ou como não verificada, o que é uma regra de exibição que a carteira aplica e que pode ser desligada. A carteira pode indexar um padrão e não o outro, de modo que um token cunhado sob ERC-1155 não mostra nada em uma visão construída só para ERC-721. E uma carteira que exige adicionar a coleção à mão não mostra nada dela até que isso seja feito.

Nenhuma dessas coisas se conserta reenviando qualquer coisa na cadeia. Mandar uma segunda transação porque a galeria parece vazia corre o risco de cunhar de novo e pagar de novo por um token que você já tem.

Quando o token foi para outro lugar

A outra família de causas é que a cunhagem funcionou exatamente como está escrita e o token não está no endereço que você está olhando.

Quem decide o destinatário de uma cunhagem é o contrato, não a interface. Uma função que cunha para quem chama credita o endereço que assinou a transação, ou seja, a conta que estava conectada naquele momento, e não a que está selecionada agora na carteira. Uma carteira derivada de uma frase semente tem mais de um endereço, e o que você está vendo pode não ser o que cunhou.

Contas de contrato inteligente acrescentam uma segunda versão do mesmo descompasso. O ERC-721 exige que uma transferência segura verifique se o destinatário é um contrato inteligente e, se for, chame o hook de recebimento nele e lance erro quando o valor de retorno esperado não vier. Uma conta de contrato que implementa esse hook recebe o token normalmente, e o token passa a morar no endereço do contrato. Qualquer visão apontada para a chave que assina em vez de para a conta não mostrará nada enquanto o token estiver bem guardado onde foi enviado.

Depois vem a rede. O mesmo endereço existe em toda cadeia que usa o mesmo formato de endereço, então uma carteira ajustada para uma rede desenha uma galeria vazia para um token cunhado em outra. O token não sumiu. A visão é que está filtrada para uma cadeia em que o token nunca esteve.

Quando o token está lá e só falta a imagem

Um sintoma distinto é um quadro presente, mas em branco, cinza, ou rotulado com um nome provisório. Aqui a propriedade não está em questão de jeito nenhum: a carteira desenhou o token, o que significa que ela indexou o evento de transferência e o identificador.

O que está por trás do quadro é o documento de metadados, não o token, e o instrumento para isso é uma atualização de metadados, que manda a plataforma ler de novo o ponteiro e o documento. Uma atualização não move nada na cadeia e não cria propriedade, então é a ferramenta certa para uma imagem desatualizada e a errada para um token que nunca aparece. Separar esses dois casos antes de agir poupa as horas que se gastam atualizando um token que a carteira nunca iria desenhar.

O que conferir, e em que ordem

Abra a transação em um explorador de blocos e leia os logs dela em vez da manchete. Um evento de transferência do endereço zero, com um identificador de token, diz a você que um token foi criado. O endereço no campo do destinatário diz de quem ele é. Se essa seção estiver vazia, todo o resto da busca é sobre o contrato, não sobre a sua carteira.

Depois chame ownerOf no contrato com aquele identificador de token. Os exploradores expõem leituras de contrato sem assinatura e sem taxa, então isso não custa nada e devolve a resposta da própria cadeia em vez da cópia de um indexador. Se o endereço que volta é um dos seus, o token é seu e tudo o que resta é uma questão de exibição.

Depois confira o que você está olhando: o endereço selecionado na carteira, a rede em que ela está ajustada e se a coleção está oculta. Esses três ajustes explicam a distância entre um contrato que aponta você como dono e uma galeria que não mostra nada.

Em resumo

Uma cunhagem que confirma prova que uma chamada não reverteu. Ela não prova que um token existe, e não nomeia um dono. Esses dois fatos vivem no evento de transferência da transação e no que ownerOf devolve depois, e os dois podem ser lidos sem a cooperação de nenhum aplicativo.

Uma galeria vazia é uma afirmação sobre um indexador. Leia o evento, leia ownerOf, e então confira o endereço, a rede e o filtro de coleções. Se o contrato aponta você como dono, nada precisa ser enviado, assinado ou pago de novo. Para continuar aprendendo os fundamentos, acompanhe mais conteúdos da Bitbase Academy.

Leituras relacionadas

Outros artigos da Bitbase sobre este tema:

- Propriedade fracionada de um token não fungível e onde está o risco

- O processo de revelação de um NFT: o que muda e quando

- Royalties opcionais de NFT explicados

- The DATA Foundation, antiga Story Protocol: a migração do token IP para DATA

- Carteiras omnibus e segregadas e o risco de re-hipoteca

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, EIP-721: Non-Fungible Token Standard, seção de especificação eips.ethereum.org

[2] Ethereum Improvement Proposals, EIP-1155: Multi Token Standard, seção de especificação eips.ethereum.org