CIP-68: El enfoque de Cardano para el diseño de activos nativos

LeeMaimai

/16 oct 2025

Puntos clave

• CIP-68 permite la gestión de metadatos en la cadena para NFTs y tokens fungibles.

• Los activos nativos de Cardano son tratados como ciudadanos de primera clase, evitando envoltorios innecesarios.

• La implementación de CIP-68 mejora la componibilidad y la transparencia para desarrolladores y usuarios.

• Se introducen tres tipos de tokens para facilitar la actualización y el manejo de metadatos.

• Las características de la era Vasil son fundamentales para la funcionalidad de CIP-68.

Cardano trata los activos nativos como ciudadanos de primera clase a nivel de registro (ledger), evitando envoltorios de contratos al estilo ERC‑20/721 y heredando el mismo modelo de seguridad y tarifas que el ada. Esa elección de diseño hace que la emisión de activos sea eficiente, pero también plantea preguntas prácticas sobre metadatos, mutabilidad, regalías y composabilidad. La Propuesta de Mejora de Cardano CIP‑68 introduce un patrón robusto para los "activos inteligentes": metadatos actualizables en la cadena para NFTs y tokens fungibles que pueden leerse y validarse sin gastar el activo en sí.

Este artículo explica por qué CIP‑68 es importante, cómo funciona y qué desbloquea para constructores y usuarios en todo el ecosistema de Cardano.

Por qué los activos nativos de Cardano son diferentes

A diferencia de las cadenas basadas en cuentas, el registro UTXO extendido (EUTXO) de Cardano te permite acuñar y transferir múltiples activos en el mismo UTXO, rastreados por políticas de acuñación en lugar de contratos específicos de token. Esto proporciona tarifas predecibles y paralelización, manteniendo al mismo tiempo una contabilidad de activos simple a nivel de registro. Para obtener antecedentes, consulta la documentación de Cardano sobre tokens nativos y cómo el modelo EUTXO permite transacciones programables con comportamiento determinista:

Descripción general de activos nativos (Documentos de Cardano) — enlazado al final de este párrafo
Investigación sobre EUTXO y materiales para desarrolladores — enlazado al final de este párrafo

Referencia: lee la documentación oficial sobre tokens nativos en Cardano y el modelo EUTXO en el portal de desarrolladores de Cardano y los blogs de investigación asociados. Visita la documentación oficial a través de Activos nativos y Modelo EUTXO para obtener más información.

El problema con los metadatos heredados (CIP‑25)

Los primeros NFTs de Cardano dependían de indexadores fuera de la cadena y metadatos de transacciones a través de CIP‑25. Si bien es simple, este enfoque:

Dependía de indexadores de terceros para la corrección
Hacía que las actualizaciones fueran incómodas o imposibles
No podía aplicar fácilmente la lógica de regalías en la cadena o el comportamiento con estado

A medida que el ecosistema maduró, los constructores necesitaron un estándar que mantuviera los metadatos y el estado en la cadena, versionados y descubribles de manera confiable sin sacrificar la experiencia del usuario.

Puedes encontrar el enfoque original de metadatos de NFT en CIP‑25 para contexto histórico (referencia al final de esta oración). Consulta la especificación en CIP‑25.

Entra CIP‑68: "activos inteligentes" actualizables en la cadena

CIP‑68 define un patrón para almacenar metadatos y estado dentro de los datums de UTXO, manteniendo al mismo tiempo un token limpio y visible para el usuario. Formaliza una relación entre múltiples tokens acuñados bajo la misma política para separar las preocupaciones:

Un activo visible para el usuario que las personas poseen e intercambian
Un activo de referencia cuya UTXO lleva los metadatos canónicos y versionados en un datum en línea
Un token de estado/hilo opcional para gestionar la mutabilidad o las transiciones de estado

Crucialmente, las billeteras y dApps pueden leer los metadatos del activo de referencia sin consumirlo, y las actualizaciones se realizan gastando y recreando la UTXO de referencia con un nuevo datum. Esto brinda a los proyectos un comportamiento de "NFT inteligente" sin depender de bases de datos fuera de la cadena. Lee el estándar en CIP‑68.

Por qué las características de la era Vasil son importantes: entradas de referencia, datums en línea y scripts de referencia

CIP‑68 aprovecha tres mejoras de la era Vasil que hicieron que los metadatos en la cadena fueran prácticos y rentables:

CIP‑31 Entradas de referencia: lee datos de una UTXO en una transacción sin gastarla, ideal para consultar la UTXO de metadatos de un NFT de referencia. Ver CIP‑31.
CIP‑32 Datums en línea: almacena el datum directamente en la UTXO, permitiendo metadatos canónicos en la cadena sin búsquedas externas. Ver CIP‑32.
CIP‑33 Scripts de referencia: adjunta scripts a las UTXO y refiérete a ellos para validación, reduciendo el tamaño de las transacciones y los costos al interactuar repetidamente con el mismo script. Ver CIP‑33.

Estas características juntas permiten un acceso de lectura de bajo costo y componible a metadatos y estado, evitando cambios innecesarios en la UTXO.

El patrón de tres tokens en la práctica

Si bien las implementaciones varían, una implementación típica de CIP‑68 se ve así:

Token de usuario (el activo comercializable): lo que los usuarios ven en sus billeteras y mercados.
Token de referencia (no comercializable o propiedad del protocolo): ancla los metadatos canónicos en un datum en línea; los indexadores y las dApps leen de esta UTXO a través de entradas de referencia.
Token de hilo de estado (opcional): gobierna las actualizaciones, impone la unicidad o transporta el estado programático para casos de uso como arte dinámico, credenciales, posiciones o elementos de juego.

CIP‑68 también fomenta la versionado de esquemas para datums, de modo que los metadatos puedan evolucionar sin romper a los consumidores. El resultado es una fuente de verdad versionada en la cadena que cualquier dApp puede consultar de manera consistente.

Puedes explorar la especificación formal y los esquemas recomendados en CIP‑68.

Lo que obtienen los constructores

Componibilidad: las dApps pueden confiar en una única fuente de metadatos en la cadena y consumirla sin gastar el activo, lo que permite integraciones fluidas en mercados, protocolos DeFi y juegos.
Actualizabilidad con transparencia: los datums en la cadena son auditables; los proyectos pueden publicar políticas de cambio, bloqueos de tiempo o requisitos de multisig en torno a las actualizaciones.
Mejor indexación: los indexadores ya no necesitan conciliar metadatos fuera de la cadena con activos visibles para el usuario; pueden seguir la relación definida por la política y el esquema del datum.
Regalías y reglas de política: si bien las regalías no se aplican a nivel de registro, CIP‑68 se combina bien con la lógica de política y las convenciones del mercado para honrar la intención del creador. Para convenciones de regalías, ver CIP‑27.

Consulta la convención de regalías en CIP‑27.

Lo que obtienen los usuarios

Metadatos deterministas: las billeteras pueden mostrar los mismos datos que las dApps y los exploradores leen de la UTXO de referencia.
Menor fricción: las actualizaciones de obras de arte, atributos o estado ya no requieren reagrupaciones incómodas o coordinación fuera de la cadena.
Modelo de confianza más claro: los proyectos pueden revelar si los metadatos son mutables, quién puede actualizarlos y bajo qué condiciones.

Como siempre, verifica los ID de política e inspecciona los metadatos de exploradores de buena reputación antes de interactuar con activos desconocidos. Puedes verificar políticas y transacciones utilizando exploradores de Cardano como Cardanoscan.

Casos de uso prácticos

NFTs dinámicos: obras de arte en evolución, pases de temporada o artículos de juego cuyos atributos cambian con el tiempo.
Credenciales y artefactos estilo SBT: insignias con mecánicas de revocación o actualización impulsadas por un token de estado.
Posiciones DeFi: acciones de LP o recibos de bóveda que transportan el estado de la posición en el datum, mientras que el token de usuario sigue siendo comercializable cuando corresponde.
Activos del mundo real: procedencia y atestaciones almacenadas en la cadena de manera versionada y auditable.

Consejos y mejores prácticas para desarrolladores

Adopta esquemas de datums claros y versionados y documéntalos públicamente para que las billeteras y los indexadores puedan integrarse rápidamente.
Señala la mutabilidad: si los metadatos pueden cambiar, hazlo explícito y explica la gobernanza (por ejemplo, firmantes de multisig, bloqueos de tiempo o aprobaciones de DAO).
Utiliza scripts de referencia y entradas de referencia para minimizar las tarifas y los cambios de UTXO.
Evita una complejidad de estado innecesaria; mantén la UX del token de usuario simple y rápida de transferir.
Considera combinar CIP‑68 con bloqueos de tiempo o bloqueos de política una vez que se finalicen las reglas de la colección.

Para las características subyacentes que hacen que este patrón sea eficiente, consulta CIP‑31, CIP‑32 y CIP‑33.

Perspectivas para 2025

A medida que Cardano continúa evolucionando hacia la era Conway con bases de gobernanza en la cadena como CIP‑1694, los estándares que mejoran la expresividad y la componibilidad de los activos solo crecerán en importancia para las dApps y los ecosistemas asociados. La gobernanza y las actualizaciones del protocolo pueden fortalecer las garantías en torno a la mutabilidad, la procedencia y los metadatos a largo plazo para casos de uso tokenizados del mundo real. Para obtener antecedentes sobre gobernanza, lee CIP‑1694.

Consideraciones de seguridad y billetera

Los activos CIP‑68 dependen de UTXO de referencia y datums en línea. Al firmar transacciones:

Revisa las políticas de acuñación de la transacción y cualquier script que se esté referenciando.
Prefiere billeteras que muestren ID de política, datums y metadatos claros de activos obtenidos en la cadena.
Almacena las tenencias a largo plazo en almacenamiento en frío y utiliza la firma de hardware para reducir la exposición de claves.

Si operas una cartera multichain que incluye tokens nativos de Cardano, una billetera de hardware de código abierto como OneKey puede servir como el ancla de firma sin conexión en tu pila. OneKey se centra en un firmware transparente y fácil de auditar y en flujos seguros sin conexión, lo que te ayuda a mantener las claves privadas fuera de los dispositivos conectados a Internet mientras interactúas con dApps a través de billeteras de software compatibles.