URI base

¿Qué es una URI base en el mundo cripto?

Una URI base es la ruta inicial común que utiliza un contrato inteligente para crear el enlace completo a los metadatos de los tokens de una colección cripto.

En los sistemas de metadatos de NFT y tokens, una URI indica a las carteras, los exploradores y las aplicaciones dónde encontrar los metadatos JSON que describen un token.

El estándar ERC-721 oficial define tokenURI como una función que devuelve un identificador uniforme de recursos (URI) distinto para un activo determinado.

La URI base suele combinarse con un ID de token para crear esa tokenURI completa.

Por ejemplo, una URI base podría ser ipfs://exampleCID/ y el ID de token 25 podría dar como resultado ipfs://exampleCID/25.

En otro diseño, la ruta completa a los metadatos puede incluir una extensión de archivo, como ipfs://exampleCID/25.json.

El resultado exacto depende de cómo cree el contrato inteligente la tokenURI.

La documentación de ERC-721 de OpenZeppelin explica que su función _baseURI se utiliza para calcular ERC721.tokenURI y que la URI resultante puede ser la concatenación de baseURI y tokenId.

Esto convierte la URI base en una herramienta práctica para ahorrar gas, organizar metadatos y facilitar la gestión de grandes colecciones de NFT.

Para los usuarios de criptomonedas, la URI base es importante porque determina desde dónde se cargan las imágenes, los rasgos, las descripciones y otros metadatos de los NFT.

Por qué es importante la URI base

La URI base es importante porque la propiedad del token y sus metadatos no siempre se almacenan en el mismo lugar.

Una blockchain puede almacenar el titular del token, su ID, el historial de transferencias, las autorizaciones y la lógica del contrato.

La imagen, el nombre, la descripción, los atributos, la animación y otros contenidos multimedia suelen almacenarse fuera de la blockchain.

La URI base conecta el token on-chain con la ubicación de sus metadatos, que puede estar off-chain o en un sistema descentralizado.

Si la URI base es correcta, las carteras y aplicaciones pueden mostrar el token adecuadamente.

Si la URI base es incorrecta, deja de funcionar, está centralizada o se modifica de forma maliciosa, el token puede mostrar imágenes ausentes, rasgos incorrectos o información engañosa.

Esto es especialmente importante en los NFT, ya que buena parte del valor que perciben los usuarios puede depender de los metadatos.

Un objeto coleccionable con rasgos poco comunes puede parecer valioso solo si sus metadatos están disponibles y son fiables.

Un objeto de un juego puede necesitar metadatos para mostrar su nivel, clase, diseño visual o utilidad.

Un NFT de membresía puede necesitar metadatos para mostrar su categoría o los derechos de acceso.

Por tanto, la URI base influye en la experiencia de usuario, la integridad de los metadatos, la confianza en la colección y la legibilidad del activo a largo plazo.

Cómo funciona la URI base

Normalmente, una URI base funciona almacenando o devolviendo un prefijo común dentro del contrato del token.

Después, el contrato añade un valor específico del token, a menudo el ID del token, para crear la URI completa de los metadatos.

Por ejemplo, si la URI base es ipfs://bafyExampleCollection/ y el ID del token es 100, la tokenURI final podría ser ipfs://bafyExampleCollection/100.

Si el contrato añade el sufijo .json, la tokenURI final podría ser ipfs://bafyExampleCollection/100.json.

Algunos contratos almacenan la URI base en una variable de estado que puede actualizar una dirección autorizada.

Otros fijan la URI base permanentemente en el momento del despliegue.

Algunos contratos devuelven distintas URI base según el estado de revelación, el tipo de token, el ID de cadena u otra lógica personalizada.

Otros no utilizan ninguna URI base y almacenan una URI completa y única para cada token.

La URI base no es un requisito universal para todos los contratos de NFT.

Es un patrón de implementación habitual para generar rutas a los metadatos de los tokens de forma eficiente.

URI base y tokenURI

La tokenURI es la URI completa que se devuelve para un token concreto.

La URI base es el prefijo reutilizable que puede ayudar a crear muchas tokenURI.

En los contratos ERC-721, tokenURI forma parte de la extensión de metadatos opcional.

El estándar ERC-721 indica que tokenURI puede apuntar a un archivo JSON que siga el esquema JSON de metadatos ERC-721.

Ese archivo JSON suele incluir campos como name, description e image.

La URI base no es lo mismo que los metadatos JSON.

Es la ruta que ayuda a una cartera o aplicación a encontrar esos metadatos JSON.

Un contrato sencillo puede devolver tokenURI uniendo la URI base y el ID del token.

Un contrato más complejo puede devolver una URI totalmente personalizada para cada token.

Un contrato de NFT dinámico puede generar tokenURI a partir del estado on-chain, en lugar de utilizar una URI base fija.

Los usuarios deben fijarse en lo que devuelve tokenURI, ya que esa es la ubicación real de los metadatos que utilizan las aplicaciones.

URI base en los NFT ERC-721

ERC-721 es el estándar de token más asociado a los NFT únicos y a los ID de token irrepetibles.

Cada token ERC-721 tiene un ID único dentro de un contrato específico.

La combinación de la dirección del contrato y el ID del token identifica de forma única el NFT en esa blockchain.

La extensión de metadatos permite a las aplicaciones solicitar al contrato la tokenURI.

La URI base ayuda al contrato a evitar el almacenamiento de una URI completa para cada token.

Esto resulta útil porque almacenar cadenas de texto largas on-chain puede ser caro.

En lugar de almacenar 10.000 enlaces completos a metadatos, una colección puede guardar una URI base y utilizar los ID de los tokens para crear enlaces individuales.

Este diseño es habitual en colecciones de imágenes de perfil, objetos de juegos, pases de membresía, series de arte y conjuntos de objetos coleccionables.

Por ejemplo, los tokens 1, 2 y 3 pueden compartir la misma URI base, aunque cada uno apunte a un archivo de metadatos diferente.

La URI base compartida mantiene la estructura sencilla y predecible.

URI base en los tokens ERC-1155

ERC-1155 es un estándar mult token que puede admitir tokens fungibles, tokens semifungibles y NFT en un mismo contrato.

ERC-1155 gestiona los metadatos de forma distinta a muchas implementaciones de ERC-721.

El estándar ERC-1155 oficial indica que el valor URI permite a los clientes sustituir el ID cuando la cadena {id} aparece en una URI.

Los clientes deben sustituir {id} por el ID real del token en formato hexadecimal en minúsculas, con 64 caracteres cuando sea necesario.

Así, un gran número de ID de tokens puede utilizar un único patrón de URI compartido.

Por ejemplo, una URI podría tener este aspecto: https://example.com/metadata/{id}.json.

Una cartera o aplicación sustituye {id} por el ID del token con el formato correspondiente para encontrar el archivo JSON correcto.

Su finalidad es similar a la de la URI base, ya que permite crear muchos enlaces a metadatos de tokens a partir de un patrón compartido.

Sin embargo, ERC-1155 utiliza una regla de sustitución específica, en lugar del patrón sencillo de URI base más ID de token que se observa en muchos contratos ERC-721.

Los desarrolladores no deben dar por hecho que las rutas de metadatos de ERC-721 y ERC-1155 se crean del mismo modo.

URI base y metadatos de NFT

Los metadatos de NFT son información estructurada que indica a los usuarios qué representa un token.

Los metadatos pueden incluir el nombre, la descripción, la imagen, la URL de animación, los atributos, el fondo, los rasgos de rareza, los niveles, las referencias a contenido desbloqueable, enlaces externos y otros campos.

El esquema de metadatos ERC-721 incluye campos básicos como name, description e image.

El esquema de metadatos ERC-1155 también incluye campos descriptivos habituales y admite datos de visualización específicos de cada token.

La URI base suele apuntar a un directorio o endpoint donde se encuentran los archivos de metadatos.

Si los metadatos se almacenan como archivos JSON, cada ID de token suele corresponder a un archivo JSON.

Si los metadatos son dinámicos, la URI base puede apuntar a un endpoint de API que devuelva distintos archivos JSON con el tiempo.

Si los metadatos utilizan direccionamiento por contenido, la URI base puede apuntar a un identificador de almacenamiento descentralizado.

La calidad de la URI base determina si las aplicaciones pueden encontrar y mostrar los metadatos de forma coherente.

Un token sin metadatos puede seguir existiendo on-chain, pero a los usuarios les puede resultar mucho más difícil entenderlo o valorarlo.

URI base e IPFS

IPFS es un sistema de almacenamiento descentralizado habitual para los metadatos y los contenidos multimedia de NFT.

La guía de datos de NFT de IPFS oficial recomienda utilizar URI de IPFS para enlazar desde contratos inteligentes con datos externos de NFT almacenados en IPFS.

Una URI de IPFS suele empezar por ipfs:// e incluye un identificador de contenido, también llamado CID.

Una URI base que utilice IPFS podría tener este aspecto: ipfs://bafyExampleCID/.

Después, cada archivo de metadatos del token puede almacenarse en ese directorio de IPFS.

Este diseño puede hacer que los metadatos de NFT sean más resistentes a la manipulación que los enlaces web normales, porque un CID hace referencia al contenido por sus datos, no solo por la ubicación de un servidor.

Si cambia el contenido, también cambia el CID.

Esto ayuda a los usuarios a detectar si los metadatos se han modificado.

Sin embargo, el contenido de IPFS debe seguir disponible en al menos un nodo o proveedor de pinning para que los usuarios puedan recuperarlo fácilmente.

Utilizar una URI base de IPFS mejora la integridad, pero no elimina la necesidad de planificar el almacenamiento a largo plazo.

URI base y URL HTTP

Una URI base también puede utilizar una URL HTTPS normal.

Por ejemplo, una colección puede utilizar https://example.com/metadata/ como URI base.

La tokenURI del token 100 podría ser entonces https://example.com/metadata/100.json.

Los metadatos HTTPS pueden ser sencillos y flexibles porque el proyecto puede actualizar archivos en un servidor web.

Esta flexibilidad puede ser útil para juegos, NFT dinámicos, membresías o arte en evolución.

También conlleva riesgos de confianza, porque el propietario del servidor puede modificar, eliminar o redirigir los metadatos, o bloquear el acceso a ellos.

Si el dominio caduca o el proveedor de alojamiento deja de funcionar, el NFT puede dejar de mostrarse correctamente.

Si se vulnera la cuenta de administración del proyecto, la URI base o el endpoint de metadatos pueden servir contenido malicioso o engañoso.

Los metadatos HTTP centralizados son fáciles de utilizar, pero pueden reducir la permanencia a largo plazo.

Los usuarios deben comprobar si el proyecto utiliza almacenamiento con direccionamiento por contenido, servidores web centralizados o un enfoque híbrido.

URI base y almacenamiento al estilo de Arweave

Algunos proyectos de NFT utilizan sistemas de almacenamiento permanente para sus metadatos y contenidos multimedia.

En estos sistemas, los metadatos pueden referenciarse mediante un ID de transacción o una ruta permanente al contenido.

Una URI base puede apuntar a una pasarela de almacenamiento permanente o a una ruta de manifiesto que organice los archivos de metadatos de muchos tokens.

Este enfoque puede reducir el riesgo de que desaparezca un servidor web normal.

También puede reducir la necesidad de pagar continuamente por el pinning, si el sistema de almacenamiento está diseñado para conservar los datos a largo plazo.

No obstante, los usuarios deben entender el formato exacto de la URI y el funcionamiento de la pasarela.

Una URL de pasarela no siempre es lo mismo que el identificador permanente de contenido subyacente.

Si un contrato solo almacena una URL de pasarela, la visualización puede depender de que esa pasarela esté disponible.

Un diseño más sólido deja claro y permite verificar el identificador permanente.

El diseño de la URI base debe facilitar la auditoría de la ubicación de los datos a largo plazo.

URI base y metadatos on-chain

Algunos tokens no dependen de una URI base externa porque sus metadatos se almacenan o generan íntegramente on-chain.

Los metadatos on-chain pueden devolverse como una URI de datos que incluya JSON codificado directamente por el contrato inteligente.

En este diseño, tokenURI puede devolver una cadena que empiece por data:application/json, en vez de ipfs:// o https://.

Esto puede hacer que los metadatos sean más autónomos, ya que el propio contrato del token los genera.

Los metadatos on-chain pueden ser útiles para arte generativo, juegos íntegramente on-chain, sistemas de identidad y objetos coleccionables inmutables.

La contrapartida es que el almacenamiento y los cálculos on-chain pueden resultar caros.

Puede ser difícil almacenar directamente on-chain imágenes grandes, animaciones y metadatos complejos.

Por ello, muchos proyectos utilizan una URI base para metadatos externos y reservan los metadatos íntegramente on-chain para casos de uso especiales.

No existe un único modelo óptimo para todos los proyectos.

El diseño de metadatos más adecuado depende del coste, la permanencia, la flexibilidad, las expectativas de los usuarios y la complejidad técnica.

URI base y revelación de metadatos

Muchas colecciones de NFT utilizan una URI base durante el proceso de revelación.

Antes de la revelación, todos los tokens pueden devolver los mismos metadatos provisionales.

Estos metadatos provisionales pueden mostrar una imagen misteriosa o una descripción genérica de la colección.

Tras la revelación, el proyecto actualiza la URI base para que cada token apunte a su archivo definitivo de metadatos.

Esto puede hacer que la acuñación parezca más justa, ya que los usuarios desconocen los rasgos finales de cada token antes de la revelación.

Sin embargo, los diseños de revelación requieren confianza.

Si el proyecto controla la URI base, puede tener la capacidad de cambiar los metadatos después de la acuñación.

Si el proceso de revelación no es transparente, los usuarios pueden temer que los rasgos poco comunes se hayan asignado de forma injusta.

Los proyectos pueden reducir esta preocupación publicando hashes de procedencia, utilizando aleatoriedad verificable, bloqueando los metadatos tras la revelación o haciendo que la generación de metadatos pueda auditarse.

Los usuarios deben saber si la URI base de una colección es provisional, ya se ha revelado, es modificable o está bloqueada de forma permanente.

URI base modificable

Una URI base modificable es aquella que puede cambiarse después del despliegue del contrato.

Puede ser útil si los metadatos no están listos en el lanzamiento, si es necesario migrar contenidos multimedia o si los NFT dinámicos necesitan actualizaciones.

También puede ser peligrosa, porque quien controle la función de actualización podría cambiar lo que muestran todos los tokens.

Un proyecto podría sustituir las ilustraciones, cambiar los rasgos, redirigir los metadatos a un nuevo servidor o eliminar contenido.

Un administrador malicioso podría modificar los metadatos de forma que perjudicara el valor de los tokens o engañara a los usuarios.

Una clave de administración comprometida podría producir el mismo resultado, aunque el equipo original fuera honesto.

Los usuarios deben comprobar si la URI base todavía puede modificarse.

También deben comprobar quién puede cambiarla.

Una URI base modificable controlada por una única wallet externa entraña más riesgos que un proceso de actualización bien gobernado.

La posibilidad de modificar los metadatos debe comunicarse claramente, ya que cambia el modelo de confianza del token.

URI base inmutable

Una URI base inmutable no puede modificarse después del despliegue o tras una acción de bloqueo definitiva.

Esto puede aumentar la confianza, ya que los usuarios saben que un administrador no podrá cambiar posteriormente la ruta de los metadatos.

Las URI base inmutables son habituales en proyectos que buscan la permanencia de sus objetos coleccionables a largo plazo.

Resultan especialmente sólidas si se combinan con almacenamiento con direccionamiento por contenido, como los CID de IPFS.

Sin embargo, la inmutabilidad también puede generar problemas si la URI original contiene un error.

Si faltan archivos de metadatos, tienen un formato incorrecto o se han subido a una ruta equivocada, el proyecto quizá no pueda corregirlos.

Si cambia el funcionamiento de una pasarela de almacenamiento, puede que el contrato no pueda adaptarse.

Los desarrolladores deben probar cuidadosamente las rutas de metadatos antes de bloquear la URI base.

Los usuarios deben entender que la inmutabilidad protege frente a cambios posteriores, pero no garantiza que los metadatos originales fueran correctos.

Un error permanente sigue siendo permanente.

URI base y actualizaciones de metadatos ERC-4906

ERC-4906 es una extensión de actualización de metadatos para tokens ERC-721.

El estándar ERC-4906 oficial añade los eventos MetadataUpdate y BatchMetadataUpdate para señalar cambios en los metadatos.

Esto es importante porque las carteras, los indexadores y las aplicaciones suelen almacenar los metadatos en caché.

Si cambia una URI base, pero las aplicaciones no actualizan su caché, los usuarios pueden seguir viendo los metadatos antiguos.

ERC-4906 ofrece a los contratos una forma estándar de comunicar a los sistemas de terceros que han cambiado los metadatos de los tokens.

Esto resulta útil para eventos de revelación, NFT dinámicos, objetos de juego en evolución y correcciones de metadatos posteriores a la acuñación.

Sin embargo, el estándar no hace que los cambios en los metadatos sean seguros por sí mismo.

Solo ayuda a indicar que los metadatos han cambiado.

Los controles de permisos para modificar los metadatos siguen siendo importantes.

Si un proyecto utiliza una URI base modificable o metadatos dinámicos, la autoridad de actualización debe estar protegida y documentada con claridad.

URI base y metadatos múltiples ERC-7160

ERC-7160 es una extensión de ERC-721 que permite admitir varias URI de metadatos por token.

El estándar ERC-7160 oficial describe un sistema en el que un token puede tener varias URI de metadatos y una URI principal fijada.

Esto es relevante para la URI base porque los metadatos ya no se encuentran siempre en una única ubicación estática.

Un token puede tener varias versiones, formatos, revisiones u opciones de visualización.

Por ejemplo, una obra dinámica puede tener varios estados de metadatos aprobados.

Un objeto de juego puede tener distintos metadatos después de mejoras o eventos.

Un NFT colaborativo puede incluir metadatos de varios creadores.

La compatibilidad con varios metadatos puede mejorar la flexibilidad, pero también complica su auditoría.

Los usuarios y las aplicaciones deben saber cuál es la URI principal y si las URI anteriores siguen disponibles.

La URI base sigue siendo importante, ya que a menudo es la ruta raíz de una o varias de esas ubicaciones de metadatos.

URI base y eficiencia de gas

La URI base se utiliza a menudo para reducir los costes de gas.

Almacenar una URI completa de metadatos para cada token puede resultar caro, ya que el almacenamiento on-chain consume gas.

Una URI base compartida permite que un contrato almacene menos información.

En lugar de guardar miles de cadenas largas, el contrato puede almacenar un único prefijo y calcular las rutas específicas de cada token cuando sea necesario.

Esto resulta especialmente útil para colecciones grandes con muchos ID de tokens.

Por ejemplo, una colección de 10.000 tokens puede utilizar una URI base y 10.000 archivos JSON identificados por el ID de cada token.

El contrato solo necesita la lógica necesaria para combinar la URI base y el ID del token.

Esto ahorra almacenamiento, pero reduce la flexibilidad frente a la opción de almacenar una URI personalizada para cada token.

Los desarrolladores deben elegir entre ahorrar gas y disponer de flexibilidad en los metadatos.

Un diseño de bajo coste puede seguir siendo inseguro si facilita demasiado la modificación de los metadatos o dificulta su verificación.

URI base y nombres de archivo

Los nombres de archivo son importantes porque la creación de tokenURI debe corresponderse con los archivos reales de metadatos.

Si el contrato devuelve ipfs://CID/1, la ubicación de almacenamiento debe contener un archivo u objeto llamado 1.

Si la ubicación contiene 1.json, pero el contrato devuelve solo 1, algunas aplicaciones pueden no conseguir cargar los metadatos.

Si el contrato devuelve 0001.json, pero los archivos se llaman 1.json, también pueden producirse errores en los metadatos.

ERC-1155 añade otra capa, ya que la sustitución del ID del token utiliza un formato hexadecimal en minúsculas con relleno.

Los desarrolladores deben decidir cómo nombrar los archivos antes del despliegue.

Deben probar las salidas de tokenURI frente a archivos reales de metadatos en redes de prueba.

Deben probar varios ID de tokens, incluidos ID bajos, altos y los que no sigan una secuencia.

También deben comprobar cómo interpretan los metadatos las carteras y los indexadores.

Pequeños errores en los nombres pueden causar grandes problemas de visualización en toda una colección.

URI base y barras finales

Una barra final es la barra situada al final de una URI base.

Puede determinar si la tokenURI final es válida.

Por ejemplo, ipfs://CID/ más el ID de token 1 da como resultado ipfs://CID/1.

Sin la barra, ipfs://CID más el ID de token 1 da como resultado ipfs://CID1, que puede ser incorrecto.

El mismo problema puede producirse en rutas HTTPS.

https://example.com/metadata/ más 1.json forma una ruta de archivo clara.

https://example.com/metadata más 1.json da como resultado https://example.com/metadata1.json, que quizá no exista.

Los desarrolladores deben gestionar de forma coherente las barras y los sufijos en el contrato.

Los usuarios no siempre pueden detectar este problema al ver el NFT en un mercado.

Cuando no se cargan los metadatos, lo primero que suele comprobarse es la cadena tokenURI exacta que devuelve el contrato.

URI base y almacenamiento en caché de metadatos

Muchas carteras, mercados, exploradores y servicios de indexación almacenan en caché los metadatos de los NFT.

El almacenamiento en caché mejora la velocidad porque las aplicaciones no tienen que recuperar los metadatos desde cero cada vez.

Sin embargo, puede hacer que los cambios en la URI base resulten confusos.

Un proyecto puede actualizar los metadatos, pero algunas aplicaciones pueden seguir mostrando la imagen o los atributos antiguos.

Esta es una de las razones por las que pueden ser útiles los eventos de actualización de metadatos.

ERC-4906 se creó para ofrecer a los contratos una forma estándar de señalar cambios en los metadatos.

Aun así, no todas las aplicaciones actualizan los datos al instante ni admiten todos los eventos de metadatos.

Los usuarios deben tener en cuenta que, durante los retrasos de actualización, un token puede mostrar metadatos distintos en diferentes aplicaciones.

Esto no significa necesariamente que haya cambiado la propiedad del token o que este haya dejado de funcionar.

Puede que simplemente no se haya actualizado la caché de metadatos.

URI base y riesgo de centralización

La URI base puede conllevar un riesgo de centralización si apunta a un servidor o dominio controlado por una sola parte.

Si un proyecto almacena los metadatos en un dominio web normal, el propietario del dominio puede cambiar los archivos.

El dominio también puede caducar, ser confiscado o pirateado, o dejar de estar disponible.

Un estudio sobre los riesgos de centralización de los metadatos de NFT destaca que el almacenamiento centralizado puede exponer los datos de los NFT a la censura, las brechas de seguridad y los cambios administrativos.

Esto es importante porque muchos usuarios creen que poseer un NFT significa que el activo completo está almacenado permanentemente on-chain.

En realidad, puede que el token solo apunte a metadatos almacenados en otro lugar.

Si ese enlace es frágil, el activo que ve el usuario también puede serlo.

El almacenamiento con direccionamiento por contenido y un bloqueo claro de los metadatos pueden reducir este riesgo.

No obstante, cada proyecto necesita un plan de almacenamiento a largo plazo.

Un NFT atractivo puede convertirse en un enlace roto si su URI base se gestiona mal.

URI base y direccionamiento por contenido

El direccionamiento por contenido significa que el identificador se basa en el propio contenido.

Los CID de IPFS son un ejemplo habitual en los metadatos cripto.

Cuando los metadatos utilizan direccionamiento por contenido, cualquier modificación genera un identificador distinto.

Esto facilita la detección de manipulaciones.

Por tanto, una URI base que incluya un CID puede ofrecer a los usuarios más confianza en que los archivos referenciados no han cambiado sin que se sepa.

Esto es distinto de una URL normal, en la que el servidor puede ofrecer contenido nuevo en la misma dirección.

El direccionamiento por contenido no significa que el contenido se almacene automáticamente para siempre.

Alguien debe alojar, fijar o conservar los datos de algún otro modo.

Tampoco garantiza que los metadatos originales fueran honestos o de calidad.

Solo ayuda a verificar que el contenido asociado a ese identificador sigue siendo el mismo.

URI base y NFT dinámicos

Los NFT dinámicos son tokens cuyos metadatos pueden cambiar según acontecimientos, el tiempo, las acciones de los usuarios, el estado de un juego, los datos de un oráculo o la lógica del contrato.

Los NFT dinámicos pueden utilizar una URI base que apunte a una API o servicio de metadatos dinámicos.

También pueden generar metadatos on-chain a partir de estados cambiantes.

Una URI base dinámica puede hacer que los NFT sean más interactivos y útiles.

Por ejemplo, un NFT de personaje de un juego puede subir de nivel y mostrar nuevos atributos.

Un NFT de membresía puede cambiar de aspecto cuando un usuario alcanza un determinado nivel.

Un token de activo del mundo real puede actualizar sus metadatos cuando se renuevan los documentos.

El riesgo es que los metadatos dinámicos requieren confianza en las reglas de actualización.

Los usuarios deben saber qué puede cambiar, quién puede hacerlo y si los cambios se rigen por código, administradores o sistemas off-chain.

Los metadatos dinámicos solo son realmente útiles cuando las reglas son transparentes.

URI base y seguridad

La seguridad de la URI base depende del almacenamiento, los controles de acceso, la lógica del contrato y las expectativas de los usuarios.

Si la URI base puede actualizarse, la función de actualización debe contar con controles de permisos sólidos.

Si una clave privada controla la URI base, esa clave se convierte en un objetivo de gran valor.

Si una wallet multifirma controla la URI base, la seguridad depende de la calidad de los firmantes y de las reglas de umbral.

Si la URI base está bajo control de gobernanza, la seguridad depende de la distribución del voto y de los procesos de actualización.

Si la URI base apunta a un servidor, importan tanto la seguridad del servidor como la del dominio.

Si apunta a IPFS, importan el pinning y la disponibilidad del contenido.

Si los metadatos se generan on-chain, importa que el contrato sea correcto.

No existe un único modelo de seguridad para las URI base.

La pregunta clave siempre es qué puede cambiar, quién puede cambiarlo y cómo pueden verificarlo los usuarios.

URI base y actualizaciones de contratos inteligentes

Los contratos inteligentes actualizables pueden cambiar la forma en que se calcula tokenURI.

Esto significa que la lógica de la URI base puede cambiar aunque la variable visible de URI base parezca estable.

Un contrato de NFT actualizable puede permitir a los desarrolladores corregir errores o añadir funciones.

También puede permitir cambiar el comportamiento de los metadatos después de que los usuarios hayan comprado los tokens.

Los usuarios deben comprobar si el contrato es actualizable.

También deben comprobar quién controla las actualizaciones y si existe un bloqueo temporal o un proceso de gobernanza.

Bloquear la URI base tiene menos sentido si una actualización puede sustituir toda la función tokenURI.

Para obtener garantías sólidas sobre los metadatos, deben revisarse tanto la URI base como la vía de actualización del contrato.

Los desarrolladores deben comunicar claramente si el contrato es actualizable, ya que esto afecta a la confianza.

Los usuarios no deben evaluar la permanencia de los metadatos basándose únicamente en la URI base.

URI base y verificación de tokens

La URI base puede ayudar a los usuarios a verificar si los metadatos de un token proceden de la fuente esperada de la colección.

Sin embargo, los usuarios no deben confiar únicamente en el aspecto de la imagen o en el nombre del token.

Los tokens falsos pueden copiar los metadatos, nombres, símbolos e imágenes de colecciones reales.

El identificador real es la dirección del contrato y el ID del token en la blockchain correcta.

La URI base puede mostrar a dónde apuntan los metadatos, pero por sí sola no demuestra que el token sea auténtico.

Un contrato fraudulento puede apuntar a metadatos copiados de una colección legítima.

Los usuarios deben verificar la dirección del contrato, el estándar del token, la información del creador, la ruta de los metadatos, el historial de propiedad y las fuentes oficiales del proyecto.

Los desarrolladores deben procurar que los resultados de tokenURI sean predecibles y fáciles de inspeccionar.

Un diseño claro de URI base facilita la verificación, pero no sustituye a la verificación del contrato.

La autenticidad depende tanto de la identidad del token como de la integridad de sus metadatos.

URI base y metadatos de la colección

La URI base suele referirse a las rutas de metadatos de cada token.

Los metadatos de la colección son distintos, ya que describen el contrato o la colección en su conjunto.

Pueden incluir el nombre y la descripción de la colección, una imagen, un banner, enlaces externos, comisiones o información de redes sociales.

Algunos contratos ofrecen metadatos de la colección mediante funciones separadas, como contractURI.

No debe confundirse la URI base del token con la URI de metadatos de la colección.

La URI base del token ayuda a generar metadatos para ID de tokens individuales.

La URI de metadatos de la colección describe la colección en su conjunto.

Ambas pueden afectar a cómo muestran un proyecto las carteras y las aplicaciones.

Ambas también pueden conllevar riesgos de centralización o modificación.

Los usuarios deben saber qué URI controla los datos de cada token y cuál controla los datos de visualización de la colección.

URI base y congelación de metadatos

Congelar los metadatos significa hacer que no puedan modificarse permanentemente o indicar que ya no deberían cambiar.

Un proyecto puede congelar los metadatos eliminando la posibilidad de actualizar la URI base.

También puede hacerlo fijando la URI base a una ruta de almacenamiento con direccionamiento por contenido y renunciando a la autoridad de actualización.

Algunos proyectos anuncian que los metadatos se congelan tras la revelación.

Los usuarios deben comprobar si el bloqueo está aplicado por el código o si solo lo ha prometido el equipo.

Una promesa ofrece menos garantías que un bloqueo a nivel de contrato.

Un bloqueo a nivel de contrato tampoco ofrece tantas garantías si el contrato sigue siendo actualizable.

Para congelar realmente los metadatos, es necesario revisar todas las vías que podrían cambiar los resultados de tokenURI.

La congelación puede aumentar la confianza de los coleccionistas cuando la permanencia es importante.

Sin embargo, congelar los metadatos demasiado pronto puede dejar fijados errores que ya no podrán corregirse.

URI base y experiencia de usuario

La URI base influye en la experiencia de usuario porque las aplicaciones utilizan los metadatos para mostrar qué poseen los usuarios.

Si la URI base se carga rápidamente, los NFT se muestran sin problemas.

Si es lenta, no está disponible o se bloquea, las carteras pueden mostrar imágenes en blanco o marcadores genéricos.

Si el JSON de los metadatos está mal formado, es posible que las aplicaciones no puedan analizarlo.

Si los enlaces a imágenes incluidos en los metadatos están rotos, el token puede mostrar texto, pero no contenido multimedia.

Si los rasgos son incoherentes, las herramientas de rareza y los juegos pueden interpretar mal el token.

Los usuarios suelen valorar las colecciones según lo que ven en su cartera.

Por ello, los desarrolladores deben tratar el diseño de la URI base como parte de la calidad del producto.

Los metadatos deben ser válidos, estables, lo bastante rápidos para recuperarse y coherentes entre los distintos ID de tokens.

Un contrato inteligente sólido puede parecer defectuoso si la URI base y los metadatos se gestionan mal.

Ejemplos de URI base

Una URI base sencilla de IPFS podría ser ipfs://bafyExampleCID/.

Si el contrato añade el ID de token 7 y el sufijo .json, la tokenURI completa podría ser ipfs://bafyExampleCID/7.json.

Una URI base HTTPS sencilla podría ser https://example.com/api/token/.

Si el contrato añade el ID de token 7, la tokenURI completa podría ser https://example.com/api/token/7.

Una plantilla URI de ERC-1155 podría ser https://example.com/metadata/{id}.json.

En ese caso, los clientes compatibles sustituyen {id} por el ID del token con el formato correspondiente.

Una URI de datos on-chain puede empezar por data:application/json;base64, en lugar de utilizar una URI base.

Estos ejemplos muestran por qué los usuarios deben comprobar la tokenURI que devuelve realmente el contrato, en lugar de deducirla de la web de la colección.

La función tokenURI del contrato es la fuente que suelen consultar las aplicaciones.

La URI base solo resulta útil si genera tokenURI válidas y accesibles.

Ventajas de utilizar una URI base

La primera ventaja de la URI base es la eficiencia de gas.

Un prefijo compartido puede reducir la cantidad de datos almacenados on-chain.

La segunda ventaja es que facilita la organización de la colección.

Los desarrolladores pueden almacenar los archivos de metadatos en una carpeta o endpoint y asignarlos a los ID de los tokens.

La tercera ventaja es que simplifica la acuñación de colecciones grandes.

Los tokens nuevos pueden acceder automáticamente a rutas de metadatos predecibles.

La cuarta ventaja es que facilita la gestión de la revelación.

Si el contrato lo permite, un proyecto puede pasar de los metadatos provisionales a los definitivos cambiando una sola URI base.

La quinta ventaja es la compatibilidad.

Las carteras, los exploradores y las aplicaciones están acostumbrados a leer tokenURI y rutas de metadatos con formato URI.

La sexta ventaja es la flexibilidad.

La URI base puede admitir IPFS, HTTPS, enlaces de almacenamiento permanente, endpoints de API o diseños híbridos.

Riesgos de utilizar una URI base

El primer riesgo es que los metadatos dejen de funcionar.

Una URI base incorrecta puede inutilizar todos los tokens de una colección.

El segundo riesgo es la centralización.

Una URI base que apunte a un servidor normal depende de ese servidor, del dominio y de su operador.

El tercer riesgo son las actualizaciones maliciosas.

Si un administrador puede cambiar la URI base, podría cambiar lo que muestran todos los tokens.

El cuarto riesgo es la posibilidad de modificación oculta.

Los usuarios pueden creer que los metadatos son permanentes cuando la URI base todavía se puede modificar.

El quinto riesgo es la confusión por el almacenamiento en caché.

Las aplicaciones pueden mostrar metadatos antiguos tras una actualización de la URI base.

El sexto riesgo es la disponibilidad del almacenamiento.

Incluso puede ser difícil recuperar los metadatos con direccionamiento por contenido si nadie los aloja o fija.

El séptimo riesgo es la lógica actualizable.

Una actualización del contrato puede cambiar el comportamiento de tokenURI aunque la URI base parezca bloqueada.

Cómo comprobar una URI base

Los usuarios pueden comprobar el funcionamiento de la URI base llamando a la función tokenURI para el ID de un token concreto.

Deben comparar la URI devuelta con lo que afirma el proyecto sobre sus metadatos.

Deben comprobar si la URI empieza por ipfs://, https://, data:, ar:// u otro esquema.

Deben probar si el archivo de metadatos se carga y devuelve un JSON válido.

Deben comprobar si el JSON incluye image, description, attributes y los demás campos esperados.

Deben verificar que los enlaces a imágenes del JSON también sean estables y accesibles.

Deben revisar el contrato para saber si se puede cambiar la URI base.

Deben comprobar si el contrato es actualizable.

Deben estar atentos a los eventos de actualización de metadatos cuando una colección afirme que estos han cambiado.

No deben dar por hecho que un token es seguro solo porque se muestre correctamente en una cartera.

Buenas prácticas para desarrolladores

Los desarrolladores deben decidir el modelo de almacenamiento de metadatos antes de desplegar el contrato del token.

Deben elegir si la URI base será inmutable, modificable, basada en una revelación, dinámica o íntegramente on-chain.

Deben utilizar enlaces con direccionamiento por contenido cuando la integridad a largo plazo sea importante.

Deben probar las salidas de tokenURI para muchos ID de tokens antes del lanzamiento.

Deben mantener la coherencia en los nombres de archivo, los sufijos y las barras finales.

Deben proteger las funciones de actualización de la URI base mediante controles de acceso sólidos.

Deben comunicar si los metadatos pueden cambiar después de la acuñación.

Cuando cambien los metadatos, deben emitir eventos estándar de actualización de metadatos si el contrato admite ese patrón.

Deben conservar copias de seguridad y planes de alojamiento a largo plazo para todos los metadatos y contenidos multimedia.

Deben recordar que los metadatos forman parte de la confianza de los usuarios, no son solo una función de visualización.

Buenas prácticas para usuarios

Los usuarios deben verificar la dirección del contrato antes de confiar en los metadatos.

Deben comprobar la tokenURI de un token real, en lugar de confiar en capturas de pantalla.

Deben preferir proyectos que expliquen claramente dónde se almacenan los metadatos.

Deben entender si todavía se puede cambiar la URI base.

Deben comprobar si los metadatos se almacenan en sistemas con direccionamiento por contenido o en servidores centralizados.

Deben tener cuidado con los proyectos que prometen permanencia, pero mantienen permisos de actualización para los administradores.

Deben estar atentos a cambios repentinos en los metadatos después de la revelación o la venta.

Deben recordar que poseer un NFT no siempre implica poseer el archivo multimedia, los derechos de autor o los derechos off-chain.

Cuando sea importante mantener el acceso a largo plazo, los usuarios deben guardar localmente los metadatos y contenidos multimedia importantes.

Deben considerar los metadatos rotos o sospechosos como una señal de riesgo.

Malentendidos habituales sobre la URI base

Un malentendido habitual es creer que la URI base almacena el propio NFT.

La URI base suele apuntar a los metadatos, mientras que el contrato inteligente registra la propiedad.

Otro malentendido es creer que la imagen de un NFT siempre se almacena on-chain.

Muchas imágenes de NFT se almacenan off-chain o en sistemas de almacenamiento descentralizados, y se referencian mediante metadatos.

Un tercer malentendido es creer que IPFS garantiza que el contenido seguirá disponible para siempre.

IPFS mejora la integridad del contenido, pero alguien debe seguir poniéndolo a disposición de los usuarios.

Un cuarto malentendido es creer que una URI base bloqueada garantiza la propiedad legal del activo mostrado en los metadatos.

La permanencia de los metadatos y los derechos legales son cuestiones distintas.

Un quinto malentendido es creer que todo cambio de URI base es negativo.

Algunos cambios son legítimos para una revelación, NFT dinámicos o correcciones de errores, pero deben ser transparentes y estar debidamente controlados.

Un sexto malentendido es creer que una visualización correcta demuestra que la URI base es segura.

Las cachés pueden ocultar problemas, por lo que los usuarios deben inspeccionar la tokenURI real cuando sea posible.

Términos cripto relacionados

URI significa identificador uniforme de recursos; es una cadena que se utiliza para identificar un recurso, como un archivo de metadatos.

tokenURI es la función de ERC-721 que devuelve la URI de metadatos de un ID de token concreto.

ERC-721 es un estándar de token habitual de Ethereum para tokens no fungibles.

ERC-1155 es un estándar mult token que puede admitir activos fungibles, semifungibles y no fungibles.

Los metadatos de NFT son los datos JSON o estructurados que describen el nombre, la imagen, los rasgos y otras propiedades de un token.

IPFS significa InterPlanetary File System, una red de almacenamiento con direccionamiento por contenido que se utiliza habitualmente para datos de NFT.

CID significa identificador de contenido; es una referencia con direccionamiento por contenido utilizada por IPFS.

Una URI de datos es una URI que integra datos directamente en la cadena de texto de la propia URI.

La revelación de metadatos es el proceso de sustituir los metadatos provisionales de los tokens por los metadatos definitivos.

La congelación de metadatos consiste en hacer que los metadatos de los tokens o sus rutas no puedan modificarse a partir de cierto momento.

Preguntas frecuentes

¿Qué significa URI base en los NFT?

La URI base es la ruta inicial compartida que utiliza un contrato inteligente para crear la URI completa de los metadatos de cada NFT.

¿URI base y tokenURI son lo mismo?

No. La URI base suele ser el prefijo compartido, mientras que tokenURI es la URI completa de los metadatos que se devuelve para un token concreto.

¿Cómo funciona la URI base en ERC-721?

En muchos contratos ERC-721, la URI base se combina con el ID del token para producir la tokenURI final de ese NFT.

¿Cómo funciona la URI base en ERC-1155?

ERC-1155 suele utilizar una plantilla de URI con sustitución de {id}, que los clientes reemplazan por el ID del token con el formato correspondiente.

¿Se puede cambiar una URI base?

Sí, se puede cambiar si el contrato incluye una función de actualización y una cuenta autorizada sigue controlándola.

¿Es arriesgada una URI base modificable?

Sí, porque quien la controle puede tener la capacidad de cambiar los metadatos de muchos o todos los tokens.

¿Siempre es mejor una URI base inmutable?

Una URI base inmutable puede aumentar la confianza, pero también puede dejar los errores bloqueados permanentemente si las rutas de metadatos eran incorrectas en el lanzamiento.

¿Por qué utilizan IPFS los proyectos de NFT para la URI base?

Los proyectos utilizan IPFS porque los CID de IPFS tienen direccionamiento por contenido y ayudan a verificar que los metadatos referenciados no hayan cambiado sin que se sepa.

¿IPFS garantiza que los metadatos de NFT seguirán disponibles para siempre?

No. IPFS ayuda a preservar la integridad, pero el contenido debe seguir alojándose, fijándose o poniéndose a disposición de los usuarios de algún otro modo.

¿Por qué no se muestra la imagen de mi NFT si soy titular del token?

Puede que la imagen no se muestre porque la URI base sea incorrecta, el archivo de metadatos no esté disponible, el enlace a la imagen esté roto o la caché de la aplicación no se haya actualizado.

¿Qué es la revelación de metadatos?

Es el proceso por el que un proyecto sustituye los metadatos provisionales de los tokens por los definitivos, a menudo actualizando la URI base o la lógica de tokenURI.

¿Cómo puedo comprobar si la URI base de un NFT es segura?

Puedes comprobar el resultado de tokenURI, el tipo de almacenamiento, los permisos de actualización, si el contrato es actualizable, el formato de los metadatos y si los archivos están disponibles mediante un almacenamiento fiable.

Conclusión

La URI base es un concepto clave de metadatos en los contratos de NFT y tokens cripto.

Es la ruta compartida que ayuda a un contrato a crear la URI completa de los metadatos de cada token.

En muchas colecciones ERC-721, la URI base se combina con el ID del token para generar tokenURI.

En ERC-1155, una plantilla de URI que utiliza la sustitución de {id} suele cumplir una función similar.

La URI base facilita y abarata la gestión de grandes colecciones, ya que un único prefijo compartido puede servir para muchos archivos de metadatos de tokens.

También plantea importantes cuestiones de confianza, porque los metadatos suelen estar fuera de la blockchain.

Si la URI base apunta a servidores centralizados, los usuarios dependen de esos servidores y de sus operadores.

Si apunta a almacenamiento con direccionamiento por contenido, puede ofrecer más garantías de integridad, pero sigue siendo necesario que el contenido esté disponible.

Si la URI base puede cambiarse, los usuarios deben confiar en la autoridad de actualización y en sus controles de seguridad.

Si es inmutable, ofrece permanencia, pero reduce la flexibilidad si contiene errores.

Los desarrolladores deben diseñar cuidadosamente la lógica de la URI base antes del lanzamiento, probar a fondo las rutas de los archivos, proteger los permisos de actualización y comunicar claramente si los metadatos pueden modificarse.

Los usuarios deben inspeccionar tokenURI, verificar las direcciones de los contratos, entender el tipo de almacenamiento y no dar por hecho que el contenido multimedia mostrado es automáticamente permanente o de su propiedad legal.

La lección más importante es que la propiedad de un NFT y sus metadatos están relacionados, pero no son lo mismo.

El contrato inteligente demuestra la propiedad del token, mientras que la URI base ayuda a las aplicaciones a encontrar los datos que explican lo que representa.

Un diseño sólido de URI base hace que esa conexión sea estable, transparente y fácil de verificar.

Un diseño deficiente puede convertir un token que parece valioso en un enlace roto, una promesa modificable o un riesgo de seguridad para los metadatos.