# Approaches to ICRC-7 NFT User Facing Metadata

**URL:** <https://forum.dfinity.org/t/approaches-to-icrc-7-nft-user-facing-metadata/42884>\
**Category:** Tokenization\
**Tags:** Discussing, community-consideration\
**Created:** [March 22, 2025, 1:55pm UTC](https://forum.dfinity.org/t/approaches-to-icrc-7-nft-user-facing-metadata/42884 "2025-03-22T13:55:51Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![sea-snake](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/sea-snake/32/7243_2.png) [@sea-snake](https://forum.dfinity.org/u/sea-snake)\
**Post date:** [March 22, 2025, 1:55pm UTC](https://forum.dfinity.org/t/approaches-to-icrc-7-nft-user-facing-metadata/42884/1 "2025-03-22T13:55:51Z")

</div>

We identified three approaches for handling ICRC-7 NFT user facing metadata, each with distinct trade-offs in terms of interoperability, simplicity, and on-chain accessibility.

* * *

## 1. On-Chain ICRC-3 Metadata (Structured Fields)

This approach involves defining metadata directly within ICRC-3 fields, allowing canisters to access key information without additional fetching or parsing.

### Pros:

- **Direct Access** : Simplifies on-chain metadata retrieval (e.g., image URLs), as canisters can access the data directly.
- **Efficient Processing** : Avoids the overhead and complexity of fetching and parsing JSON.

### Cons:

- **Limited Interoperability** : Incompatible with NFT metadata standards from other blockchains.
- **Cross-Chain Maintenance** : Cross-chain collections would need metadata mapping, leading to additional storage and maintenance overhead.
- **Tooling Gaps** : Existing NFT tools won’t work out-of-the-box, and new IC-specific tools would need to be developed.
- **Wallet Complexity** : Cross-chain wallets would need to implement custom IC logic to handle the metadata format.

* * *

## 2. URL-Based JSON Metadata

In this approach, metadata consists of a URL pointing to a JSON file, which follows common NFT metadata standards used across multiple ecosystems.

### Pros:

- **Cross-Chain Compatibility** : Aligns with existing NFT metadata standards, enabling seamless integration with other blockchains.
- **Tooling Reuse** : Leverages existing NFT tools, wallets, and marketplaces, simplifying NFT creation on the IC.
- **Metadata Reusability** : Cross-chain collections can reuse the same metadata across different chains.
- **Simpler Wallet Integration** : Wallets can adopt IC-based NFTs without needing special implementations.

### Cons:

- **Indirect Access** : Canisters must fetch and parse the JSON file to access metadata, adding some overhead and complexity.
- **Potential Off-Chain Risks** : If not implemented properly, metadata may be stored off-chain (e.g., via centralized servers), unless decentralized alternatives like DATA URLs, ICRC-91 URLs, or IPFS are used.

* * *

## 3. Hybrid Approach (Supporting Both Formats)

This approach combines on-chain structured metadata with URL-based JSON, giving developers the flexibility to choose the format that best suits their needs.

### Pros:

- **Flexible Metadata Options** : Developers can optimize metadata for either on-chain access or cross-chain compatibility, depending on their use case.

### Cons:

- **Increased Complexity** : Wallets, marketplaces, and dapps must support and manage two metadata formats.
- **Canister Overhead** : Canisters that process metadata may need to handle both formats or risk being incompatible with certain collections.

* * *

## Summary

The right metadata approach depends on how the data is primarily consumed:

- **On-Chain Metadata (ICRC-3 Structured Fields)**: Best for collections where canisters need direct, efficient access to metadata.
- **URL-Based JSON Metadata** : More practical for most cases, offering better compatibility with external ecosystems and existing tools.

## Current Working Group Recommendation

After evaluating the pros and cons, we believe that **URL-based JSON metadata** offers the best balance of flexibility, cross-chain compatibility, and tooling reuse for most NFT use cases.

To minimize the risks of off-chain storage, developers can adopt the following decentralized solutions:

- **Recommended Basic Canister Approach:**  
Embed JSON metadata directly within the URL using a **DATA URI** to keep it fully on-chain and easily accessible.

- **Recommended Advanced Multi-Canister Approach:**  
Store JSON metadata on the same canister or another canister, certified and served over HTTPS. The ICRC-91 standard basically removes the `ic0.app`/`icp0.io` part from the URL, improving decentralization and flexibility.

- **Recommended for Bringing NFTs from Other Chains**  
Store metadata on IPFS, a common decentralized file system, to facilitate interoperability with NFTs from other blockchains.

### Handling Canister-Specific Metadata:

If canisters need direct access to collection-specific metadata (e.g., a game character’s level), developers can implement alternative entries with that data. These items should be namespaced to keep the global namespace clean and MAY be defined as alternative ICRCs.

```candid
vec {
    record {
        "icrc97:metadata"; 
        variant { Array = vec {
            variant { Text = "data:text/json;charset=utf-8;base64,ew0KICAgImtleSIgOiAidmFsdWUiDQp9" };
        }; };
    };
    record {
        "com.mygame.namespace";
        variant { Map = vec {
            vec {
                "level";
                variant { Nat = 6; };
            };
            vec {
                "name";
                variant { Text = "Rathgar the Wise" };
            };
            vec {
                "inventory";
                variant { Array = vec {
                    variant { Text = "Cooking Pot" };
                    variant { Text = "Asparagus" };
                    variant { Text = "Hot Chocolate" };
                }; };
            };
        }; };
    }
}

```

## Notes

Please see below notes that further details our current viewpoint and approach:

- Initially we considered the hybrid approach to cover all use cases.

- Trying to define a metadata standards that covers all use cases is a big goal but is likely to result in a standard that falls short for each individual use case.

- Interoperability with other chains and cross-chain wallets was an important requirement to make sure NFTs on the IC would gain more and wider adoption.

- Immutability, dynamic and other metadata topics are interesting and should definitely be covered.

## Join the discussion

Respond in this thread to join the discussion, additionally there’s the Tokenization WG meeting every other Tuesday.

**Feedback:**

- Disagree with our viewpoint? Awesome, share your thoughts so we can find the right approach!
- Agree with our viewpoint? Let us know your support by liking this post or commenting below.

**Technical discussion:**

- Are there other better approaches we’ve missed?
- What metadata fields and values do we need? Do we follow existing standards? Which one?
- Input and discussions regarding technical details is highly appreciated.

> **Example** : Are multiple URLs (fallbacks) needed and what is the risk of data being different between these URLs?

---

<div class="post-metadata">

**Author:** ![filharvey](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/filharvey/32/6940_2.png) [@filharvey](https://forum.dfinity.org/u/filharvey)\
**Post date:** [March 22, 2025, 2:43pm UTC](https://forum.dfinity.org/t/approaches-to-icrc-7-nft-user-facing-metadata/42884/2 "2025-03-22T14:43:44Z")

</div>

Also with the metadata, do any of the options allow for dynamic updating of the data at any time.

This possibly includes updating of the image provided with them as well.

---

<div class="post-metadata">

**Author:** ![sea-snake](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/sea-snake/32/7243_2.png) [@sea-snake](https://forum.dfinity.org/u/sea-snake)\
**Post date:** [March 22, 2025, 2:55pm UTC](https://forum.dfinity.org/t/approaches-to-icrc-7-nft-user-facing-metadata/42884/3 "2025-03-22T14:55:26Z")

</div>

Yes, all of the options allow for updating of the metadata.

Though with option 1, there’s no possibility to have this metadata on another canister (e.g. game canister that rapidly updates a game character experience points).

To keep track of metadata updates, the `7update_token` block type defined in ICRC-7 standard could be used.

In case ICRC-91 URLs are used, they should ideally contain a hash of their contents to make sure they’re tied tot the ICRC-7 metadata updates. This is already the case for IPFS urls as I’ve mentioned above.

---

<div class="post-metadata">

**Author:** ![skilesare](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/skilesare/32/5609_2.png) [@skilesare](https://forum.dfinity.org/u/skilesare)\
**Post date:** [March 22, 2025, 4:26pm UTC](https://forum.dfinity.org/t/approaches-to-icrc-7-nft-user-facing-metadata/42884/4 "2025-03-22T16:26:50Z")

</div>

> [@filharvey](#):
>
> Also with the metadata, do any of the options allow for dynamic updating of the data at any time.
> 
> This possibly includes updating of the image provided with them as well.

If you’d like a preview of a more explicit static/dynamic nft metadata standards, see [NFT Working Group - Next Steps - ICRC-8, ICRC-56, ICRC-59, ICRC-60](https://forum.dfinity.org/t/nft-working-group-next-steps-icrc-8-icrc-56-icrc-59-icrc-60/27698) for ICRC-59 and ICRC-60. These desperately need to be updated and streamlined, but they are generally in the right direction.

The idea here is that for WALLETs you would always want the ICRC-97 entry as it will be the most direct to implement. For other kinds of applications you would ADD the ICRC-59 or ICRC-60 entry to augment it for applications that want to handle processing static or dynamic data on-chain by other canisters. Similar to the example given with com.mygame.namespace above but with ICRC-59 or 60 fields.

I’d expect 59 to end up with something along the lines of “icrc59:isStatic”, #Text(“true”) to flag that the data in the icrc97 will never change.

---

<div class="post-metadata">

**Author:** ![filharvey](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/filharvey/32/6940_2.png) [@filharvey](https://forum.dfinity.org/u/filharvey)\
**Post date:** [March 22, 2025, 6:54pm UTC](https://forum.dfinity.org/t/approaches-to-icrc-7-nft-user-facing-metadata/42884/5 "2025-03-22T18:54:15Z")

</div>

Thanks I will be checking all of these out, as my game is neary ready for playtest. Once it is at that stage, I will be looking at NFT integration and will be starting with ICRC-7, and will look at all the other standard which could help it.

Currently I’m thinking having the meta data on a **URL-Based JSON Metadata** would be best for the game. But will need to check into it more.

---

<div class="post-metadata">

**Author:** ![Joey\_ICP](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/joey_icp/32/17389_2.png) [@Joey\_ICP](https://forum.dfinity.org/u/Joey_ICP)\
**Post date:** [March 22, 2025, 8:09pm UTC](https://forum.dfinity.org/t/approaches-to-icrc-7-nft-user-facing-metadata/42884/6 "2025-03-22T20:09:20Z")

</div>

Just wanted to give my input here. From my experience I believe URL-Based JSON Metadata would be the best option. We should try to align ourselves with industry standards rather than trying to reinvent things which already work quite well elsewhere. There is a “risk” that data may be stored off-chain, but this should be at the discretion of the creators of NFTs, and it should be up to the community to demand on-chain or immutable data if that is what they desire.

As for metadata fields, I absolutely insist on a **thumbnail** field. When building Cubetopia, we wanted to allow players to users to place their NFTs within our 3D game world. However, many ICP collections (particularly a few years ago) simply link to a HTML page, meaning that it was not possible to get an image suitable for use in our application. The workaround we had to settle on was an off-chain microservice which would render these NFTs in chrome, before taking a screenshot and returning it to the game. In hindsight, its a ridiculous workaround which would be totally avoided if creators were required to add a JPEG thumbnail, as is the standard on other chains. This is an amusing and perhaps unusual circumstance, but the principle would apply to many other applications that integrate and display NFTs.

> **[Metadata Standards](https://docs.opensea.io/docs/metadata-standards)**
>
> How to add rich metadata to your ERC721 or ERC1155 NFTs

The opensea metadata standards probably cover most use cases, but maybe others have suggestions for what additional fields should be added?

---

<div class="post-metadata">

**Author:** ![skilesare](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/skilesare/32/5609_2.png) [@skilesare](https://forum.dfinity.org/u/skilesare)\
**Post date:** [March 22, 2025, 10:11pm UTC](https://forum.dfinity.org/t/approaches-to-icrc-7-nft-user-facing-metadata/42884/7 "2025-03-22T22:11:27Z")

</div>

My understanding is that the idea is that either the data-uri or the Itemm pointed to would most likely be openSea standard. The nice feature of this setup is that it allows -BOTH- a standard current-nft standard in the icrc-97 field and allows you to add other metadata standards that may come along if you want to do something else possibly useful or something custom.

Unfortunately, unless I’m missing it, the openSea standard doesn’t have a thumbnail field. You could I guess use the attributes to put a link in there, but it would be unlikely to be standard. As absurd as it sounds the thing you mentioned about snapshotting and caching is precisely what most NFT marketplaces do today because, well, the existing ‘standards’ are barely standards, vary widely, and just don’t get the job done for full feature dynamic, professional nft that would be far better than today’s version of it.

…so we try to facilitate both.

You can see here in 59 we try to provide a specific preview endpoint, and experience endpoint(for web page or dapp), as well as a generic specification so if you want to deal with all the different sizes and flavors that someone like apple asks you to have for logos and what not you can include all of those pre rendered for your users: [ICRC/ICRCs/ICRC-59 at icrc59and60 · skilesare/ICRC · GitHub](https://github.com/skilesare/ICRC/tree/icrc59and60/ICRCs/ICRC-59#optional-metadata-fields) so that you can load in things like icrc59:resource:ios:20x20 and have all kinds of different sizes and/or representations at different sizes.

That system could potentially handle all this craziness:

### 📱 iPhone Icons

| Icon Use | Size (pt) | Scale | Size (px) |
| --- | --- | --- | --- |
| App Icon (iPhone) | 60×60 | @2x | 120×120 |
| | 60×60 | @3x | 180×180 |
| Spotlight | 40×40 | @2x | 80×80 |
| | 40×40 | @3x | 120×120 |
| Settings | 29×29 | @2x | 58×58 |
| | 29×29 | @3x | 87×87 |
| Notification | 20×20 | @2x | 40×40 |
| | 20×20 | @3x | 60×60 |

* * *

### 📱 iPad Icons

| Icon Use | Size (pt) | Scale | Size (px) |
| --- | --- | --- | --- |
| App Icon (iPad) | 76×76 | @1x | 76×76 |
| | 76×76 | @2x | 152×152 |
| App Icon (iPad Pro) | 83.5×83.5 | @2x | 167×167 |
| Spotlight | 40×40 | @1x | 40×40 |
| | 40×40 | @2x | 80×80 |
| Settings | 29×29 | @1x | 29×29 |
| | 29×29 | @2x | 58×58 |
| Notification | 20×20 | @1x | 20×20 |
| | 20×20 | @2x | 40×40 |

* * *

### 🛍 App Store Icon (Required)

| Icon Use | Size (px) |
| --- | --- |
| App Store Icon | 1024×1024 |

- This icon **should not have any transparency**.
- Used for display in the App Store.

* * *

### ⌚ Apple Watch Icons (optional, if supporting watchOS)

| Icon Use | Size (pt) | Scale | Size (px) |
| --- | --- | --- | --- |
| Notification Center | 24×24 | @2x | 48×48 |
| | | @3x | 72×72 |
| Companion Settings | 29×29 | @2x | 58×58 |
| | | @3x | 87×87 |
| Home Screen Icon | 40×40 | @2x | 80×80 |
| | | @3x | 120×120 |
| Long-Look Notification | 44×44 | @2x | 88×88 |
| | | @3x | 132×132 |
| App Icon (App Launcher) | 86×86 | @2x | 172×172 |
| | 98×98 | @2x | 196×196 |

* * *

### 🧾 Quick Summary of Most Common iOS App Icon Sizes

| Use Case | Size (px) |
| --- | --- |
| iPhone App | 180×180 |
| iPad App | 167×167 |
| App Store | 1024×1024 |
| Notification | 60×60 |
| Settings | 87×87 |
| Spotlight | 120×120 |

---

<div class="post-metadata">

**Author:** ![Joey\_ICP](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/joey_icp/32/17389_2.png) [@Joey\_ICP](https://forum.dfinity.org/u/Joey_ICP)\
**Post date:** [March 22, 2025, 10:40pm UTC](https://forum.dfinity.org/t/approaches-to-icrc-7-nft-user-facing-metadata/42884/8 "2025-03-22T22:40:02Z")

</div>

Ah, on second look I see that you’re right. I think going by the OpenSea standard we would use the `image` property for an image, and then use `animation_url` to link to the multimedia (for example: [BTC Flower](https://n6au6-3aaaa-aaaae-qaaxq-cai.raw.ic0.app/1426.svg) and [Cubetopia Pets](https://mxmzj-5iaaa-aaaah-ace5q-cai.raw.ic0.app/?pet=1913)) which would resolve the issue I was mentioning. As long as we can represent all NFTs with an image, I’ll be happy, and it’ll no doubt save many headaches!

IRC59 looks interesting though, that certainly takes things a lot further!

---

<div class="post-metadata">

**Author:** ![skilesare](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/skilesare/32/5609_2.png) [@skilesare](https://forum.dfinity.org/u/skilesare)\
**Post date:** [March 23, 2025, 12:05am UTC](https://forum.dfinity.org/t/approaches-to-icrc-7-nft-user-facing-metadata/42884/9 "2025-03-23T00:05:24Z")

</div>

59 and 60 take a specific approach of allowing multi asset NFTs with extensive(sometimes multi-party) data apps(or data regions) that can be given to specific principals for maintenance and updating. It is roughly based on the Origyn\_nft standard and allows for things like keeping service records in the digital twin of your car, or a whole game in an NFT. The Origyn nft even had a way others to put entire Dapps into your NFT that could interact with the data stored there. I need to get back to refactoring them.

---

<div class="post-metadata">

**Author:** ![EpicICP](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/epicicp/32/17433_2.png) [@EpicICP](https://forum.dfinity.org/u/EpicICP)\
**Post date:** [March 24, 2025, 4:32pm UTC](https://forum.dfinity.org/t/approaches-to-icrc-7-nft-user-facing-metadata/42884/10 "2025-03-24T16:32:02Z")

</div>

I love this discussion. I am strongly in favor of option #1 because it allows developers in the ICP space to innovate and disrupt the NFT space going forward.

That said, backwards compatibility is valuable and devs should have the option to become compliant with existing standards. However, we don’t want to allow existing standards to place limits on ICP developers.

I believe ICP can only win in the marketplace when it innovates, and that requires a bit of freedom beyond established standards. In the future, ICP will have wallets that bridge the gaps in standards. But if we place limitations on ourselves, then we will fail to innovate.

Thoughts?

---

<div class="post-metadata">

**Author:** ![sea-snake](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/sea-snake/32/7243_2.png) [@sea-snake](https://forum.dfinity.org/u/sea-snake)\
**Post date:** [March 24, 2025, 5:02pm UTC](https://forum.dfinity.org/t/approaches-to-icrc-7-nft-user-facing-metadata/42884/11 "2025-03-24T17:02:34Z")

</div>

To clarify, option 2 would not limit wallet and marketplace developers specifically since they’re not likely reading metadata fields on-chain specifically. Instead both would likely read this metadata from a frontend to display it to a user.

Option 2 would practically limit the metadata standard scope to user facing metadata but not restrict additional metadata standards with a different scope (possibly used in parallel).

Meanwhile option 1 keeps a larger more abstract scope for this single standard where metadata is easily accessible for on-chain processing at the cost of inoperability with other chain wallets and marketplaces.

From the WG perspective, we thought it would make more sense to have a standard compatible with other chain wallets and marketplaces. After which additional metadata standards could be defined if needed that aren’t compatible with other chains but have a different/larger scope.

---

<div class="post-metadata">

**Author:** ![sea-snake](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/sea-snake/32/7243_2.png) [@sea-snake](https://forum.dfinity.org/u/sea-snake)\
**Post date:** [March 25, 2025, 9:18am UTC](https://forum.dfinity.org/t/approaches-to-icrc-7-nft-user-facing-metadata/42884/12 "2025-03-25T09:18:18Z")

</div>

This topic is on the agenda for the [Token WG meeting](https://dfinity.zoom.us/j/97922121860?pwd=wtGHHLnbN0GLZCFBi476UHDvFin9Ic.1) 2025-03-25T16:00:00Z.

---

<div class="post-metadata">

**Author:** ![bls\_sigmature](https://avatars.discourse-cdn.com/v4/letter/b/ad7895/32.png) [@bls\_sigmature](https://forum.dfinity.org/u/bls_sigmature)\
**Post date:** [March 25, 2025, 2:45pm UTC](https://forum.dfinity.org/t/approaches-to-icrc-7-nft-user-facing-metadata/42884/13 "2025-03-25T14:45:30Z")

</div>

> [@sea-snake](#):
>
> 2025-03-25T16:00:00Z.

Would it be possible for you to record the meeting and post the summary here? If you post the recording of discussions that will be plenty enough too. Just trying to catch up with the discussions.

---

<div class="post-metadata">

**Author:** ![sea-snake](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/sea-snake/32/7243_2.png) [@sea-snake](https://forum.dfinity.org/u/sea-snake)\
**Post date:** [March 25, 2025, 3:08pm UTC](https://forum.dfinity.org/t/approaches-to-icrc-7-nft-user-facing-metadata/42884/14 "2025-03-25T15:08:01Z")

</div>

Will link the recording after the call.

Though, it’s mostly appreciated if people from outside the WG join the call with input, feedback and questions at this stage.

---

<div class="post-metadata">

**Author:** ![bls\_sigmature](https://avatars.discourse-cdn.com/v4/letter/b/ad7895/32.png) [@bls\_sigmature](https://forum.dfinity.org/u/bls_sigmature)\
**Post date:** [March 25, 2025, 3:10pm UTC](https://forum.dfinity.org/t/approaches-to-icrc-7-nft-user-facing-metadata/42884/15 "2025-03-25T15:10:55Z")

</div>

Yes it would have been nice. Maybe eventually many will join once this discussion is jump-started

---

<div class="post-metadata">

**Author:** ![bls\_sigmature](https://avatars.discourse-cdn.com/v4/letter/b/ad7895/32.png) [@bls\_sigmature](https://forum.dfinity.org/u/bls_sigmature)\
**Post date:** [March 27, 2025, 12:16pm UTC](https://forum.dfinity.org/t/approaches-to-icrc-7-nft-user-facing-metadata/42884/16 "2025-03-27T12:16:45Z")

</div>

> [@sea-snake](#):
>
> Will link the recording after the call.
> 
> Though, it’s mostly appreciated if people from outside the WG join the call with input, feedback and questions at this stage.

Hello @sea-snake any updates on this?

---

<div class="post-metadata">

**Author:** ![catpirate32](https://avatars.discourse-cdn.com/v4/letter/c/258eb7/32.png) [@catpirate32](https://forum.dfinity.org/u/catpirate32)\
**Post date:** [March 31, 2025, 5:39am UTC](https://forum.dfinity.org/t/approaches-to-icrc-7-nft-user-facing-metadata/42884/17 "2025-03-31T05:39:58Z")

</div>

Good Morning @sea-snake. I was waiting for the recording you were talking about earlier.

> [@sea-snake](#):
>
> Will link the recording after the call.

Please let me know if you have this sorted.

---

<div class="post-metadata">

**Author:** ![skilesare](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/skilesare/32/5609_2.png) [@skilesare](https://forum.dfinity.org/u/skilesare)\
**Post date:** [March 31, 2025, 9:15pm UTC](https://forum.dfinity.org/t/approaches-to-icrc-7-nft-user-facing-metadata/42884/18 "2025-03-31T21:15:59Z")

</div>

I believe that @dieter.sommer will have to make it public/publish it. I’m pretty sure the “this call is recording” came up so it should be in the Dfinity zoom account.

---

<div class="post-metadata">

**Author:** ![sea-snake](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/sea-snake/32/7243_2.png) [@sea-snake](https://forum.dfinity.org/u/sea-snake)\
**Post date:** [March 31, 2025, 9:30pm UTC](https://forum.dfinity.org/t/approaches-to-icrc-7-nft-user-facing-metadata/42884/19 "2025-03-31T21:30:23Z")

</div>

Had some technical issues on my end that should be resolved now (zoom/drive permissions). I’ll upload it in next hour when I’m back behind my pc.

---

<div class="post-metadata">

**Author:** ![sea-snake](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/sea-snake/32/7243_2.png) [@sea-snake](https://forum.dfinity.org/u/sea-snake)\
**Post date:** [March 31, 2025, 10:41pm UTC](https://forum.dfinity.org/t/approaches-to-icrc-7-nft-user-facing-metadata/42884/20 "2025-03-31T22:41:58Z")

</div>

Here’s the uploaded recording: [2025-03-25 WG meeting.mp4 - Google Drive](https://drive.google.com/file/d/11DZsKtBOM1nXSEdOHHGClDBdj1_GQQXu)

The Tokenization WG repo with an overview of standards, link to recording and more can be found here: [GitHub - dfinity/wg-token-standards: Token Standards Working Group](https://github.com/dfinity/wg-token-standards)

I’ll create another thread this week regarding ICRC-7 and its next steps.

[Next page](https://forum.dfinity.org/t/approaches-to-icrc-7-nft-user-facing-metadata/42884.md?page=2)