Três dias depois do reveal, seu token ainda mostra uma imagem provisória. Uma coleção que você tem passa a exibir atributos diferentes dos da semana passada. Nenhuma das duas coisas é sobre o token. As duas são sobre uma única cadeia de texto guardada pelo contrato e sobre o que está na outra ponta dela; congelado e atualizar são as duas palavras para o que pode e o que não pode acontecer com essa cadeia.
O que o token guarda e o que não guarda
Um NFT é um identificador que um contrato inteligente registra em nome de um endereço detentor. O nome, a descrição e a arte não estão nesse registro.
Quem os coloca atrás de uma única função é o padrão de tokens ERC-721. Dado um identificador de token, tokenURI devolve um Uniform Resource Identifier, e a especificação acrescenta que essa URI pode apontar para um arquivo JSON em conformidade com o ERC721 Metadata JSON Schema.
Esse esquema tem três propriedades: name identifica o ativo que o NFT representa, description o descreve, e image é uma URI que aponta para um recurso com tipo MIME de imagem. A arte é, portanto, um segundo salto: o contrato aponta para um documento e o documento aponta para um arquivo.
Além do identificador e do detentor, tudo o que um aplicativo mostra a você é lido desse documento e não da cadeia. A parte que todo mundo olha é justamente a parte que a cadeia não guarda.
Para onde o ponteiro leva decide o que pode mudar
Uma URI de token é uma cadeia de texto, e essa cadeia pode ser várias coisas diferentes. Pode ser um endereço web em um servidor que alguém opera. Pode ser um endereço IPFS construído em torno de um identificador de conteúdo. Pode carregar o documento inteiro dentro de si, de modo que não há nada a buscar.
A distinção importa por causa daquilo em que cada uma pode se transformar. Um endereço web nomeia um lugar, não um conteúdo: quem opera aquele servidor pode devolver outros bytes amanhã no mesmo endereço, e nada muda na cadeia por isso. Um identificador de conteúdo se comporta de outro jeito. A documentação do IPFS afirma que os CIDs se baseiam no hash criptográfico do conteúdo e que qualquer diferença no conteúdo produz um CID diferente. Um CID não pode, portanto, resolver para conteúdo editado, porque conteúdo editado é outro CID e precisa de outro ponteiro.
Um documento embutido vai um passo além, porque não sobra nenhuma busca a interceptar. Ele custa tamanho, porque cada byte dele ocupa armazenamento do contrato.
| Para onde a URI de token aponta | A outra ponta pode servir outro conteúdo depois | O que precisa mudar para a arte mudar |
|---|---|---|
| Um endereço web no servidor de outra pessoa | Sim | Nada na cadeia |
| Um identificador de conteúdo do IPFS | Não | O contrato precisa devolver outra URI |
| O documento codificado na própria URI | Não | O contrato precisa devolver outra URI |
O que metadados congelados realmente significam
Congelado é uma afirmação sobre duas fechaduras, e ela só vale quando as duas estão trancadas. A primeira está na outra ponta: o conteúdo atrás do ponteiro não pode ser trocado por outro. A segunda está no próprio ponteiro: o contrato não pode ser levado a devolver outra URI.
Uma coleção pode colocar cada arquivo no IPFS, publicar os identificadores de conteúdo e ainda assim manter uma função que permita a quem a implantou definir uma nova base URI. O endereçamento por conteúdo tranca a primeira fechadura e deixa a segunda aberta. Uma coleção de 10.000 tokens pode ser servida a partir de uma única base URI, e nesse caso uma transação do dono muda aquilo para que cada identificador dela resolve.
Por isso congelado se lê do mesmo jeito que os privilégios do dono em qualquer outro contrato. A pergunta não é o que o contrato faz hoje, e sim o que quem tem a chave do dono ainda consegue fazê-lo fazer.
Por que o que você vê é uma cópia em cache
Marketplaces e carteiras não chamam tokenURI nem buscam um documento a cada rolagem. Eles leem uma vez, guardam a própria cópia do JSON, baixam a imagem e servem essa cópia a você, porque renderizar uma galeria de outro jeito significaria uma requisição externa por miniatura contra servidores que o site não controla.
Existem, portanto, três cópias da resposta, e elas podem divergir: o que o contrato devolve agora, o que o documento naquela URI diz agora e o que o indexador anotou da última vez que olhou. Uma exibição errada é uma afirmação sobre a terceira cópia, não uma prova de que as duas primeiras estão erradas.
O ERC-4906 existe justamente por causa dessa fresta. Intitulado EIP-721 Metadata Update Extension, ele acrescenta um evento MetadataUpdate para que, nas suas próprias palavras, plataformas de terceiros como os marketplaces de NFT possam atualizar a tempo as imagens e os atributos relacionados do NFT; um evento BatchMetadataUpdate cobre uma faixa de identificadores em uma única emissão. A motivação declarada é que os contratos já emitiam os próprios eventos para isso e que construir uma solução individual para cada coleção era esforço extra para as plataformas que os leem.
O que uma atualização realmente faz
Uma atualização é uma instrução para o indexador, não para a cadeia. Ela manda a plataforma jogar fora o que anotou e refazer toda a leitura: chamar tokenURI, buscar o que voltar, analisar isso e baixar de novo o arquivo nomeado no campo image. Nada é assinado, nenhuma taxa é paga e o contrato não é tocado.
Por isso uma atualização ajuda em uma única situação: a cópia guardada ficou atrás da resposta atual. Se o contrato agora devolve uma URI nova, ou se o documento na URI antiga agora tem outros bytes, a atualização põe a exibição em dia. Se nenhuma das duas coisas for verdade, ela substitui a cópia guardada por uma idêntica.
Uma atualização é a versão manual do que o ERC-4906 automatiza: quando uma coleção emite o evento de atualização, um indexador que o observa refaz a leitura sem que ninguém peça.
Quando uma atualização não resolve
A pergunta útil não é se deve atualizar, e sim com qual falha você está lidando, porque falhas sem relação entre si aparecem do mesmo jeito: a imagem está errada, ou a imagem não está lá.
| O que você vê | O que acontece por baixo | Uma atualização muda isso |
|---|---|---|
| Imagem provisória depois do reveal | O contrato ainda devolve a URI anterior ao reveal | Não, até o contrato devolver a nova |
| Imagem quebrada, o documento ainda abre | A URI da imagem está morta ou inalcançável | Não, o conserto é na hospedagem |
| Nada carrega | O próprio documento de metadados está inalcançável | Não |
| Os atributos divergem do documento | A cópia guardada está desatualizada | Sim |
| Arte certa, página de coleção errada | Você está olhando outro contrato | Não |
As linhas de ponteiro morto são justamente as lidas como falha da plataforma. Se a URI de token for um endereço web, o servidor por trás pode ser desligado, e o ponteiro segue apontando para nada. Se for um identificador de conteúdo, o mesmo desfecho chega por outro caminho: a documentação do IPFS afirma que, embora o IPFS garanta que qualquer conteúdo na rede seja descobrível, ele não garante que qualquer conteúdo esteja disponível de forma persistente, e que os dados podem ser fixados em um ou mais nós IPFS para que não sejam apagados na coleta de lixo. Um CID que nenhum nó guarda é um nome válido e permanente para nada.
O que checar antes de pedir uma atualização
Três leituras separam esses casos, e nenhuma delas precisa que o marketplace esteja funcionando.
Leia o contrato primeiro. Em um explorador de blocos, abra o contrato da coleção e chame tokenURI com o seu identificador de token. A cadeia que volta é a resposta da cadeia de blocos e a única das três cópias que ela atesta.
Depois abra o que ele devolveu. Busque essa URI e leia o JSON. Se name, description e image contiverem o que você espera, o lado da cadeia está certo e o problema está adiante dele. Se a URI não abrir, nenhuma atualização vai produzir um documento que não existe.
Depois siga o campo image, porque um documento pode estar intacto enquanto o arquivo que ele nomeia sumiu, e em uma hospedagem diferente da que serve os metadados. Quando as três leituras estão corretas e o marketplace ainda mostra outra coisa, esse é o caso de atualização, e é o único.
Em resumo
Metadados são um documento para o qual a cadeia aponta, não uma coisa que a cadeia guarda. Congelado significa que as duas fechaduras estão trancadas: a outra ponta não pode servir outro conteúdo e o contrato não pode ser levado a apontar para outro lugar. Uma fechadura sem a outra não é congelamento, e o endereçamento por conteúdo sozinho tranca apenas a primeira.
Uma atualização não encosta em nada disso. Ela relê o ponteiro e o documento e sobrescreve uma cópia em cache, então conserta exatamente uma falha: uma exibição que ficou para trás. Leia tokenURI, abra o que ele devolve, siga o campo image. Essas três leituras separam um indexador que precisa olhar de novo de um ponteiro que já não tem nada na ponta. 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
- A cunhagem deu certo, mas o NFT não aparece na carteira
- O processo de revelação de um NFT: o que muda e quando
- Royalties opcionais de NFT explicados
- Cruzamentos de médias móveis: cruzamento dourado e cruzamento da morte
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-721: Non-Fungible Token Standard eips.ethereum.org
[2] Ethereum Improvement Proposals, ERC-4906: EIP-721 Metadata Update Extension eips.ethereum.org
[3] Documentação do IPFS, Content Identifiers (CIDs) docs.ipfs.tech
[4] Documentação do IPFS, Persistence, permanence, and pinning docs.ipfs.tech
