@sea-snake, thanks a lot for the detailed write up and for triggering this important discussion. Thought more about it and for me it is clear now that we should go for Option 2 for multiple reasons.
- ICRC-7 has always been intended to be a simple NFT standard, but still it should comprise all necessary functionality, and one of those is dynamic metadata. Not having dynamic metadata in this basic standard would not be true to the idea of a basic standard on ICP, as dynamicity of metadata is one of the key things ICP enables, compared to other chains, where this is much more tedious…
- We are already very close to this simple, yet powerful standard, and explicitly defining the basics for dynamic NFTs is one small missing step to reach that completely.
- People with basic demands for dynamic NFTs will be able to just just ICRC-7/-37, those with more elaborate requirements will implement the full-blown ICRC-60, which is more complex, but also (much) more powerful. But I think we should not force everyone who has basic needs for dynamic NFTs to go for the full ICRC-60 as it’s also much more complex to implement.
Thinking about this more, I need to disagree that both cannot be combined. I think we can have both static and dynamic metadata without any issues. The single Value element can contain a top-level Map which contains a static Value and a dynamic Value, and those Values contain the static and dynamic metadata, respectively. The ledger must never change the static metadata, by can change the dynamic metadata. Having both classes of metadata in one Value should not be constraining. We can make this approach a best practice and make it a SHOULD requirement, so people can still deviate if they want.
Both on minting and update, the full Value MUST be hashed to guarantee full data integrity. This makes the updates to the dynamic parts fully traceable and would detect tampering with the static part.
Ledgers that only have static metadata do not need this, but MAY just go with any Value representation that fits their need, but they MAY also follow this scheme with the dynamic part being empty.
ICRC-3 Block Schema
ICRC-7 needs to extend the block schema with a type=7update for the blocks for updating metadata. This block would contain an element tx defined as follows:
- it MUST contain a field
tx.tidwith the token id - it MUST contain a field
tx.metadatawith the metadata or hash thereof - it MAY contain a field
tx.fromwith an account who initiated the update
The tx.metadata MUST contain the (hash of the) full Value with both static and dynamic metadata in order to have full traceability of changes and prevent static metadata from being tampered with.
Rationale
This approach would be a very simple, yet powerful foundation to build many NFT-based applications. Not doing this imposes an undue constraint that may hamper adoption as people would be forced to go with a much harder-to-implement add-on standard to get dynamic NFT functionality. Those who need it, will still implement the add-on, but not everyone should be forced to do it.
Also conceptually, this approach makes lots of sense because of the ICRC-7 metadata representation using the Value type resembles the ICRC-3 technical Value representation as the most canonical realization of the metadata. Any add-on standards may use more complex representations like ICRC-16 for additional functionality. But those, for whom the simple ICRC-7 representation is sufficient, already get an out-of-the-box solution for their needs without needing to implement a much more complex machinery.
Conclusion
After more thinking about this, I would claim that following Option 2 for supporting dynamic NFT metadata, in addition to static metadata, is the right and natural way to go forward with. It provides a nice and simple framework for NFTs on ICP for many users with simple requirements to dynamic NFTs. People with more elaborate requirements can revert to implementing ICRC-60, which is more more comprehensive.
Let’s discuss this in the Working Group meeting tomorrow!