# Align token metadata in ICRC-7 with ICRC-3 history blocks **URL:** \ **Category:** Developers\ **Created:** [March 8, 2024, 11:52am UTC](https://forum.dfinity.org/t/align-token-metadata-in-icrc-7-with-icrc-3-history-blocks/28243 "2024-03-08T11:52:53Z")\ **Posts on this page:** 1\ **Showing post:** 5
**Author:** ![dieter.sommer](https://avatars.discourse-cdn.com/v4/letter/d/b487fb/32.png) [@dieter.sommer](https://forum.dfinity.org/u/dieter.sommer)\ **Post date:** [March 11, 2024, 10:39am UTC](https://forum.dfinity.org/t/align-token-metadata-in-icrc-7-with-icrc-3-history-blocks/28243/5 "2024-03-11T10:39:32Z")
@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. > [@sea-snake](#): > > This would mean though that a ledger can only have static or dynamic token metadata but not both. 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 `Value`s 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.tid` with the token id - it MUST contain a field `tx.metadata` with the metadata or hash thereof - it MAY contain a field `tx.from` with 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! --- _[View the full topic](https://forum.dfinity.org/t/align-token-metadata-in-icrc-7-with-icrc-3-history-blocks/28243)._