Buy Crypto
Markets
Spot
FuturesBTC
Earn
Event Center
More
0-Fee Fest
Esquema de metadatos de token: ¿Qué es un esquema de metadatos de token?Un esquema de metadatos de token es un formato estructurado que define cómo debe escribirse, almacenarse y leerse la información sobre un token cripto medianteEsquema de metadatos de token: ¿Qué es un esquema de metadatos de token?Un esquema de metadatos de token es un formato estructurado que define cómo debe escribirse, almacenarse y leerse la información sobre un token cripto mediante

Esquema de metadatos de token

2026/10/13 17:06
#Advanced
TokenFi
TOKEN$0.001845-1.07%
Humanity
H$0.05609-1.19%
PX
PX$0.0109-2.67%
Lagrange
LA$0.05605+1.68%
ELYSIA
EL$0.001551+0.25%

¿Qué es un esquema de metadatos de token?

Un esquema de metadatos de token es un formato estructurado que define cómo debe escribirse, almacenarse y leerse la información sobre un token cripto mediante carteras, dApps, exploradores, marketplaces, juegos y herramientas de indexación.

En la mayoría de las conversaciones sobre cripto, el esquema de metadatos de token se refiere a la estructura JSON utilizada para describir NFT y otros activos tokenizados.

El esquema indica a las aplicaciones qué campos deben esperar, como

name
,
description
,
image
,
attributes
y enlaces multimedia.

Un contrato de token puede almacenar la titularidad on-chain, mientras que sus metadatos se almacenan mediante una URI que apunta a un archivo JSON.

El estándar oficial ERC-721 indica que una URI de token puede apuntar a un archivo JSON conforme al ERC-721 Metadata JSON Schema.

El estándar oficial ERC-1155 define un ERC-1155 Metadata URI JSON Schema para contratos multítoken.

Un esquema de metadatos es importante porque ayuda a distintas aplicaciones a mostrar el mismo token de forma coherente.

Sin un esquema, cada proyecto podría denominar los campos de forma distinta, y las carteras tendrían dificultades para saber qué valor corresponde a la imagen, la descripción o los rasgos.

Para un principiante, la forma más sencilla de entender un esquema de metadatos de token es considerarlo un formato de etiqueta para un activo cripto.

La blockchain demuestra que el token existe y quién lo posee, mientras que el esquema de metadatos explica qué representa el token.

Por qué es importante el esquema de metadatos de token en cripto

El esquema de metadatos de token es importante porque los usuarios no interactúan únicamente con ID de token sin procesar.

Interactúan con imágenes, nombres, descripciones, rasgos, niveles, insignias, información de rareza, contenido desbloqueable y otros detalles legibles para las personas.

Una cartera solo puede mostrar un token correctamente cuando sabe cómo leer sus metadatos.

Un juego solo puede mostrar correctamente un objeto si comprende los atributos y campos multimedia del objeto.

Un marketplace solo puede filtrar colecciones correctamente cuando los rasgos están estructurados de manera predecible.

Un protocolo de préstamos que acepta NFT como garantía puede necesitar información precisa sobre la colección, los rasgos y los medios para respaldar los procesos de valoración.

Una plataforma de activos del mundo real puede necesitar campos de metadatos que hagan referencia a documentos, emisores, tasaciones, condiciones legales o estado de verificación.

Una aplicación con acceso controlado por tokens puede necesitar metadatos para verificar si un token concede acceso a un determinado nivel de membresía.

Cuando los metadatos están claramente estructurados, las aplicaciones pueden leerlos automáticamente.

Cuando los metadatos son desordenados o incoherentes, los usuarios pueden ver imágenes rotas, rasgos ausentes, nombres incorrectos o detalles de activos desactualizados.

Por ello, el diseño del esquema de metadatos forma parte de la experiencia de usuario en cripto, no es solo un detalle para desarrolladores.

Esquema de metadatos de token y Token URI

Una Token URI es el enlace o identificador que apunta a los metadatos de un token.

Un esquema de metadatos de token es la estructura de los datos que se encuentran en ese enlace o en esa respuesta codificada.

Por ejemplo, un contrato ERC-721 puede devolver

ipfs://exampleCID/1.json
desde
tokenURI(1)
.

El archivo JSON de esa URI debe seguir un esquema de metadatos para que las carteras puedan entenderlo.

La Token URI es la dirección de los metadatos.

El esquema de metadatos de token es el formato de los metadatos.

Esta diferencia importa porque no basta con que una URI funcione si el JSON que contiene no es válido o resulta confuso.

Un token puede tener un archivo de metadatos accesible y, aun así, mostrarse incorrectamente si faltan campos o se denominan de forma no estándar.

Un token también puede tener un esquema correcto, pero no cargarse si la URI apunta a un almacenamiento no disponible.

Un buen diseño de NFT requiere tanto una Token URI fiable como un esquema de metadatos de token limpio.

Esquema de metadatos de token en ERC-721

ERC-721 es el estándar clásico para NFT únicos en redes de estilo Ethereum.

La extensión de metadatos ERC-721 incluye

name()
,
symbol()
y
tokenURI(uint256 tokenId)
.

El estándar ERC-721 describe los metadatos mediante un esquema JSON sencillo que puede incluir campos como

name
,
description
e
image
.

Esta estructura sencilla ayudó a que los NFT fueran más fáciles de mostrar en carteras y aplicaciones.

Un token ERC-721 puede representar arte digital, objetos de juego, pases de membresía, certificados, terrenos virtuales, insignias de identidad o registros de activos del mundo real.

Cada ID de token puede tener su propio archivo de metadatos.

Esto significa que el ID de token 1 puede tener una imagen, un nombre y atributos diferentes de los del ID de token 2.

El esquema ayuda a los clientes a comprender qué campos describen cada token único.

Los desarrolladores suelen ampliar el patrón básico de metadatos ERC-721 con campos adicionales para rasgos, medios, animación, rareza, licencias o datos específicos del proyecto.

Estas extensiones pueden ser útiles, pero los campos principales deben seguir siendo claros y compatibles con las herramientas Web3 habituales.

Esquema de metadatos de token en ERC-1155

ERC-1155 es un estándar multítoken que puede gestionar tokens fungibles, semifungibles y no fungibles dentro de un mismo contrato.

El esquema de metadatos ERC-1155 es especialmente importante porque un contrato puede contener muchos ID de token con significados distintos.

Un único contrato ERC-1155 puede representar monedas de juego, armas, armaduras, entradas, insignias, ediciones limitadas y objetos de colección únicos.

El estándar ERC-1155 permite que una URI incluya el marcador de posición

{id}
.

El software cliente sustituye

{id}
por el ID de token real antes de obtener los metadatos.

La documentación oficial de OpenZeppelin sobre ERC-1155 Metadata URI explica que la extensión de URI de metadatos apunta cada token a un archivo JSON que sigue el ERC-1155 Metadata URI JSON Schema.

Los metadatos ERC-1155 pueden incluir campos como

name
,
description
,
image
,
properties
y otros datos específicos del token.

El esquema permite que carteras y dApps muestren muchos tipos de activos desde un contrato sin necesitar lógica personalizada para cada ID de token.

Los metadatos ERC-1155 deben gestionarse con cuidado, ya que una sustitución incorrecta de ID puede provocar visualizaciones rotas o incorrectas.

Un diseño sólido de metadatos ERC-1155 hace que cada ID de token sea fácil de interpretar y recuperar de forma fiable.

Campos habituales en un esquema de metadatos de token

El campo más común es

name
, que proporciona al token un título legible para las personas.

El siguiente campo habitual es

description
, que explica qué representa el token.

El campo

image
suele apuntar a la imagen principal que se muestra en carteras y marketplaces.

El campo

animation_url
puede apuntar a medios más enriquecidos, como vídeo, audio, objetos 3D o contenido interactivo, cuando el cliente los admite.

El campo

external_url
puede apuntar a una página oficial con más información sobre el token o la colección.

El campo

attributes
suele contener una matriz de objetos de rasgos utilizados para rareza, filtrado, estadísticas de juego y organización de colecciones.

El campo

background_color
se utiliza a veces para sugerir un color de fondo de visualización para el activo.

El campo

properties
se utiliza habitualmente para metadatos de estilo ERC-1155 o información estructurada específica del proyecto.

Algunos proyectos añaden campos como

compiler
,
license
,
creator
,
version
o
content_hash
.

Los campos personalizados pueden ser útiles, pero deben documentarse para que las aplicaciones puedan interpretarlos correctamente.

Ejemplo de un esquema básico de metadatos NFT

Un archivo sencillo de metadatos NFT suele ser un objeto JSON con unos pocos campos claros.

{

"name": "Example NFT #1",

"description": "A sample NFT metadata object used to explain token metadata schema.",

"image": "ipfs://bafyExampleCID/image.png",

"attributes": [

{

"trait_type": "Background",

"value": "Blue"

},

{

"trait_type": "Level",

"value": 5

}

]

}

Este ejemplo muestra un nombre legible, una descripción, una referencia de imagen y dos atributos.

El esquema es lo suficientemente sencillo para que las carteras y las dApps lo analicen.

La imagen utiliza una URI de estilo IPFS, lo que significa que los medios se referencian mediante almacenamiento direccionado por contenido.

Los atributos están estructurados como una matriz, lo que facilita la creación de herramientas de filtrado y rareza.

Un proyecto puede añadir más campos, pero debe evitar una complejidad innecesaria que rompa la compatibilidad.

Los mejores metadatos son legibles por máquinas y fáciles de entender para las personas.

El campo Name

El campo

name
proporciona al token su título de visualización.

Para una colección NFT, un patrón habitual consiste en utilizar el nombre de la colección y el número de token.

Un ejemplo es

Example Collection #123
.

Un objeto de juego podría usar un nombre como

Silver Sword
o
Dragon Armor
.

Un token de membresía podría usar un nombre como

Gold Access Pass
.

El nombre debe ser estable, claro y no engañoso.

Una colección falsa puede copiar el nombre de un proyecto real, por lo que los usuarios nunca deben basarse únicamente en el campo de nombre.

La dirección oficial del contrato es más importante que el nombre mostrado.

Los desarrolladores deben evitar cambiar nombres inesperadamente, salvo que el token esté diseñado para ser dinámico.

Un buen campo de nombre mejora el reconocimiento sin pretender demostrar autenticidad.

El campo Description

El campo

description
explica qué representa el token.

Una descripción clara ayuda a los usuarios a comprender el propósito, la historia, la utilidad o la función de membresía del activo.

En los NFT de arte, la descripción puede explicar el concepto o el tema de la colección.

En los objetos de juego, puede explicar cómo se utiliza el objeto.

En los tokens de activos del mundo real, puede resumir la categoría de activo y dirigir a los usuarios a documentos legales en otra ubicación.

La descripción no debe incluir afirmaciones engañosas sobre valor, rentabilidades garantizadas o estatus oficial.

Las carteras y dApps pueden mostrar la descripción directamente a los usuarios, por lo que los enlaces inseguros o mensajes de estafa pueden generar riesgo de phishing.

Los desarrolladores deben mantener las descripciones útiles y honestas.

Los usuarios deben recordar que la descripción la proporciona el creador del token o el controlador de los metadatos.

Una descripción no es una verificación independiente de la calidad o legitimidad del token.

El campo Image

El campo

image
apunta al archivo multimedia principal mostrado para el token.

Puede apuntar a un PNG, JPG, GIF, SVG u otro formato de imagen compatible según la aplicación.

La imagen puede almacenarse en IPFS, Arweave, servidores HTTPS o codificarse directamente dentro de los metadatos.

El campo de imagen es importante porque muchos usuarios identifican los NFT visualmente.

Un enlace de imagen roto puede hacer que un token parezca incompleto aunque la titularidad sea válida on-chain.

Una imagen engañosa puede hacer que un token falso parezca legítimo.

Una URL de imagen centralizada puede desaparecer si falla el servidor o el dominio.

Una URI de imagen direccionada por contenido puede mejorar la integridad, pero el contenido debe seguir estando disponible mediante almacenamiento o pinning.

Los desarrolladores deben utilizar almacenamiento de imágenes duradero para activos a largo plazo.

Los usuarios deben comprobar la calidad del almacenamiento de imágenes antes de confiar en NFT de alto valor.

El campo Attributes

El campo

attributes
se utiliza habitualmente para describir rasgos, rareza, propiedades de juego, niveles, estado u otras características estructuradas.

Cada atributo suele ser un objeto con

trait_type
y
value
.

Por ejemplo,

trait_type
puede ser
Hat
y
value
puede ser
Red Cap
.

Para un objeto de juego,

trait_type
puede ser
Attack
y
value
puede ser
80
.

La estructura de los atributos importa porque los marketplaces y las herramientas analíticas la utilizan para el filtrado y la clasificación de rareza.

Los atributos incoherentes pueden hacer que las herramientas de rareza sean imprecisas.

Los nombres de rasgos mal escritos pueden dividir una categoría que debería ser única en varias categorías.

Los atributos numéricos deben formatearse de manera coherente para que las herramientas puedan compararlos correctamente.

Los NFT dinámicos deben dejar claro si sus atributos pueden cambiar con el tiempo.

Unos buenos atributos ayudan a los usuarios a comprender la identidad y utilidad del token.

El campo Properties

El campo

properties
se utiliza habitualmente para contener metadatos estructurados más allá de los datos básicos de nombre, descripción e imagen.

Los ejemplos de metadatos ERC-1155 suelen usar

properties
para información adicional del token.

Un objeto de juego podría incluir propiedades como rareza, clase, durabilidad o materiales de fabricación.

Un token de entrada podría incluir propiedades como fecha del evento, nivel de asiento, recinto y tipo de acceso.

Un token de activo del mundo real podría incluir propiedades como categoría de activo, referencia del emisor, jurisdicción, hash de documento o estado de verificación.

Las propiedades pueden ser potentes porque permiten modelos de datos más enriquecidos.

También pueden volverse desordenadas si cada proyecto utiliza nombres y formatos distintos sin documentación.

Los desarrolladores deben mantener nombres de propiedades estables y predecibles.

Las aplicaciones deben tratar las propiedades como datos no fiables hasta que la lógica del contrato o fuentes de confianza las verifiquen.

Un campo de propiedades puede describir un activo, pero no demuestra automáticamente que la afirmación sea cierta.

Esquema de metadatos de token e IPFS

IPFS se utiliza habitualmente para almacenar metadatos de tokens y archivos multimedia.

La documentación oficial sobre direccionamiento por contenido de IPFS explica que IPFS utiliza identificadores de contenido, o CID, para referirse a datos según el propio contenido.

Esto es útil para los metadatos porque un CID puede mostrar si el contenido referenciado ha cambiado.

Si cambian los metadatos JSON, también debería cambiar el CID.

Esto proporciona a los usuarios una integridad mayor que una URL normal de servidor cuyo contenido puede cambiar en la misma dirección.

Sin embargo, IPFS no garantiza automáticamente que la disponibilidad dure para siempre.

Los archivos de metadatos e imágenes deben estar fijados mediante pinning o ser servidos por nodos para que los clientes puedan recuperarlos.

Un esquema de metadatos almacenado en IPFS puede seguir fallando si nadie mantiene el contenido disponible.

Los desarrolladores deben planificar el pinning y el almacenamiento a largo plazo antes de acuñar tokens.

Los usuarios deben entender que el direccionamiento por contenido mejora la integridad, pero la disponibilidad sigue requiriendo respaldo de almacenamiento.

Esquema de metadatos de token y almacenamiento HTTP

Algunos proyectos almacenan metadatos en servidores HTTPS estándar.

Esto puede facilitar la actualización, generación y entrega rápida de metadatos.

Es habitual en NFT dinámicos, activos de juego, mecanismos de reveal y activos que dependen de sistemas backend activos.

La desventaja es que los metadatos HTTP dependen del tiempo de actividad del servidor, del control del dominio, de la seguridad del alojamiento y de las operaciones del proyecto.

Si el servidor deja de funcionar, los metadatos del token pueden desaparecer de las interfaces de usuario.

Si el dominio caduca, el endpoint de metadatos puede volverse inseguro o no estar disponible.

Si el operador del servidor cambia el JSON, los usuarios pueden ver contenido diferente sin un cambio on-chain.

Los metadatos HTTP no son automáticamente malos, pero deben divulgarse con claridad.

Los desarrolladores deben explicar si los metadatos son mutables y durante cuánto tiempo se mantendrá el almacenamiento.

Los usuarios deben tener más cuidado con activos de alto valor que dependen completamente de servidores de metadatos centralizados.

Esquema de metadatos de token y metadatos on-chain

Los metadatos on-chain implican que los metadatos del token se almacenan o generan directamente mediante el contrato inteligente.

Esto puede reducir la dependencia de sistemas de almacenamiento externos.

Un contrato puede devolver una URI

data:application/json
que contiene metadatos codificados.

Los metadatos pueden incluir una imagen SVG on-chain o lógica de arte generativo.

Los metadatos on-chain pueden mejorar la durabilidad porque los datos están vinculados al estado de la blockchain.

También pueden ser más caros, ya que almacenar y generar datos on-chain consume recursos.

Los metadatos on-chain pueden ser más difíciles de cambiar, lo cual es útil para la permanencia, pero menos útil para juegos o credenciales dinámicas.

Los desarrolladores deben elegir metadatos on-chain cuando la permanencia y la minimización de confianza sean más importantes que la flexibilidad.

Los usuarios deben seguir inspeccionando la lógica del contrato, ya que los metadatos on-chain también pueden ser dinámicos si el contrato lo permite.

Los metadatos on-chain son un modelo de almacenamiento, no una garantía automática de calidad.

Esquema de metadatos de token y NFT dinámicos

Los NFT dinámicos son tokens cuyos metadatos pueden cambiar según eventos, tiempo, jugabilidad, datos de oráculos, decisiones de gobernanza o acciones de usuarios.

Los metadatos dinámicos pueden hacer que los NFT sean más útiles e interactivos.

Un personaje de juego puede subir de nivel.

Un pase de membresía puede cambiar de activo a caducado.

Una credencial puede actualizarse después de que un usuario complete un nuevo logro.

Un token de activo del mundo real puede actualizar su estado de verificación o referencias documentales.

El esquema de metadatos debe dejar claros los campos dinámicos.

Los usuarios deben saber qué campos pueden cambiar y quién controla esos cambios.

Un NFT dinámico no debe ocultar un control administrativo arbitrario tras un lenguaje vago sobre metadatos.

Unos buenos metadatos dinámicos son predecibles, están documentados y vinculados a un comportamiento significativo del token.

Esquema de metadatos de token y actualizaciones de metadatos

Las actualizaciones de metadatos son habituales durante los reveals, la progresión en juegos, la verificación de activos y la corrección de errores.

La extensión oficial de actualización de metadatos ERC-4906 define eventos que notifican a los clientes cuando han cambiado los metadatos de NFT.

Esto importa porque las carteras y los indexadores suelen almacenar metadatos en caché para mejorar la velocidad.

Si cambian los metadatos pero no se emite una señal de actualización, los usuarios pueden seguir viendo información antigua.

Un esquema de metadatos debe acompañarse de un comportamiento de actualización claro.

En un reveal, el proyecto debe explicar cuándo los metadatos provisionales pasarán a ser metadatos finales.

Para activos dinámicos, el proyecto debe explicar qué eventos activan cambios de metadatos.

En actualizaciones controladas por administradores, el proyecto debe divulgar quién puede cambiar los metadatos y en qué condiciones.

Las actualizaciones transparentes de metadatos generan confianza.

Las actualizaciones ocultas generan incertidumbre y pueden perjudicar el valor del token.

Esquema de metadatos de token y metadatos a nivel de contrato

Los metadatos a nivel de token describen un ID de token específico.

Los metadatos a nivel de contrato describen todo el contrato o la colección.

El estándar oficial de metadatos a nivel de contrato ERC-7572 estandariza

contractURI()
para información enriquecida a nivel de contrato, como nombre, descripción e imagen.

Esto es útil porque una colección puede necesitar un logotipo, banner, descripción, información de comisiones, enlaces sociales o una imagen a nivel de proyecto.

Un NFT concreto de una colección puede tener su propio esquema de metadatos de token, mientras que la colección también tiene un esquema de metadatos a nivel de contrato.

Ambas capas son importantes para la experiencia de usuario.

Si los metadatos del token son correctos pero los de la colección son erróneos, los usuarios pueden seguir viendo información confusa.

Si los metadatos de la colección son correctos pero los del token están dañados, puede que los tokens individuales no se muestren correctamente.

Los desarrolladores deben admitir metadatos tanto a nivel de token como a nivel de contrato cuando sea pertinente.

Los usuarios deben entender que son capas de metadatos relacionadas, pero distintas.

Esquema de metadatos de token y ERC-1046

ERC-1046 amplía las ideas de Token URI más allá de los casos de uso básicos de NFT.

La propuesta oficial de interoperabilidad tokenURI ERC-1046 añade compatibilidad con Token URI para ERC-20 y amplía la interoperabilidad de metadatos entre tipos de token.

Esto es importante porque los tokens fungibles también pueden necesitar metadatos.

Un token fungible puede necesitar un logotipo, descripción, datos del emisor, enlaces oficiales, notas de cumplimiento normativo o referencias a documentación.

Los metadatos estandarizados ayudan a las carteras y aplicaciones a presentar los tokens fungibles con mayor claridad.

Sin embargo, los usuarios no deben tratar los campos de metadatos como prueba de legitimidad.

Un token de estafa puede proporcionar un logotipo y una descripción atractivos.

La dirección del contrato, el emisor, la liquidez, la seguridad, la tokenomics y las fuentes oficiales siguen siendo importantes.

ERC-1046 demuestra que los esquemas de metadatos no tratan solo de imágenes de colección.

Forman parte de un esfuerzo más amplio para hacer interoperable la información sobre tokens.

Esquema de metadatos de token y ERC-5625

ERC-5625 es una extensión de metadatos propuesta relacionada con información de almacenamiento descentralizado para NFT.

La extensión ERC-5625 NFT Metadata JSON Schema dStorage añade una propiedad de almacenamiento descentralizado a los metadatos NFT para que la información de almacenamiento de activos pueda describirse con mayor claridad.

Esto importa porque los metadatos suelen apuntar a archivos almacenados fuera de la blockchain.

Un token puede parecer duradero, pero sus medios pueden depender de acuerdos de almacenamiento poco claros.

Añadir metadatos relacionados con el almacenamiento puede ayudar a usuarios y aplicaciones a entender dónde se almacenan los datos del activo.

También puede ayudar a identificar si el contenido se almacena en IPFS, Arweave u otro sistema de almacenamiento descentralizado.

Los metadatos de almacenamiento no garantizan por sí mismos la permanencia.

Proporcionan a las aplicaciones una forma más clara de describir e inspeccionar las hipótesis de almacenamiento.

Para NFT de alto valor, los detalles de almacenamiento descentralizado pueden ser una parte importante de la diligencia debida.

Un esquema de metadatos se fortalece cuando explica tanto qué es el activo como cómo se preservan sus datos.

Validación del esquema

La validación del esquema consiste en comprobar si los metadatos siguen la estructura esperada.

Un validador puede comprobar si el JSON es válido.

Puede comprobar si están presentes los campos obligatorios.

Puede comprobar si el campo de imagen es una URI válida.

Puede comprobar si los atributos tienen formato de matriz.

Puede comprobar si los valores numéricos se almacenan de forma coherente.

Puede comprobar si los campos multimedia apuntan a tipos de archivo compatibles.

La validación del esquema ayuda a evitar visualizaciones rotas en carteras y errores en marketplaces.

También ayuda a los desarrolladores a detectar errores antes de la acuñación o el reveal.

Un proyecto debe validar los metadatos antes de publicarlos permanentemente en almacenamiento descentralizado.

Esquema de metadatos y rareza

Las herramientas de rareza suelen depender del campo

attributes
de los metadatos NFT.

Si los atributos son incoherentes, los cálculos de rareza pueden volverse imprecisos.

Por ejemplo,

Blue
,
blue
y
BLUE
pueden tratarse como valores distintos por algunas herramientas.

Si un token utiliza

Background
y otro utiliza
background
, las herramientas de rareza pueden dividir la categoría del rasgo.

Si falta un rasgo en algunos tokens, los cálculos de rareza pueden cambiar inesperadamente.

Los proyectos deben usar nombres y valores de rasgos coherentes en toda la colección.

También deben congelar los metadatos finales cuando la colección esté destinada a ser inmutable.

Los usuarios deben tener cuidado durante los periodos de reveal, ya que los datos de rareza quizá todavía no sean estables.

La calidad del esquema de metadatos puede afectar directamente a cómo los coleccionistas evalúan un NFT.

Para colecciones con precios basados en rasgos, unos metadatos limpios son especialmente importantes.

Esquema de metadatos y activos de juego

Los activos de juego suelen necesitar esquemas de metadatos más completos que los NFT de arte sencillos.

Un objeto de juego puede necesitar campos para nivel, durabilidad, poder de ataque, defensa, rareza, clase, elemento, enfriamiento, estado de mejora o ranura de equipamiento.

Un NFT de personaje puede necesitar campos para experiencia, habilidades, inventario, facción, salud y estado visual.

Algunos de estos campos pueden cambiar durante la jugabilidad.

Los desarrolladores deben decidir qué valores pertenecen on-chain y cuáles pertenecen a los metadatos.

La lógica importante de juego no debe depender únicamente de metadatos off-chain no verificados.

Un contrato o servidor de juego debe verificar los valores clave antes de permitir acciones de alto valor.

Los metadatos pueden mejorar la visualización, pero las reglas de juego deben estar protegidas por lógica de confianza.

Los usuarios deben entender si el valor de un objeto depende de que el juego siga funcionando.

Un esquema de metadatos puede describir un activo de juego, pero el ecosistema del juego le aporta utilidad.

Esquema de metadatos y activos del mundo real

Los tokens de activos del mundo real pueden utilizar esquemas de metadatos para describir activos off-chain.

Los ejemplos pueden incluir registros de propiedades, materias primas, facturas, bonos, participaciones de fondos, objetos de colección, créditos de carbono o credenciales vinculadas a la identidad.

El esquema de metadatos puede incluir campos para emisor, categoría de activo, URI de documento, fecha de valoración, jurisdicción, custodio, estado de verificación y hash de documento.

Estos campos pueden ayudar a los usuarios a comprender el token, pero no crean automáticamente titularidad legal.

Los derechos legales dependen de los documentos del emisor, contratos, acuerdos de custodia, jurisdicción y normas de reembolso.

Un esquema de metadatos de activos del mundo real debe separar la información de marketing de las referencias legalmente importantes.

Debe evitar afirmaciones vagas que no puedan verificarse.

Debe preservar la integridad documental mediante hashes o almacenamiento duradero cuando sea posible.

Los usuarios deben leer los documentos legales oficiales antes de basarse en metadatos de activos del mundo real.

Los metadatos pueden respaldar la divulgación de información, pero no pueden sustituir la diligencia debida legal.

Esquema de metadatos y riesgos de seguridad

Los metadatos de token pueden crear riesgos de seguridad porque las carteras y dApps obtienen y muestran datos de fuentes externas.

Un archivo de metadatos malicioso puede incluir enlaces de phishing, mensajes falsos de recompensas, imágenes engañosas o URL externas peligrosas.

Un NFT de spam puede aparecer en una cartera y utilizar metadatos para indicar al usuario que visite una página falsa de reclamación.

Una colección falsa puede copiar nombres, imágenes y atributos de una colección real.

Un servidor de metadatos comprometido puede cambiar posteriormente metadatos que parecen seguros por contenido malicioso.

Las carteras y dApps deben tratar los metadatos como entradas no fiables.

No deben ejecutar scripts procedentes de metadatos.

Deben sanear enlaces externos y contenido multimedia cuando sea posible.

Los usuarios nunca deben introducir frases de recuperación, claves privadas o copias de seguridad de carteras porque los metadatos se lo indiquen.

Un esquema de metadatos de apariencia limpia no demuestra que el token sea seguro.

Esquema de metadatos y mutabilidad

La mutabilidad significa que los metadatos pueden cambiar después de acuñar el token.

Algunos proyectos necesitan mutabilidad porque el token es dinámico.

Otros proyectos prometen que los metadatos serán permanentes y no cambiarán.

El esquema de metadatos debe coincidir con la promesa del proyecto.

Si una colección se comercializa como arte inmutable, los metadatos no deben permanecer bajo control administrativo sin restricciones.

Si un token es un objeto de juego, pueden esperarse metadatos dinámicos.

Si un token es una credencial, las actualizaciones pueden ser necesarias, pero deben poder auditarse.

Los usuarios deben comprobar quién controla las actualizaciones de metadatos.

Los desarrolladores deben documentar si los metadatos son inmutables, dinámicos, controlados por administradores o controlados por gobernanza.

La mutabilidad oculta es uno de los mayores riesgos de confianza en los metadatos NFT.

Esquema de metadatos y caché

El almacenamiento en caché consiste en guardar temporalmente metadatos para que las aplicaciones carguen tokens con mayor rapidez.

Las carteras, marketplaces, exploradores e indexadores suelen almacenar metadatos en caché.

La caché es útil porque obtener repetidamente todos los archivos de metadatos sería lento.

El problema es que los metadatos almacenados en caché pueden quedar desactualizados.

Durante un reveal, algunas aplicaciones pueden seguir mostrando imágenes provisionales después de que se publiquen los metadatos finales.

Durante una actualización dinámica, algunas aplicaciones pueden mostrar atributos antiguos hasta que se actualice la caché.

Los estándares de actualización de metadatos pueden ayudar a los clientes a saber cuándo actualizar los datos almacenados en caché.

Los desarrolladores deben admitir eventos de actualización cuando se espere que cambien los metadatos.

Los usuarios deben entender que los retrasos de visualización pueden proceder de la caché y no de un fallo del token.

Un esquema de metadatos sólido funciona mejor junto con un buen comportamiento de actualización de caché.

Esquema de metadatos e indexadores

Los indexadores recopilan datos de blockchain y los organizan para aplicaciones.

En el caso de los metadatos de token, los indexadores pueden llamar a

tokenURI
, obtener archivos JSON, analizar atributos, almacenar imágenes en caché y proporcionar respuestas API.

Los indexadores necesitan esquemas de metadatos predecibles para funcionar de forma eficiente.

Si cada proyecto utiliza nombres de campo inusuales, los indexadores deben crear lógica personalizada.

Si los archivos de metadatos no son válidos o son lentos, los indexadores pueden no mostrar los activos correctamente.

Si los metadatos cambian sin eventos, los indexadores pueden mostrar datos desactualizados.

Por ello, la coherencia del esquema beneficia a todo el ecosistema Web3.

Los desarrolladores deben probar los metadatos con el comportamiento habitual de los indexadores antes del lanzamiento.

Los usuarios deben saber que distintas carteras pueden mostrar metadatos diferentes si sus indexadores se actualizan en momentos distintos.

Los indexadores son una parte oculta, pero importante, de la usabilidad de los metadatos de token.

Buenas prácticas para desarrolladores

Utiliza campos de metadatos ampliamente compatibles, como

name
,
description
,
image
y
attributes
.

Devuelve JSON válido desde cada Token URI.

Utiliza nombres y valores de rasgos estables en toda una colección.

Utiliza almacenamiento duradero para archivos de metadatos y medios.

Fija archivos IPFS mediante pinning o utiliza un plan de almacenamiento fiable a largo plazo.

Documenta si los metadatos son mutables, inmutables o dinámicos.

Emite eventos de actualización de metadatos cuando cambien los metadatos.

Valida los metadatos antes de publicarlos de forma permanente.

Prueba el comportamiento de visualización en carteras, exploradores y dApps.

Evita incluir promesas legales sensibles únicamente dentro de metadatos editables.

Buenas prácticas para usuarios

Comprueba si los metadatos del token se almacenan en IPFS, un servidor, Arweave o on-chain.

Verifica la dirección oficial del contrato en lugar de confiar en el nombre o la imagen del token.

Ten cuidado con los metadatos que contienen enlaces externos o afirmaciones de recompensas.

No firmes transacciones únicamente para ver metadatos.

No introduzcas una frase de recuperación en ninguna página enlazada desde los metadatos del token.

Comprueba si un administrador puede cambiar los metadatos.

Revisa cuidadosamente los atributos durante los periodos de reveal de NFT.

Entiende que una imagen mostrada no demuestra autenticidad.

En los tokens de activos del mundo real, lee los documentos legales fuera del archivo de metadatos.

Trata los metadatos como información útil, no como prueba independiente de valor o seguridad.

Errores habituales en esquemas de metadatos de token

El primer error es publicar JSON no válido.

El segundo error es utilizar nombres de atributos incoherentes entre tokens.

El tercer error es apuntar los campos de imagen a archivos no disponibles.

El cuarto error es depender de un servidor centralizado sin divulgarlo.

El quinto error es cambiar los metadatos tras la acuñación sin reglas claras.

El sexto error es olvidar los requisitos de sustitución de

{id}
de ERC-1155.

El séptimo error es usar formatos multimedia no compatibles sin imágenes alternativas.

El octavo error es tratar los metadatos como jurídicamente vinculantes cuando solo son descriptivos.

El noveno error es no emitir eventos de actualización cuando cambian los metadatos.

El décimo error es incluir enlaces inseguros que pueden exponer a los usuarios al phishing.

Preguntas frecuentes

¿Qué significa esquema de metadatos de token?

Un esquema de metadatos de token es el formato estructurado utilizado para describir los metadatos de un token cripto, normalmente en JSON.

¿El esquema de metadatos de token es solo para NFT?

No. Es más habitual en NFT, pero los esquemas de metadatos también pueden admitir tokens fungibles, tokens de activos del mundo real y tokens específicos de aplicaciones.

¿Qué campos son habituales en los metadatos NFT?

Los campos habituales incluyen

name
,
description
,
image
,
animation_url
,
external_url
y
attributes
.

¿Cuál es la diferencia entre Token URI y el esquema de metadatos de token?

La Token URI apunta a los metadatos, mientras que el esquema de metadatos de token define la estructura de los metadatos que se encuentran allí.

¿Qué es ERC-721 Metadata JSON Schema?

Es el esquema básico de metadatos descrito por ERC-721 para los metadatos NFT devueltos mediante una Token URI.

¿Qué es ERC-1155 Metadata URI JSON Schema?

Es el esquema de metadatos utilizado por los tokens ERC-1155, incluido el soporte para la sustitución de ID de token mediante

{id}
.

¿Pueden almacenarse metadatos de token en IPFS?

Sí, los metadatos de token pueden almacenarse en IPFS utilizando identificadores de contenido que ayudan a verificar la integridad del contenido.

¿IPFS garantiza que los metadatos estarán siempre disponibles?

No. IPFS mejora el direccionamiento por contenido, pero los archivos aún deben estar fijados mediante pinning o ser servidos para que los usuarios puedan recuperarlos.

¿Pueden cambiar los metadatos de un token después de la acuñación?

Sí, los metadatos pueden cambiar si el proyecto utiliza metadatos dinámicos, servidores mutables, URI base controladas por administradores o lógica de resolución actualizable.

¿Qué son los metadatos dinámicos de token?

Los metadatos dinámicos de token son metadatos que cambian según el tiempo, la jugabilidad, la actividad del usuario, los datos de oráculos, el estado del contrato o las actualizaciones del proyecto.

¿Para qué se utiliza ERC-4906?

ERC-4906 define eventos de actualización de metadatos para que las carteras y aplicaciones sepan cuándo deben actualizarse los metadatos NFT.

¿Para qué se utiliza ERC-7572?

ERC-7572 estandariza

contractURI()
para metadatos a nivel de contrato, como el nombre, la descripción y la imagen de una colección.

¿Pueden ser maliciosos los metadatos?

Sí, los metadatos pueden incluir enlaces de phishing, reclamaciones falsas de recompensas, imágenes engañosas o referencias externas inseguras.

¿Por qué los rasgos NFT a veces se muestran incorrectamente?

Los rasgos NFT pueden mostrarse incorrectamente porque los atributos son incoherentes, faltan, están mal escritos, se almacenan en caché o tienen un formato que el cliente no entiende.

¿Qué caracteriza a un buen esquema de metadatos de token?

Un buen esquema de metadatos de token es válido, coherente, duradero, documentado, compatible con herramientas habituales y claro sobre si los metadatos pueden cambiar.

Conclusión

El esquema de metadatos de token es el formato estructurado que indica a carteras, dApps, exploradores, juegos, marketplaces e indexadores cómo leer información sobre un token cripto.

Es especialmente importante para los NFT porque la titularidad de NFT se almacena on-chain, mientras que los nombres, imágenes, rasgos, descripciones y medios suelen almacenarse mediante archivos de metadatos.

ERC-721 y ERC-1155 definen patrones de metadatos que ayudan a las aplicaciones a resolver y mostrar información sobre tokens de forma coherente.

Un buen esquema de metadatos facilita entender, filtrar, operar, verificar y utilizar tokens dentro de aplicaciones.

Un esquema de metadatos deficiente puede provocar imágenes rotas, rasgos ausentes, datos desactualizados, riesgo de phishing y confusión para los usuarios.

Los campos importantes incluyen

name
,
description
,
image
,
animation_url
,
attributes
y propiedades específicas del proyecto.

Las opciones de almacenamiento, como IPFS, HTTPS, Arweave y los datos on-chain, afectan a la permanencia, mutabilidad, coste y confianza.

Las actualizaciones de metadatos deben ser transparentes, especialmente para reveals, NFT dinámicos, activos de juego, credenciales y tokens de activos del mundo real.

Los desarrolladores deben validar los metadatos, utilizar almacenamiento duradero, documentar la mutabilidad, emitir eventos de actualización y probarlos con herramientas Web3 habituales.

Los usuarios deben verificar las direcciones de contrato, evitar enlaces de metadatos sospechosos, comprender el riesgo de almacenamiento y tratar los metadatos como descriptivos, en lugar de como prueba absoluta.

En un glosario cripto, el esquema de metadatos de token debe entenderse como el formato de datos que aporta significado legible para las personas a los tokens cripto y permite al ecosistema Web3 mostrar información de tokens de manera coherente y segura.
BTC ETFs See $679M in Outflows
BTC ETFs See $679M in OutflowsBTC ETFs See $679M in Outflows
Citi sees BTC at $113K. What do institutions see?