CIP-68: Abordagem da Cardano para o design de ativos nativos

Principais Resultados
• A CIP-68 permite metadados atualizáveis na cadeia para NFTs e tokens fungíveis.
• O modelo EUTXO da Cardano facilita a emissão e transferência de múltiplos ativos de forma eficiente.
• A nova abordagem elimina a dependência de indexadores externos, proporcionando uma experiência de usuário mais fluida.
• A CIP-68 promove a composibilidade e a transparência nas atualizações de metadados.
• Os desenvolvedores podem implementar um padrão de três tokens para gerenciar ativos de forma eficaz.
A Cardano trata os ativos nativos como cidadãos de primeira classe no nível do ledger, evitando "wrappers" de contrato no estilo ERC-20/721 e herdando o mesmo modelo de segurança e taxas do ada. Essa escolha de design torna a emissão de ativos eficiente, mas também levanta questões práticas sobre metadados, mutabilidade, royalties e composibilidade. A Proposta de Melhoria da Cardano (CIP) 68 introduz um padrão robusto para "ativos inteligentes": metadados atualizáveis na cadeia para NFTs e tokens fungíveis que podem ser lidos e validados sem consumir o próprio ativo.
Este artigo explica por que a CIP-68 é importante, como ela funciona e o que ela desbloqueia para construtores e usuários em todo o ecossistema Cardano.
Por que os ativos nativos da Cardano são diferentes
Ao contrário das cadeias baseadas em contas, o ledger UTXO estendido (EUTXO) da Cardano permite cunhar e transferir múltiplos ativos no mesmo UTXO, rastreados por políticas de cunhagem em vez de contratos específicos de token. Isso fornece taxas previsíveis e paralelismo, mantendo a contabilidade de ativos simples na camada do ledger. Para um contexto mais aprofundado, consulte a documentação da Cardano sobre tokens nativos e como o modelo EUTXO permite transações scriptáveis com comportamento determinístico:
- Visão geral de ativos nativos (Documentos Cardano) — link no final deste parágrafo
- Pesquisa EUTXO e materiais para desenvolvedores — link no final deste parágrafo
Referência: leia os documentos oficiais sobre tokens nativos na Cardano e o modelo EUTXO no portal do desenvolvedor Cardano e blogs de pesquisa associados. Visite a documentação oficial através de Ativos Nativos e Modelo EUTXO para saber mais.
O problema com metadados legados (CIP-25)
Os primeiros NFTs da Cardano dependiam de indexadores fora da cadeia e metadados de transação via CIP-25. Embora simples, essa abordagem:
- Dependia de indexadores de terceiros para correção
- Tornava as atualizações incômodas ou impossíveis
- Não conseguia impor facilmente lógica de royalties na cadeia ou comportamento stateful
À medida que o ecossistema amadureceu, os construtores precisavam de um padrão que mantivesse metadados e estado na cadeia, versionado e confiavelmente descoberto sem sacrificar a experiência do usuário.
Você pode encontrar a abordagem original de metadados de NFT na CIP-25 para contexto histórico (referência no final desta frase). Veja a especificação na CIP-25.
Entra a CIP-68: "ativos inteligentes" na cadeia e atualizáveis
A CIP-68 define um padrão para armazenar metadados e estado dentro de "datums" de UTXO, mantendo um token limpo e voltado para o usuário. Formaliza uma relação entre múltiplos tokens cunhados sob a mesma política para separar preocupações:
- Um ativo voltado para o usuário que as pessoas possuem e negociam
- Um ativo de referência cuja UTXO carrega os metadados canônicos e versionados em um "inline datum";
- Um token de estado/thread opcional para gerenciar mutabilidade ou transições de estado
Crucialmente, carteiras e dApps podem ler os metadados do ativo de referência sem consumi-lo, e as atualizações são realizadas gastando e recriando o UTXO de referência com um novo "datum". Isso dá aos projetos comportamento de "NFT inteligente" sem depender de bancos de dados fora da cadeia. Leia o padrão na CIP-68.
Por que os recursos da era Vasil são importantes: entradas de referência, "inline datums" e scripts de referência
A CIP-68 utiliza três melhorias da era Vasil que tornaram os metadados na cadeia práticos e econômicos:
- CIP-31 Entradas de Referência: lê dados de uma UTXO em uma transação sem gastá-la, ideal para consultar a UTXO de metadados de um NFT de referência. Veja a CIP-31.
- CIP-32 "Inline Datums": armazena o "datum" diretamente na UTXO, permitindo metadados canônicos na cadeia sem consulta externa. Veja a CIP-32.
- CIP-33 Scripts de Referência: anexa scripts a UTXOs e os referencia para validação, reduzindo o tamanho da transação e os custos ao interagir com o mesmo script repetidamente. Veja a CIP-33.
Esses recursos juntos permitem acesso de leitura de baixo custo e componível a metadados e estado, evitando "churn" (agitação) desnecessário de UTXOs.
O padrão de três tokens na prática
Embora as implementações variem, uma implantação típica da CIP-68 se parece com isto:
- Token do usuário (o ativo negociável): o que os usuários veem em suas carteiras e marketplaces.
- Token de referência (não negociável ou mantido pelo protocolo): ancora os metadados canônicos em um "inline datum"; indexadores e dApps leem desta UTXO via entradas de referência.
- Token de thread de estado (opcional): governa atualizações, impõe unicidade ou carrega estado programático para casos de uso como arte dinâmica, credenciais, posições ou itens de jogo.
A CIP-68 também incentiva o versionamento de esquemas para "datums", para que os metadados possam evoluir sem quebrar os consumidores. O resultado é uma fonte de verdade versionada e na cadeia que qualquer dApp pode consultar de forma consistente.
Você pode explorar a especificação formal e os esquemas recomendados na CIP-68.
O que os construtores obtêm
- Composibilidade: dApps podem confiar em uma única fonte de metadados na cadeia e consumi-la sem gastar o ativo, permitindo integrações perfeitas em marketplaces, protocolos DeFi e jogos.
- Atualizabilidade com transparência: "datums" na cadeia são auditáveis; projetos podem publicar políticas de alteração, "timelocks" ou requisitos de multi-assinatura em torno de atualizações.
- Melhor indexação: indexadores não precisam mais reconciliar metadados fora da cadeia com ativos voltados para o usuário; eles podem seguir a relação definida pela política e o esquema do "datum".
- Royalties e regras de política: embora os royalties não sejam impostos no nível do ledger, a CIP-68 combina bem com a lógica de política e convenções de marketplace para honrar a intenção do criador. Para convenções de royalties, veja a CIP-27.
Referencie a convenção de royalties na CIP-27.
O que os usuários obtêm
- Metadados determinísticos: carteiras podem exibir os mesmos dados que dApps e exploradores leem da UTXO de referência.
- Menos atrito: atualizações de arte, atributos ou estado não exigem mais "re-minting" (re-cunhagem) incômodo ou coordenação fora da cadeia.
- Modelo de confiança mais claro: projetos podem divulgar se os metadados são mutáveis, quem pode atualizá-los e sob quais condições.
Como sempre, verifique os IDs de política e inspecione os metadados de exploradores confiáveis antes de interagir com ativos desconhecidos. Você pode verificar políticas e transações usando exploradores Cardano como o Cardanoscan.
Casos de uso práticos
- NFTs Dinâmicos: arte evolutiva, passes de temporada ou itens de jogo cujos atributos mudam ao longo do tempo.
- Credenciais e artefatos estilo SBT: distintivos com mecanismos de revogação ou atualização impulsionados por um token de estado.
- Posições DeFi: ações de LP ou recibos de cofre que carregam o estado da posição no "datum", enquanto o token do usuário permanece negociável quando apropriado.
- Ativos do mundo real: proveniência e atestações armazenadas na cadeia de forma versionada e auditável.
Dicas e melhores práticas para desenvolvedores
- Adote esquemas de "datum" claros e versionados e documente-os publicamente para que carteiras e indexadores possam integrar rapidamente.
- Sinalize a mutabilidade: se os metadados puderem mudar, torne isso explícito e explique a governança (por exemplo, signatários de multi-assinatura, "timelocks" ou aprovações de DAO).
- Use scripts de referência e entradas de referência para minimizar taxas e "churn" de UTXO.
- Evite complexidade de estado desnecessária; mantenha a UX do token do usuário simples e rápida para transferir.
- Considere combinar a CIP-68 com "time locks" ou bloqueio de política assim que as regras da coleção forem finalizadas.
Para os recursos subjacentes que tornam este padrão eficiente, veja a CIP-31, CIP-32 e CIP-33.
Perspectiva para 2025
À medida que a Cardano continua a evoluir para a era Conway com fundamentos de governança na cadeia como a CIP-1694, padrões que melhoram a expressividade e a composibilidade de ativos só crescerão em importância para dApps e ecossistemas parceiros. A governança e as atualizações de protocolo podem fortalecer as garantias em torno da mutabilidade, proveniência e metadados de longa duração para casos de uso de ativos tokenizados do mundo real. Para contexto de governança, leia a CIP-1694.
Considerações de segurança e carteira
Ativos CIP-68 dependem de UTXOs de referência e "inline datums". Ao assinar transações:
- Revise as políticas de cunhagem da transação e quaisquer scripts que estejam sendo referenciados.
- Prefira carteiras que exibam IDs de política, "datums" e metadados de ativos claros obtidos na cadeia.
- Armazene participações de longo prazo em armazenamento frio e use assinatura de hardware para reduzir a exposição de chaves.
Se você opera um portfólio multi-cadeia que inclui tokens nativos da Cardano, uma carteira de hardware de código aberto como a OneKey pode servir como âncora de assinatura offline em sua pilha. A OneKey se concentra em firmware transparente e auditável e fluxos offline seguros, ajudando você a manter as chaves privadas fora de dispositivos conectados à internet enquanto interage com dApps através de carteiras de software compatíveis.
Referências
- CIP-68: Smart NFTs on Cardano https://github.com/cardano-foundation/CIPs/blob/master/CIP-0068/README.md
- Native assets (Cardano Docs) https://docs.cardano.org/native-tokens/
- CIP-25: NFT metadata standard (legacy) https://github.com/cardano-foundation/CIPs/blob/master/CIP-0025/README.md
- CIP-27: Royalty specification (convention) https://github.com/cardano-foundation/CIPs/blob/master/CIP-0027/README.md
- CIP-31: Reference Inputs https://github.com/cardano-foundation/CIPs/blob/master/CIP-0031/README.md
- CIP-32: Inline Datums https://github.com/cardano-foundation/CIPs/blob/master/CIP-0032/README.md
- CIP-33: Reference Scripts https://github.com/cardano-foundation/CIPs/blob/master/CIP-0033/README.md
- CIP-1694: On-chain governance foundations https://github.com/cardano-foundation/CIPs/blob/master/CIP-1694/README.md
- Cardanoscan (explorer) https://cardanoscan.io/






