CIP-0068 | Support multi-asset metadata a la CIP-0025 #1112
Conversation
…tion#1112) Add version 4 metadata support with 721-ERC-style mappings to NFT (222), FT (333) and RFT (444) standards, ensuring consistency across all asset classes. Changes: - Add metadata_field union type supporting both direct and 721-map formats - Add __RESERVE_KEYWORD_721_V4__ marker for 721-style detection - Update retrieval steps to handle both metadata formats - Support version 4 in FT standard - Support version 3/4 in RFT standard - Add 721-style JSON example for NFT standard - Update pattern descriptions with asset_name terminology - Fix URI support to include [* bounded_bytes] for RFT
thaddeusdiamond
force-pushed
the
master
branch
from
fe50df9 to
264170d
Compare
thaddeusdiamond
changed the title
|
@thaddeusdiamond I was answering your comments by subject in alphabetical (not chronological) order, so I posted this response without seeing you've already done the proposed update: I think these changes are consistent with your suggestion of a new best-practice approach, the editorial guidelines, and the requirements of CIP-0068... but we'll follow the related issue in case other feedback indicates that a different approach should be taken. In any case we'll tag this |
rphair
added
Update
rphair
changed the title
|
@thaddeusdiamond I'm recording this meeting resolution to leave this submission |
rphair
added
State: Unconfirmed
|
I think @Crypto2099 was onboard as is since it's backwards compatible but he can comment here. Will close #1111 |
|
@thaddeusdiamond we might not get @Crypto2099's participation on this issue... so if there are any review points you could record here about that conversation please do... otherwise we'll continue on with this without it. If that's the case... @Ryun1 @perturbing if you can recall any other blocking issues to consider this a CIP candidate, perhaps you can post them here? Otherwise we might mark this as |
|
Correct that's the plan.
I've calculated that several of my artists could get a roughly 75% reduction in minUTxO. For a multi-thousand art piece collection this is several hundred to several thousand dollars.
The only problem with that is since the name is part of the reference token itself, you would have to "reprint" the reference tokens instead of making this at the datum level. But I'm open to suggestions.
I would think this would be up to the dApp developer? So long as it conforms to the spec they can either "respend" the datum and rewrite every related token metadata, or they could split it overall.
Consistency issues? This aims to be backwards-compatible with the existing data formats so I'm not sure I'm following. As for the rationale, I'll attach it to the bottom of this comment and you can let me know what/where you want it.
Yes there is no change to SC usage. Since the datum is just "larger" the contract may be slightly more complex, but there is no structural change. This is more on the dApp or SC developer to interpret the datum in a new way. Not sure about Rationale for Introducing Optional CIP-0025-Compatible Metadata Within CIP-0068The current design of CIP-0068 inadvertently creates a significant cost barrier for large NFT collections due to minimum-ADA requirements. As ADA approaches parity with USD, artists and platforms minting 5,000–10,000+ on-chain assets are increasingly impacted by the minUTxO amplification effect: the metadata-bearing reference scripts and datums mandated by CIP-0068 can cause 10–20% of project budgets to be consumed purely by ADA locked in outputs, rather than by art production or ecosystem growth. This cost profile wasn’t as visible when ADA was significantly cheaper, but it has now become an operational friction point across multiple creator workflows. The proposal aims to reduce the minUTxO footprint for CIP-0068 assets by allowing an optional alternate metadata shape that mirrors CIP-0025 (721-style metadata) while preserving CIP-0068’s semantics. Concretely: 1. Dual-format Metadata Reduces Unnecessary ADA LockingAllowing a CIP-0025-shaped metadata payload means:
This addresses a real-world pain point reported by multiple production-level minting pipelines, not just isolated cases. 2. Improved Migration Path from CIP-0025 to CIP-0068A sizeable portion of the ecosystem still lives on CIP-0025, particularly older marketplaces and archived collections. When artists revisit or reissue older collections, the transition path to CIP-0068 is currently friction-heavy, requiring metadata restructuring and toolchain updates. Supporting a CIP-0025-compatible metadata envelope inside CIP-0068:
3. Strict Optionality Preserves Backward CompatibilityThis proposal does not modify or deprecate existing CIP-0068 patterns. This allows:
Why a CIP-0068 Version Bump May Be Preferable to a New CIPAlthough this change is cross-cutting, it:
A versioned update (e.g., v5) avoids fracturing standards, while still being explicit enough for tooling authors and indexers to adopt cleanly. |
|
Thanks. A lot of the confusion came from the fact that you previously didn't introduce the MinUTXO issue at all in your proposal. The introduction was:
Which is why I thought it was about consistency. So it looked like it was trying to solve some metadata issues, but it actually tries to solve some cost and locked ADA issues. This is therefore a work-around for the current value of MinUTXO, quite unrelated to metadata formats. Overall I think comparing to CIP25 is very confusing, and even more "721-ERC". This has almost nothing to do with CIP25:
The only common thing with CIP25 that you introduce is the "policy_id -> asset_name" mapping. The 222/333/444 metadata is then not encoded like CIP25. So given all these differences, I don't think it particularly helps migrating to CIP68. This might instead introduce a lot of errors like in CIP25 v2, where users use strings instead of bytes or mix both versions. Therefore in my opinion this proposal should be introduced without talking about CIP25 at all, but instead just introduce the aim of supporting multiple assets per tx_output and datum. I will add other note in changes comments. |
| This is either: | ||
|
|
||
| 1. A low-level direct representation of the metadata, following closely the structure of CIP-0025 | ||
| 2. A 721-ERC-style token mapping exactly matching the structure of CIP-0025 |
There was a problem hiding this comment.
This is confusing. Why referencing 721-ERC-style here? What does this mean? This is an Ethereum standard and it is not referenced anywhere. The only link with CIP25 is the 721 metadata label.
Also "mapping exactly matching the structure of CIP-0025" is also confusing. I think you are only talking about the policy_id -> asset_name mapping? The rest is different (222/333/444, bytes instead of strings, etc.). Also only CIP25v2 use bytes as keys in the mapping.
Note that "following closely the structure of CIP-0025" was about the individual asset metadata (name, image, files, etc.). Whereas you seem to talk about its encapsulation in policy_id -> asset_name maps.
| } | ||
| } | ||
| } | ||
There was a problem hiding this comment.
This is not some valid CDDL. It looks like you are confusing CDDL with JSON.
More importantly, this does not tell how the policy_id and asset_name keys are encoded (I guess byte encoding like CIP25v2 and all CIP68 fields?).
Overall we should avoid talking about JSON as metadata and datum are CBOR encoded and CBOR -> JSON is not directly bijective. This only leads to confusion.
Note that JSON in CIP68 is only discussed in examples and even this is slightly questionable in my opinion.
| } | ||
| ``` | ||
|
|
||
| Example datum as JSON (721-style): |
There was a problem hiding this comment.
Again what "721-style" means?
| { | ||
| __RESERVE_KEYWORD_721_V4__ : bool, ; Long name to avoid conflict | ||
| "721": |
There was a problem hiding this comment.
What is the point of having __RESERVE_KEYWORD_721_V4__ bool here? Wouldn't the presence of "721" key be enough?
| } | ||
| } | ||
| } | ||
| } | ||
| } | ||
| } | ||
|
|
||
| #### version 4 | ||
|
|
||
| - Add backwards-compatible support for multi-asset 721-ERC-style metadata mappings |
There was a problem hiding this comment.
"Backwards-compatible" with what exactly?
And again "721-ERC-style" is not clear. There is no ERC on Cardano.
I meant introducing a new label instead of reusing 222/333/444. Without doing this, this not fully backward compatible because a current indexer will not expect a version 4. So some new CIP68 token minted as a single asset but with version 4 will be ignored or rejected by such tools. I don't understand what you mean by "you would have to "reprint" the reference tokens". |
I'm not sure there is any choice: assuming there are n tokens in a single tx output with their metadata in the output datum. To update only one of the tokens metadata, you will have to spend all of them, at least as change, but CIP68 metadata lookup is described as:
Note that the lookup only looks at the unspent output (not a previous output). Therefore you will have to rewrite the metadata of all tokens in a datum, hence it makes no sense to split them, it would be even costlier. |
Makes sense. So rewrite it then makes sense to me. |
This is quite a significant drawback compared to current CIP68 and even CIP25 (as only one of the tokens can be minted again to update its metadata), so maybe it's worth thinking more about it to avoid introducing a new flaw? |
If it's an optional capability what's the drawback? I don't know how to solve the minUTxO problem without consolidating the NFT metadata. To give a specific example: one of the artists I am minting for has taken roughly 10,000 ADA in project funds and the locked minUTxO is over 1,000 ADA. So that's 10% of his total funds that are locked and can't contribute to his product development. |
3 participants
Add version 4 metadata support with 721-ERC-style mappings to NFT (222), FT (333) and RFT (444) standards, ensuring consistency across all asset classes.
Changes: