Tres días después del reveal, tu token sigue mostrando una imagen provisional. Una colección que tienes muestra de pronto rasgos distintos a los de la semana pasada. Ninguna de las dos cosas trata sobre el token. Ambas tratan sobre una única cadena de texto que guarda el contrato y sobre lo que hay al otro extremo de ella; congelado y actualizar son las dos palabras para lo que puede y no puede pasarle a esa cadena.
Qué guarda el token y qué no
Un NFT es un identificador que un contrato inteligente registra a nombre de una dirección propietaria. El nombre, la descripción y la imagen no están en ese registro.
Los deja detrás de una sola función el estándar de tokens ERC-721. Dado un identificador de token, tokenURI devuelve un Uniform Resource Identifier, y la especificación añade que esa URI puede apuntar a un archivo JSON conforme al ERC721 Metadata JSON Schema.
Ese esquema tiene tres propiedades: name identifica el activo que representa el NFT, description lo describe, e image es una URI que apunta a un recurso con un tipo MIME de imagen. La imagen es, por tanto, un segundo salto: el contrato apunta a un documento y el documento apunta a un archivo.
Más allá del identificador y del propietario, todo lo que te muestra una aplicación se lee de ese documento y no de la cadena. La parte que todo el mundo mira es justo la parte que la cadena no guarda.
Adónde lleva el puntero decide qué puede cambiar
Una URI de token es una cadena de texto, y esa cadena puede ser varias cosas distintas. Puede ser una dirección web en un servidor que alguien opera. Puede ser una dirección IPFS construida alrededor de un identificador de contenido. Puede llevar el documento entero dentro de sí, de modo que no hay nada que descargar.
La distinción importa por aquello en lo que cada una puede convertirse. Una dirección web nombra un lugar, no un contenido: quien opere ese servidor puede devolver mañana otros bytes en la misma dirección, y en la cadena no cambia nada por ello. Un identificador de contenido se comporta de otra forma. La documentación de IPFS indica que los CID se basan en el hash criptográfico del contenido y que cualquier diferencia en el contenido produce un CID distinto. Un CID no puede resolver a contenido editado, porque el contenido editado es otro CID y necesita otro puntero.
Un documento incrustado va un paso más allá, porque ya no queda descarga que interceptar. Cuesta tamaño, porque cada byte suyo ocupa almacenamiento del contrato.
| Adónde apunta la URI de token | Puede el otro extremo servir otro contenido después | Qué tiene que cambiar para que cambie la imagen |
|---|---|---|
| Una dirección web en un servidor ajeno | Sí | Nada en la cadena |
| Un identificador de contenido de IPFS | No | El contrato tiene que devolver otra URI |
| El documento codificado en la propia URI | No | El contrato tiene que devolver otra URI |
Qué significa realmente que los metadatos estén congelados
Congelado es una afirmación sobre dos cerraduras, y solo se sostiene cuando ambas están echadas. La primera está en el otro extremo: el contenido detrás del puntero no se puede sustituir por otro. La segunda está en el puntero mismo: al contrato no se le puede hacer devolver otra URI.
Una colección puede poner cada archivo en IPFS, publicar los identificadores de contenido y aun así conservar una función que permita a quien la desplegó fijar una nueva base URI. El direccionamiento por contenido echa la primera cerradura y deja abierta la segunda. Una colección de 10.000 tokens puede servirse desde una única base URI, y entonces una sola transacción del propietario cambia aquello a lo que resuelve cada identificador de la colección.
Por eso congelado se lee igual que los privilegios del propietario en cualquier otro contrato. La pregunta no es qué hace el contrato hoy, sino qué puede todavía hacerle hacer quien tiene la clave del propietario.
Por qué lo que ves es una copia en caché
Los mercados y las billeteras no llaman a tokenURI ni descargan un documento cada vez que te desplazas. Lo leen una vez, guardan su propia copia del JSON, descargan la imagen y te sirven esa copia, porque renderizar una galería de otro modo supondría una petición externa por cada casilla contra servidores que el sitio no controla.
Hay, por tanto, tres copias de la respuesta, y pueden discrepar: lo que el contrato devuelve ahora, lo que el documento en esa URI dice ahora y lo que el indexador anotó la última vez que miró. Una imagen equivocada es una afirmación sobre la tercera copia, no una prueba de que las dos primeras estén mal.
ERC-4906 existe precisamente por esa rendija. Se titula EIP-721 Metadata Update Extension y añade un evento MetadataUpdate para que, en sus propias palabras, las plataformas de terceros como los mercados de NFT puedan actualizar a tiempo las imágenes y los atributos relacionados del NFT; un evento BatchMetadataUpdate cubre un rango de identificadores en una sola emisión. Su motivación declarada es que los contratos ya emitían sus propios eventos para esto y que construir una solución individual para cada colección suponía un esfuerzo extra para las plataformas que los leen.
Qué hace realmente una actualización
Una actualización es una instrucción para el indexador, no para la cadena. Le dice a la plataforma que tire lo anotado y rehaga toda la lectura: llamar a tokenURI, descargar lo que devuelva, analizarlo y volver a bajar el archivo nombrado en el campo image. Nada se firma, no se paga comisión y el contrato queda intacto.
Por eso una actualización solo ayuda en una situación: cuando la copia guardada se ha quedado detrás de la respuesta actual. Si el contrato devuelve ahora una URI nueva, o el documento en la URI antigua tiene ahora otros bytes, la actualización pone la vista en línea. Si nada de eso ocurre, reemplaza la copia guardada por otra idéntica.
Una actualización es la versión manual de lo que ERC-4906 automatiza: cuando una colección emite el evento de actualización, un indexador que lo vigila rehace la lectura sin que nadie se lo pida.
Cuándo una actualización no sirve
La pregunta útil no es si actualizar, sino ante qué fallo estás, porque fallos sin relación entre sí se presentan igual: la imagen está mal o la imagen no está.
| Lo que ves | Lo que ocurre por debajo | Lo cambia una actualización |
|---|---|---|
| Imagen provisional después del reveal | El contrato sigue devolviendo la URI previa al reveal | No, hasta que el contrato devuelva la nueva |
| Imagen rota, el documento aún carga | La URI de la imagen está muerta o inalcanzable | No, el arreglo está en el alojamiento |
| No carga nada en absoluto | El propio documento de metadatos es inalcanzable | No |
| Los rasgos difieren del documento | La copia guardada está desfasada | Sí |
| Imagen correcta, página de colección incorrecta | Estás mirando otro contrato | No |
Las filas de puntero muerto son justo las que se leen como un fallo de la plataforma. Si la URI de token es una dirección web, el servidor detrás puede apagarse, y el puntero sigue apuntando a nada. Si es un identificador de contenido, el mismo desenlace llega por otro camino: la documentación de IPFS indica que, aunque IPFS garantiza que cualquier contenido de la red sea localizable, no garantiza que ningún contenido esté disponible de forma persistente, y que los datos pueden fijarse en uno o varios nodos IPFS para que no se borren durante la recolección de basura. Un CID que ningún nodo guarda es un nombre válido y permanente para nada.
Qué comprobar antes de pedir una actualización
Tres lecturas separan estos casos, y ninguna necesita que el mercado funcione.
Lee primero el contrato. En un explorador de bloques, abre el contrato de la colección y llama a tokenURI con tu identificador de token. La cadena que vuelve es la respuesta de la cadena de bloques y la única de las tres copias que esta respalda.
Abre después lo que devolvió. Descarga esa URI y lee el JSON. Si name, description e image contienen lo que esperas, el lado de la cadena está bien y el problema está aguas abajo. Si la URI no carga, ninguna actualización hará aparecer un documento que no existe.
Sigue después el campo image, porque un documento puede estar intacto mientras el archivo que nombra ha desaparecido, y en un alojamiento distinto del que sirve los metadatos. Cuando las tres lecturas son correctas y el mercado sigue mostrando otra cosa, ese es el caso de la actualización, y es el único.
En resumen
Los metadatos son un documento al que la cadena apunta, no una cosa que la cadena guarda. Congelado significa que ambas cerraduras están echadas: el otro extremo no puede servir otro contenido y al contrato no se le puede hacer apuntar a otro sitio. Una cerradura sin la otra no es congelado, y el direccionamiento por contenido por sí solo únicamente echa la primera.
Una actualización no toca nada de eso. Relee el puntero y el documento y sobrescribe una copia en caché, así que repara exactamente un fallo: una vista que se ha quedado atrás. Lee tokenURI, abre lo que devuelva y sigue el campo image. Esas tres lecturas separan un indexador que necesita mirar otra vez de un puntero que ya no tiene nada al final. Para seguir aprendiendo los fundamentos, sigue leyendo Bitbase Academy.
Lecturas relacionadas
Otros artículos de Bitbase sobre este tema:
- Propiedad fraccionada de un token no fungible y dónde está el riesgo
- Acuñación con éxito, pero el NFT no aparece en la billetera
- El proceso de revelado de un NFT: qué cambia y cuándo
- Regalías opcionales de NFT, explicadas
- Cruces de medias móviles: cruce dorado y cruce de la muerte
Aviso legal: Este artículo es contenido educativo de Bitbase Academy y se ofrece solo con fines informativos. No constituye asesoramiento de inversión, negociación, fiscal ni financiero. Los criptoactivos son volátiles; evalúa tu propio riesgo. Redactado en septiembre de 2026; consulta la información oficial más reciente.
Fuentes
[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] Documentación de IPFS, Content Identifiers (CIDs) docs.ipfs.tech
[4] Documentación de IPFS, Persistence, permanence, and pinning docs.ipfs.tech
