Acabas de mintear y cada token de la colección muestra el mismo marcador gris. Un día después aparece la imagen y un sitio de rareza te dice qué tienes. Entre medias tu token no se movió y no se le añadió nada. Un revelado es una cadena que cambia en el contrato, más una asignación decidida antes de que nadie pudiera ver el resultado.
Qué cambia un revelado
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 forman parte de ese registro.
El estándar de tokens ERC-721 los coloca detrás de una sola función. Dado un identificador de token, tokenURI devuelve un Uniform Resource Identifier, y la especificación añade que ese URI puede apuntar a un archivo JSON conforme al ERC721 Metadata JSON Schema. Todo lo que dibuja una galería viene del extremo lejano de ese puntero.
Antes de un revelado, esa función devuelve el mismo documento marcador para cada identificador de la colección. Después, cada identificador resuelve a su propio documento. Ese es el evento entero: la cadena que devuelve el contrato cambia, y los documentos del otro extremo empiezan a diferir por identificador cuando antes no lo hacían.
Nada más de tu token cambia. El identificador es el mismo, el propietario es el mismo, el historial de transferencias es el mismo y tú no firmas nada. Un revelado es algo que hace la colección, no algo que le ocurre a tu token.
Por qué una colección vende antes de mostrar
Si las imágenes fueran visibles durante la venta, los compradores leerían la correspondencia entre identificador e imagen y comprarían solo los identificadores que valen la pena. Mintear se convertiría en una carrera por números concretos, y el resto de la colección quedaría sin vender.
Una venta a ciegas elimina esa opción eliminando la información. Cada comprador se lleva la misma incógnita, y la correspondencia se publica solo cuando ya no puede dirigir la venta. El retraso es por tanto deliberado y no una necesidad técnica, y una colección puede pasar días sin revelar sin que nada esté roto.
De qué dos decisiones se compone un revelado
Un revelado son dos cosas separables que en la conversación se funden en una. La primera es la asignación: qué entrada de metadatos pertenece a qué identificador de token. La segunda es el conmutador: a partir de cuándo el contrato empieza a devolver documentos por identificador en lugar del marcador.
El conmutador es una transacción que todo el mundo ve. La asignación es una regla fijada de antemano, y ahí es donde vive de verdad la cuestión de la equidad. Una colección puede accionar el conmutador a la vista de todos y aun así haber elegido la asignación después de ver quién compró cada identificador, así que la mitad visible del proceso no es la mitad que hay que revisar.
El conmutador es una transacción del propietario
En un contrato que sirve el marcador devolviendo un URI fijo, revelar significa que la cuenta con privilegios de propietario llama a un setter que cambia el URI base con el que el contrato compone sus respuestas. Una transacción, y cada identificador de la colección resuelve a un sitio nuevo.
Esa palanca es la misma que decide si los metadatos están congelados. Mientras una cuenta pueda apuntar la colección a otro sitio, podrá volver a apuntarla a otro sitio después del revelado. Revelada y congelada son dos afirmaciones distintas, y la primera no implica la segunda.
La asignación es un solo desplazamiento
Asignar imágenes de identificador en identificador supondría una transacción por identificador. En su lugar basta un número: un índice inicial, sorteado una vez y aplicado a toda la colección.
Toma una colección de 10.000 tokens y un conjunto de metadatos numerado en un orden fijo ya publicado. Supón que el índice inicial sorteado es 3.142: la regla es que el token con identificador uno toma la entrada de metadatos 3.143, y la secuencia da la vuelta al final de la lista, de modo que el identificador 6.859 toma la entrada del principio de la lista.
Un número fija así el mapa entero. Nadie tiene que confiar en que diez mil asignaciones se hicieran honestamente una por una, porque solo hay un sorteo del que razonar y, una vez registrado en cadena, no se puede repetir en silencio.
Comprometerse con las imágenes antes de que nadie las vea
El desplazamiento baraja una lista. No dice nada sobre si la lista misma estaba fijada de antemano, y una colección capaz de editar la lista después del sorteo todavía puede poner las imágenes deseadas donde quiera.
Un hash de procedencia cierra esa mitad. Las imágenes se hashean en su orden publicado, los hashes se unen, el resultado se hashea una vez más y se publica antes de abrir la venta. Tras el revelado cualquiera puede repetir esos pasos sobre los archivos revelados y comparar. Que coincida dice que el conjunto y su orden son los comprometidos; que no coincida dice que algo se movió.
Lee las dos afirmaciones por separado. El hash de procedencia cubre qué había en la lista. El índice inicial cubre por dónde se cortó la lista. Publicar uno y no el otro deja la otra mitad sin demostrar, y conviene comprobarlo antes de mintear y no después.
De dónde sale el desplazamiento
El sorteo tiene que ser impredecible mientras la venta está en marcha y verificable una vez terminada. Esos dos requisitos son los que convierten el origen del número en la parte interesante y no en un detalle.
Derivarlo dentro del contrato a partir de datos del bloque es la vía barata, y su debilidad es que los datos del bloque los produce una parte que ve la transacción y tiene cierto control sobre ella. Un servicio de aleatoriedad verificable toma la otra vía: el valor llega con una prueba de que se generó a partir de una clave comprometida y de la propia solicitud, de modo que el contrato puede verificar la prueba antes de aceptar el número.
Un tercer patrón esquiva la cuestión del momento: no se asigna nada hasta que se vende el último token, así que el sorteo no puede cronometrarse contra una posición que el vendedor todavía mantiene.
Cuando un revelado parece atascado
| Qué ves | Qué ocurre por debajo | Qué lo cambia |
|---|---|---|
| Todos los tokens siguen con un marcador | El contrato sigue devolviendo el URI previo al revelado | Que la colección accione el conmutador |
| Otros ya revelados, el tuyo no | La plataforma sirve una copia guardada más antigua | Una actualización en esa plataforma |
| Apareció la imagen, faltan los rasgos | El documento cargó, los atributos no | Otra lectura cuando el documento esté completo |
| Los rasgos difieren de un sitio de rareza | Dos herramientas puntuaron los mismos rasgos distinto | Nada, porque responden preguntas distintas |
Las dos primeras filas se leen como el mismo problema y no lo son. La primera es una afirmación sobre la cadena, y ninguna recarga la mueve. La segunda es una afirmación sobre la copia guardada de una plataforma, y pedirle a esa plataforma una actualización de metadatos es justo la instrucción que lo resuelve.
Consulta el contrato antes de decidir cuál de los dos tienes delante. Leer tokenURI para tu identificador en un explorador de bloques devuelve la respuesta de la cadena, y si esa respuesta sigue siendo el marcador, el revelado no ha ocurrido para nadie.
Qué no decide un revelado
La rareza no se crea en el revelado. Quedó fijada cuando se construyó el conjunto de metadatos y se sorteó el desplazamiento; el revelado solo la hace legible. Un token no se vuelve escaso porque un sitio empiece a mostrarlo.
El revelado tampoco zanja qué significa raro. Contar cuán inusual es cada rasgo y puntuar un token entero son operaciones distintas, por eso dos herramientas pueden ordenar la misma colección revelada de forma distinta, y la rareza de rasgo es un método entre varios y no la respuesta.
Y no bloquea nada. El revelado apunta la colección a documentos nuevos. Si esos documentos pueden cambiarse después depende de dónde vivan y de quién siga teniendo la clave que fija el puntero.
En resumen
Un revelado es un cambio de puntero más un mapa decidido de antemano. El cambio de puntero es público y fácil de verificar. Los compromisos están del lado del mapa: un hash de procedencia publicado antes de la venta fija qué hay en la lista, y un índice inicial sacado de una fuente que nadie podía dirigir fija por dónde se cortó la lista.
Antes de mintear, busca ambas cosas por escrito y comprueba si la cuenta que accionó el conmutador puede volver a accionarlo. Después de mintear, separa una colección que no ha revelado de una plataforma que no se ha puesto al día, porque solo una de las dos está en tus manos. Para seguir aprendiendo los fundamentos, sigue a 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
- Regalías opcionales de NFT, explicadas
- Clave privada frente a frase semilla: ¿cuál es la diferencia?
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
