From 7bee2e05fff8ac50e746343bae4051a32704f44a Mon Sep 17 00:00:00 2001 From: sea-snake <104725312+sea-snake@users.noreply.github.com> Date: Tue, 13 Aug 2024 16:18:59 +0200 Subject: [PATCH 01/13] Create ICRC-97.md --- ICRCs/ICRC-97/ICRC-97.md | 95 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 95 insertions(+) create mode 100644 ICRCs/ICRC-97/ICRC-97.md diff --git a/ICRCs/ICRC-97/ICRC-97.md b/ICRCs/ICRC-97/ICRC-97.md new file mode 100644 index 00000000..d58ca3ce --- /dev/null +++ b/ICRCs/ICRC-97/ICRC-97.md @@ -0,0 +1,95 @@ +| ICRC | Title | Author | Discussions | Status | Type | Category | Created | +|:----:|:------------------------------------------:|:--------------------------------------------------------------------------------:|:-----------------------------------------:|:------:|:---------------:|:--------:|:----------:| +| 97 | Non-Fungible Token (NFT) Metadata Standard | Thomas (@sea-snake), Austin Fatheree (@skilesare), Dieter Sommer (@dietersommer) | https://github.com/dfinity/ICRC/issues/97 | Draft | Standards Track | | 2024-08-13 | + +# ICRC-97: Non-Fungible Token (NFT) Metadata Standard + +ICRC-97 is a metadata standard for the implementation of Non-Fungible Tokens (NFTs) on +the [Internet Computer](https://internetcomputer.org). + +The standard is designed to allow for multiple assets with different data types with various purposes. Where additional +asset purposes and attribute display types can be standardized in ICRC-97 extensions. + +## Extending the ICRC-7 Standard with Token Metadata + +The [`icrc7_token_metadata`](https://github.com/dfinity/ICRC/blob/main/ICRCs/ICRC-7/ICRC-7.md#icrc7_token_metadata) +method returns the token metadata for `token_ids`, a list of token ids. Each tuple in +the response vector comprises an optional `metadata` element with the metadata expressed as vector of `text` and `Value` +pairs. + +ICRC-7 does not specify the representation of token metadata any further than that it is represented in a generic manner +as a vector of (text, Value)-pairs. The ICRC-97 standard extends the ICRC-7 standard with a token metadata +standard. + +### Entrypoint + +The following metadata property MUST be defined in the root of the token metadata if we want to return on-chain +metadata. + +| Root Metadata Property | ICRC-3 Type | Description | +|------------------------|-----------------|----------------------------------------| +| icrc99:metadata | variant { Map } | Contains on-chain metadata properties. | + +Alternatively the following metadata property MUST be defined in the root of the token metadata if we want to return +external +off-chain metadata instead of on-chain metadata. + +| Root Metadata Property | ICRC-3 Type | Description | +|--------------------------|-----------------|---------------------------------------------------| +| icrc99:external_metadata | variant { Map } | Contains below external JSON metadata properties. | + +| External Metadata Property | Optional | ICRC-3 Type | Description | +|----------------------------|----------|------------------|--------------------------------------------------------------------------------| +| url | No | variant { Text } | URL that returns the metadata in JSON format (protocol is not limited to HTTP) | +| sha256_hash | Yes | variant { Blob } | SHA-256 hash of HTTP response body bytes returned from above url. | + +### Metadata properties + +Below table list all (optional) metadata properties defined in this standard. Each property is defined in both ICRC-3 +and JSON type to support both on-chain `Value` and off-chain JSON metadata respectively. + +| Metadata Property | Optional | ICRC-3 Type | JSON Type | Description | +|-------------------|----------|-----------------------------------------|-----------|---------------------------------------------------------| +| external_url | Yes | variant { Text } | string | URL that allows the user to view the item on your site. | +| name | Yes | variant { Text } | string | Plain text. | +| description | Yes | variant { Text } | string | Markdown. | +| assets | Yes | variant { Array = vec variant { Map } } | object[] | List of assets ordered by priority descending. | +| attributes | Yes | variant { Array = vec variant { Map } } | object[] | List of attributes ordered by priority descending. | + +The following table list all (optional) asset properties. + +| Asset Property | Optional | ICRC-3 Type | JSON Type | Description | +|----------------|----------|------------------|-----------------|--------------------------------------------------------------------------------| +| url | No | variant { Text } | string | URL that returns the asset e.g. a PNG image (protocol is not limited to HTTP). | +| mime | No | variant { Text } | string | Mime type as defined in RFC 6838. | +| sha256_hash | Yes | variant { Blob } | string (base64) | SHA-256 hash of HTTP response body bytes returned from above url. | +| purpose | Yes | variant { Text } | string | Indicate purpose of asset. | + +Below list of purpose values are part of the ICRC-97 standard, this list could be extended by other standards. +Purpose values can define additional asset properties. + +| Purpose Value | Description | +|----------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------| +| icrc99:image | Original size image that is shown on e.g. item details page. Additional optional `width` and `height` properties define the dimensions in number of pixels. | +| icrc99:preview | Small image meant as preview within e.g. a list of items. Additional optional `width` and `height` properties define the dimensions in number of pixels. | + +The following table list all (optional) attribute properties. + +| Attribute Property | Optional | ICRC-3 Type | JSON Type | Description | +|--------------------|----------|----------------------------|------------------|---------------------------------------------| +| value | No | variant { Text; Nat; Int } | string \| number | Value of the trait. | +| trait_type | No | variant { Text } | string | Name of the trait. | +| display_type | Yes | variant { Text } | string | Indicate how attribute should be displayed. | + +Below list of display types are part of the ICRC-97 standard, this list could be extended by other standards. +Display types can define additional attribute properties. + +| Display Type Value | Description | +|-------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------| +| icrc97:property | Shows attribute as property with e.g. rarity, this is the default display type. | +| icrc97:date | Shows attribute as date, expects epoch timestamp number in milliseconds. | +| icrc97:time | Shows attribute as date with time, expects epoch timestamp number in milliseconds. | +| icrc97:rank | Shows attribute as progress rank e.g. 4 of 10, expects number and additional `max_value` property with a number. | +| icrc97:stat | Show attribute as stat e.g. 1 out of 2, expects number and additional `max_value` property with a number. | +| icrc97:boost | Shows attribute as boost e.g. +10, expects number and optional additional `min_value` and `max_value` properties. Numbers can be either positive or negative. | +| icrc97:boost_percentage | Same as `icrc97:boost` but shows values with %. | From ba2e7d9c288f63d670f6d8413b60f49ded4f079f Mon Sep 17 00:00:00 2001 From: sea-snake <104725312+sea-snake@users.noreply.github.com> Date: Tue, 13 Aug 2024 17:19:37 +0200 Subject: [PATCH 02/13] Update ICRC-97.md --- ICRCs/ICRC-97/ICRC-97.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/ICRCs/ICRC-97/ICRC-97.md b/ICRCs/ICRC-97/ICRC-97.md index d58ca3ce..88395262 100644 --- a/ICRCs/ICRC-97/ICRC-97.md +++ b/ICRCs/ICRC-97/ICRC-97.md @@ -28,7 +28,7 @@ metadata. | Root Metadata Property | ICRC-3 Type | Description | |------------------------|-----------------|----------------------------------------| -| icrc99:metadata | variant { Map } | Contains on-chain metadata properties. | +| icrc97:metadata | variant { Map } | Contains on-chain metadata properties. | Alternatively the following metadata property MUST be defined in the root of the token metadata if we want to return external @@ -36,7 +36,7 @@ off-chain metadata instead of on-chain metadata. | Root Metadata Property | ICRC-3 Type | Description | |--------------------------|-----------------|---------------------------------------------------| -| icrc99:external_metadata | variant { Map } | Contains below external JSON metadata properties. | +| icrc97:external_metadata | variant { Map } | Contains below external JSON metadata properties. | | External Metadata Property | Optional | ICRC-3 Type | Description | |----------------------------|----------|------------------|--------------------------------------------------------------------------------| @@ -70,8 +70,8 @@ Purpose values can define additional asset properties. | Purpose Value | Description | |----------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------| -| icrc99:image | Original size image that is shown on e.g. item details page. Additional optional `width` and `height` properties define the dimensions in number of pixels. | -| icrc99:preview | Small image meant as preview within e.g. a list of items. Additional optional `width` and `height` properties define the dimensions in number of pixels. | +| icrc97:image | Original size image that is shown on e.g. item details page. Additional optional `width` and `height` properties define the dimensions in number of pixels. | +| icrc97:preview | Small image meant as preview within e.g. a list of items. Additional optional `width` and `height` properties define the dimensions in number of pixels. | The following table list all (optional) attribute properties. From d8b9ba3f41b5eb05fe6d3cf7fb871f8fb6e69f27 Mon Sep 17 00:00:00 2001 From: sea-snake <104725312+sea-snake@users.noreply.github.com> Date: Tue, 15 Oct 2024 15:04:57 +0200 Subject: [PATCH 03/13] Update ICRC-97.md Indicate that the minimum list of asset purposes and display types are defined. --- ICRCs/ICRC-97/ICRC-97.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/ICRCs/ICRC-97/ICRC-97.md b/ICRCs/ICRC-97/ICRC-97.md index 88395262..5bdbb564 100644 --- a/ICRCs/ICRC-97/ICRC-97.md +++ b/ICRCs/ICRC-97/ICRC-97.md @@ -10,6 +10,8 @@ the [Internet Computer](https://internetcomputer.org). The standard is designed to allow for multiple assets with different data types with various purposes. Where additional asset purposes and attribute display types can be standardized in ICRC-97 extensions. +A list of asset purposes and attribute display types are defined in ICRC-97 to the minimum needed for wallets and marketplaces to display NFTs. + ## Extending the ICRC-7 Standard with Token Metadata The [`icrc7_token_metadata`](https://github.com/dfinity/ICRC/blob/main/ICRCs/ICRC-7/ICRC-7.md#icrc7_token_metadata) From 4aafbfe72f47d4c2399f4ee60bbfccc48098c0a7 Mon Sep 17 00:00:00 2001 From: sea-snake <104725312+sea-snake@users.noreply.github.com> Date: Tue, 15 Oct 2024 15:12:43 +0200 Subject: [PATCH 04/13] Update ICRC-97.md Rephrase purpose of ICRC-97. --- ICRCs/ICRC-97/ICRC-97.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ICRCs/ICRC-97/ICRC-97.md b/ICRCs/ICRC-97/ICRC-97.md index 5bdbb564..38775d1a 100644 --- a/ICRCs/ICRC-97/ICRC-97.md +++ b/ICRCs/ICRC-97/ICRC-97.md @@ -20,8 +20,8 @@ the response vector comprises an optional `metadata` element with the metadata e pairs. ICRC-7 does not specify the representation of token metadata any further than that it is represented in a generic manner -as a vector of (text, Value)-pairs. The ICRC-97 standard extends the ICRC-7 standard with a token metadata -standard. +as a vector of (text, Value)-pairs. The ICRC-97 standard defines a token metadata +standard for ICRC-7 and other NFT standards. ### Entrypoint From f030e36e40cef08131d8920802282684c328d309 Mon Sep 17 00:00:00 2001 From: sea-snake <104725312+sea-snake@users.noreply.github.com> Date: Tue, 15 Oct 2024 15:16:56 +0200 Subject: [PATCH 05/13] Update ICRC-97.md Mention Value is recursive. --- ICRCs/ICRC-97/ICRC-97.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ICRCs/ICRC-97/ICRC-97.md b/ICRCs/ICRC-97/ICRC-97.md index 38775d1a..76fe4aed 100644 --- a/ICRCs/ICRC-97/ICRC-97.md +++ b/ICRCs/ICRC-97/ICRC-97.md @@ -16,8 +16,8 @@ A list of asset purposes and attribute display types are defined in ICRC-97 to t The [`icrc7_token_metadata`](https://github.com/dfinity/ICRC/blob/main/ICRCs/ICRC-7/ICRC-7.md#icrc7_token_metadata) method returns the token metadata for `token_ids`, a list of token ids. Each tuple in -the response vector comprises an optional `metadata` element with the metadata expressed as vector of `text` and `Value` -pairs. +the response vector comprises an optional `metadata` element with the metadata expressed as a vector of `text` and `Value` +pairs. Where `Value` is recursive as defined in the ICRC-3 standard. ICRC-7 does not specify the representation of token metadata any further than that it is represented in a generic manner as a vector of (text, Value)-pairs. The ICRC-97 standard defines a token metadata From ac1b5f3ecb1d95cda181687d041335449e1a9b7b Mon Sep 17 00:00:00 2001 From: sea-snake <104725312+sea-snake@users.noreply.github.com> Date: Tue, 15 Oct 2024 15:19:35 +0200 Subject: [PATCH 06/13] Update ICRC-97.md Fix spelling --- ICRCs/ICRC-97/ICRC-97.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ICRCs/ICRC-97/ICRC-97.md b/ICRCs/ICRC-97/ICRC-97.md index 76fe4aed..181bfc73 100644 --- a/ICRCs/ICRC-97/ICRC-97.md +++ b/ICRCs/ICRC-97/ICRC-97.md @@ -47,7 +47,7 @@ off-chain metadata instead of on-chain metadata. ### Metadata properties -Below table list all (optional) metadata properties defined in this standard. Each property is defined in both ICRC-3 +Below table lists all (optional) metadata properties defined in this standard. Each property is defined in both ICRC-3 and JSON type to support both on-chain `Value` and off-chain JSON metadata respectively. | Metadata Property | Optional | ICRC-3 Type | JSON Type | Description | From a79d8d3d213e730d36803d67602d921c71ebaffa Mon Sep 17 00:00:00 2001 From: sea-snake <104725312+sea-snake@users.noreply.github.com> Date: Tue, 15 Oct 2024 15:21:31 +0200 Subject: [PATCH 07/13] Update ICRC-97.md Fix spelling --- ICRCs/ICRC-97/ICRC-97.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ICRCs/ICRC-97/ICRC-97.md b/ICRCs/ICRC-97/ICRC-97.md index 181bfc73..cb5a2102 100644 --- a/ICRCs/ICRC-97/ICRC-97.md +++ b/ICRCs/ICRC-97/ICRC-97.md @@ -58,7 +58,7 @@ and JSON type to support both on-chain `Value` and off-chain JSON metadata respe | assets | Yes | variant { Array = vec variant { Map } } | object[] | List of assets ordered by priority descending. | | attributes | Yes | variant { Array = vec variant { Map } } | object[] | List of attributes ordered by priority descending. | -The following table list all (optional) asset properties. +The following table lists all (optional) asset properties. | Asset Property | Optional | ICRC-3 Type | JSON Type | Description | |----------------|----------|------------------|-----------------|--------------------------------------------------------------------------------| @@ -75,7 +75,7 @@ Purpose values can define additional asset properties. | icrc97:image | Original size image that is shown on e.g. item details page. Additional optional `width` and `height` properties define the dimensions in number of pixels. | | icrc97:preview | Small image meant as preview within e.g. a list of items. Additional optional `width` and `height` properties define the dimensions in number of pixels. | -The following table list all (optional) attribute properties. +The following table lists all (optional) attribute properties. | Attribute Property | Optional | ICRC-3 Type | JSON Type | Description | |--------------------|----------|----------------------------|------------------|---------------------------------------------| From 0fabfd723ab66a39f6aaef0b1084c109c95e77c5 Mon Sep 17 00:00:00 2001 From: sea-snake <104725312+sea-snake@users.noreply.github.com> Date: Tue, 15 Oct 2024 15:22:15 +0200 Subject: [PATCH 08/13] Update ICRC-97.md Improve phrasing. --- ICRCs/ICRC-97/ICRC-97.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ICRCs/ICRC-97/ICRC-97.md b/ICRCs/ICRC-97/ICRC-97.md index cb5a2102..cda77ba9 100644 --- a/ICRCs/ICRC-97/ICRC-97.md +++ b/ICRCs/ICRC-97/ICRC-97.md @@ -48,7 +48,7 @@ off-chain metadata instead of on-chain metadata. ### Metadata properties Below table lists all (optional) metadata properties defined in this standard. Each property is defined in both ICRC-3 -and JSON type to support both on-chain `Value` and off-chain JSON metadata respectively. +and JSON type to support both on-chain `Value` and off-chain JSON metadata, respectively. | Metadata Property | Optional | ICRC-3 Type | JSON Type | Description | |-------------------|----------|-----------------------------------------|-----------|---------------------------------------------------------| From af41f9534300813c297119c25a2f6a238891b479 Mon Sep 17 00:00:00 2001 From: sea-snake <104725312+sea-snake@users.noreply.github.com> Date: Tue, 15 Oct 2024 15:28:31 +0200 Subject: [PATCH 09/13] Update ICRC-97.md Mention future work. --- ICRCs/ICRC-97/ICRC-97.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/ICRCs/ICRC-97/ICRC-97.md b/ICRCs/ICRC-97/ICRC-97.md index cda77ba9..d3439a01 100644 --- a/ICRCs/ICRC-97/ICRC-97.md +++ b/ICRCs/ICRC-97/ICRC-97.md @@ -95,3 +95,7 @@ Display types can define additional attribute properties. | icrc97:stat | Show attribute as stat e.g. 1 out of 2, expects number and additional `max_value` property with a number. | | icrc97:boost | Shows attribute as boost e.g. +10, expects number and optional additional `min_value` and `max_value` properties. Numbers can be either positive or negative. | | icrc97:boost_percentage | Same as `icrc97:boost` but shows values with %. | + +## Future work + +This standard defines a token metadata standard for ICRC-7. But also applies to future standards like ICRC-8, where needed ICRC-97 can be extended with additional asset purposes and display type values to accomodate for these standards. From 5f95f16b3eca07078f0e24eb62f002c9a8e62b43 Mon Sep 17 00:00:00 2001 From: sea-snake Date: Tue, 25 Mar 2025 14:11:28 +0100 Subject: [PATCH 10/13] Refactor standard to align with JSON approach. --- ICRCs/ICRC-97/ICRC-97.md | 178 +++++++++++++++++----------------- ICRCs/ICRC-97/approaches.md | 185 ++++++++++++++++++++++++++++++++++++ 2 files changed, 270 insertions(+), 93 deletions(-) create mode 100644 ICRCs/ICRC-97/approaches.md diff --git a/ICRCs/ICRC-97/ICRC-97.md b/ICRCs/ICRC-97/ICRC-97.md index d3439a01..595b44ab 100644 --- a/ICRCs/ICRC-97/ICRC-97.md +++ b/ICRCs/ICRC-97/ICRC-97.md @@ -1,101 +1,93 @@ | ICRC | Title | Author | Discussions | Status | Type | Category | Created | |:----:|:------------------------------------------:|:--------------------------------------------------------------------------------:|:-----------------------------------------:|:------:|:---------------:|:--------:|:----------:| -| 97 | Non-Fungible Token (NFT) Metadata Standard | Thomas (@sea-snake), Austin Fatheree (@skilesare), Dieter Sommer (@dietersommer) | https://github.com/dfinity/ICRC/issues/97 | Draft | Standards Track | | 2024-08-13 | +| 97 | Non-Fungible Token (NFT) Metadata Standard | Thomas (@sea-snake), Austin Fatheree (@skilesare), Dieter Sommer (@dietersommer) | https://github.com/dfinity/ICRC/issues/97 | Draft | Standards Track | Tokens | 2024-08-13 | # ICRC-97: Non-Fungible Token (NFT) Metadata Standard -ICRC-97 is a metadata standard for the implementation of Non-Fungible Tokens (NFTs) on -the [Internet Computer](https://internetcomputer.org). +ICRC-97 defines a **user-facing metadata** standard for Non-Fungible Tokens (NFTs) on the Internet Computer. This standard aligns with ERC-721 and Metaplex JSON metadata formats to enhance interoperability across ecosystems. -The standard is designed to allow for multiple assets with different data types with various purposes. Where additional -asset purposes and attribute display types can be standardized in ICRC-97 extensions. - -A list of asset purposes and attribute display types are defined in ICRC-97 to the minimum needed for wallets and marketplaces to display NFTs. - -## Extending the ICRC-7 Standard with Token Metadata +## ICRC-7 Token Metadata The [`icrc7_token_metadata`](https://github.com/dfinity/ICRC/blob/main/ICRCs/ICRC-7/ICRC-7.md#icrc7_token_metadata) -method returns the token metadata for `token_ids`, a list of token ids. Each tuple in -the response vector comprises an optional `metadata` element with the metadata expressed as a vector of `text` and `Value` -pairs. Where `Value` is recursive as defined in the ICRC-3 standard. - -ICRC-7 does not specify the representation of token metadata any further than that it is represented in a generic manner -as a vector of (text, Value)-pairs. The ICRC-97 standard defines a token metadata -standard for ICRC-7 and other NFT standards. - -### Entrypoint - -The following metadata property MUST be defined in the root of the token metadata if we want to return on-chain -metadata. - -| Root Metadata Property | ICRC-3 Type | Description | -|------------------------|-----------------|----------------------------------------| -| icrc97:metadata | variant { Map } | Contains on-chain metadata properties. | - -Alternatively the following metadata property MUST be defined in the root of the token metadata if we want to return -external -off-chain metadata instead of on-chain metadata. - -| Root Metadata Property | ICRC-3 Type | Description | -|--------------------------|-----------------|---------------------------------------------------| -| icrc97:external_metadata | variant { Map } | Contains below external JSON metadata properties. | - -| External Metadata Property | Optional | ICRC-3 Type | Description | -|----------------------------|----------|------------------|--------------------------------------------------------------------------------| -| url | No | variant { Text } | URL that returns the metadata in JSON format (protocol is not limited to HTTP) | -| sha256_hash | Yes | variant { Blob } | SHA-256 hash of HTTP response body bytes returned from above url. | - -### Metadata properties - -Below table lists all (optional) metadata properties defined in this standard. Each property is defined in both ICRC-3 -and JSON type to support both on-chain `Value` and off-chain JSON metadata, respectively. - -| Metadata Property | Optional | ICRC-3 Type | JSON Type | Description | -|-------------------|----------|-----------------------------------------|-----------|---------------------------------------------------------| -| external_url | Yes | variant { Text } | string | URL that allows the user to view the item on your site. | -| name | Yes | variant { Text } | string | Plain text. | -| description | Yes | variant { Text } | string | Markdown. | -| assets | Yes | variant { Array = vec variant { Map } } | object[] | List of assets ordered by priority descending. | -| attributes | Yes | variant { Array = vec variant { Map } } | object[] | List of attributes ordered by priority descending. | - -The following table lists all (optional) asset properties. - -| Asset Property | Optional | ICRC-3 Type | JSON Type | Description | -|----------------|----------|------------------|-----------------|--------------------------------------------------------------------------------| -| url | No | variant { Text } | string | URL that returns the asset e.g. a PNG image (protocol is not limited to HTTP). | -| mime | No | variant { Text } | string | Mime type as defined in RFC 6838. | -| sha256_hash | Yes | variant { Blob } | string (base64) | SHA-256 hash of HTTP response body bytes returned from above url. | -| purpose | Yes | variant { Text } | string | Indicate purpose of asset. | - -Below list of purpose values are part of the ICRC-97 standard, this list could be extended by other standards. -Purpose values can define additional asset properties. - -| Purpose Value | Description | -|----------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------| -| icrc97:image | Original size image that is shown on e.g. item details page. Additional optional `width` and `height` properties define the dimensions in number of pixels. | -| icrc97:preview | Small image meant as preview within e.g. a list of items. Additional optional `width` and `height` properties define the dimensions in number of pixels. | - -The following table lists all (optional) attribute properties. - -| Attribute Property | Optional | ICRC-3 Type | JSON Type | Description | -|--------------------|----------|----------------------------|------------------|---------------------------------------------| -| value | No | variant { Text; Nat; Int } | string \| number | Value of the trait. | -| trait_type | No | variant { Text } | string | Name of the trait. | -| display_type | Yes | variant { Text } | string | Indicate how attribute should be displayed. | - -Below list of display types are part of the ICRC-97 standard, this list could be extended by other standards. -Display types can define additional attribute properties. - -| Display Type Value | Description | -|-------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------| -| icrc97:property | Shows attribute as property with e.g. rarity, this is the default display type. | -| icrc97:date | Shows attribute as date, expects epoch timestamp number in milliseconds. | -| icrc97:time | Shows attribute as date with time, expects epoch timestamp number in milliseconds. | -| icrc97:rank | Shows attribute as progress rank e.g. 4 of 10, expects number and additional `max_value` property with a number. | -| icrc97:stat | Show attribute as stat e.g. 1 out of 2, expects number and additional `max_value` property with a number. | -| icrc97:boost | Shows attribute as boost e.g. +10, expects number and optional additional `min_value` and `max_value` properties. Numbers can be either positive or negative. | -| icrc97:boost_percentage | Same as `icrc97:boost` but shows values with %. | - -## Future work - -This standard defines a token metadata standard for ICRC-7. But also applies to future standards like ICRC-8, where needed ICRC-97 can be extended with additional asset purposes and display type values to accomodate for these standards. +method returns the token metadata for `token_ids`, represented as a list of (text, Value) pairs. Here, Value is recursive as defined in the ICRC-3 standard. + +ICRC-97 specifies a metadata property pointing to one or more URIs serving the metadata JSON. + +| Property | ICRC-3 Type | +|-------------------|----------------------------------------| +| `icrc97:metadata` | `variant { Array = variant { Text } }` | + +## JSON Metadata properties + +The following properties are defined for token metadata under the ICRC-97 standard. These fields are designed to be user-facing and provide essential information about the NFT. + +| Property | Required | Description | +|----------------|----------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| `name` | Yes | The name of the NFT e.g. "CoolToken #1" | +| `description` | Yes | A detailed description of the NFT or token. It can describe its history, rarity, use case, or special properties. | +| `image` | Yes | URI pointing to the primary image representing the NFT. Supported formats include PNG, JPEG, and SVG. | +| `external_url` | No | URI pointing to an external URL defining the asset — e.g. the game's main site. | +| `attributes` | No | Array of attributes defining the characteristics of the asset. | + +The attribute fields supports an optional `display_type` to enhance the visual representation of certain traits. + +| Display Type | Description | Example | +|--------------------|------------------------------------------------------------------------------------------|----------------------------| +| `number` | Displays the attribute as a numeric value. | `"Level": 5` | +| `boost_percentage` | Displays the attribute as a percentage-based boost (common for gaming NFTs). | `"Health Boost": +85%` | +| `boost_number` | Displays the attribute as a numeric boost (e.g., additional points in a game). | `"Strength Boost": +10` | +| `date` | Displays the value as a human-readable date interpreted from a Unix timestamp (seconds). | `"Birthday": "2021-08-01"` | +| Default (no type) | If `display_type` is not specified, the attribute is displayed as a text-based trait. | `"Background": "Blue"` | + +Adding an optional `max_value` sets a ceiling for a numerical trait's possible values. If you set a `max_value`, make sure not to pass in a higher value. + +## URI Storage Recommendations + +To reduce risks associated with off-chain storage, developers can adopt one of the following decentralized approaches. Multiple URIs can be provided for resilience (clients can attempt the next one if the first fails). + +### 1. Basic Canister Approach: + +Embed JSON metadata directly within a URL using a DATA URI for fully on-chain storage. + +```candid +vec { + record { + "icrc97:metadata"; + variant { Array = vec { + variant { Text = "data:text/json;charset=utf-8;base64,ew0KICAgImtleSIgOiAidmFsdWUiDQp9" }; + }; }; + } +} +``` + +### 2. Multi-Canister Approach (Advanced) + +Store JSON metadata on the same canister or another certified canister, served via HTTPS. The ICRC-91 standard improves decentralization by removing the `ic0.app`/`icp0.io` dependency. + +```candid +vec { + record { + "icrc97:metadata"; + variant { Array = vec { + variant { Text = "ic-http://2225w-rqaaa-aaaai-qtqca-cai/metadata/3456" }; + variant { Text = "https://2225w-rqaaa-aaaai-qtqca-cai.icp0.io/metadata/3456" }; + }; }; + } +} +``` + +### 3. Bridging NFTs from Other Chains + +Point to their metadata on **IPFS**, a common decentralized file system. + +```candid +vec { + record { + "icrc97:metadata"; + variant { Array = vec { + variant { Text = "ipfs://bafybeihkoviema7g3gxyt6la7vd5ho32ictqbilu3wnlo3rs7ewhnp7lly" }; + variant { Text = "https://ipfs.io/ipfs/bafybeihkoviema7g3gxyt6la7vd5ho32ictqbilu3wnlo3rs7ewhnp7lly" }; + }; }; + } +} +``` \ No newline at end of file diff --git a/ICRCs/ICRC-97/approaches.md b/ICRCs/ICRC-97/approaches.md new file mode 100644 index 00000000..a937eec5 --- /dev/null +++ b/ICRCs/ICRC-97/approaches.md @@ -0,0 +1,185 @@ +# Approaches to ICRC-7 NFT User Facing Metadata + +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. + + ```candid + vec { + record { + "icrc97:metadata"; + variant { Array = vec { + variant { Text = "data:text/json;charset=utf-8;base64,ew0KICAgImtleSIgOiAidmFsdWUiDQp9" }; + }; }; + } + } + ``` + + > **Notes**: + > - This approach is only recommended for limited metadata, large data would limit the number of NFTs that can be queried at once. + > - For larger amounts, dynamic or other advanced types of metadata, it's recommended to use below approach instead. + + +- **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. + + ```candid + vec { + record { + "icrc97:metadata"; + variant { Array = vec { + variant { Text = "ic-http://2225w-rqaaa-aaaai-qtqca-cai/metadata/3456" }; + variant { Text = "https://2225w-rqaaa-aaaai-qtqca-cai.icp0.io/metadata/3456" }; + }; }; + } + } + ``` + + > **Notes**: + > - The URL path is not a part of this standard and could be any provided value. + > - ICRC-91 is still work in progress and is likely to change, the value here should be seen as a placeholder. + > - Efforts are currently being made to align this standard with the ICRC namespacing and payment URI standards. + > - Multiple entries can be provided for resiliency. If the first one is not compatible with a client, the next one can be attempted. + > - HTTP cache headers can be used to optimize the number of incoming requests, particularly if metadata is immutable. + + +- **Recommended for Bringing NFTs from Other Chains** + Store metadata on IPFS, a common decentralized file system, to facilitate interoperability with NFTs from other blockchains. + + ```candid + vec { + record { + "icrc97:metadata"; + variant { Array = vec { + variant { Text = "ipfs://bafybeihkoviema7g3gxyt6la7vd5ho32ictqbilu3wnlo3rs7ewhnp7lly" }; + variant { Text = "https://ipfs.io/ipfs/bafybeihkoviema7g3gxyt6la7vd5ho32ictqbilu3wnlo3rs7ewhnp7lly" }; + }; }; + } + } + ``` + + > **Notes:** + > - Multiple entries can be provided for resiliency. If the first one is not compatible with a client, the next one can be attempted. + > - In IPFS, the URI itself is a content identifier (CID), derived from the hash of the file's content, ensuring immutability and authenticity. + +### 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 regarding our current viewpoint and approach: + +- Initially we considered the hybrid approach to cover all use cases. Looking further into the consequences of such an approach, we discovered it would make implementation and adoption a significant challenge. Two approaches in a single standard would need result in developers need to implement and maintain things twice everywhere. +- Trying to define a metadata standards that cover all use cases is a big goal but is likely to result in a standard that falls short for each individual use case. So instead we decided to focus on a single use case **user facing metadata**, this use case covers the data shown to end users within wallets and marketplaces. +- 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. Therefore, we think the JSON approach, which indeed seems less "IC" than candid, aligns better with this goal. +- Immutability, dynamic and other metadata topics are interesting and should definitely be covered. But from our viewpoint, these topics require further discussion with developers within the WG and the community. Meanwhile, these topics are not directly affecting the use case of **user facing metadata** shown by wallet and marketplaces. + +## Join the discussion + +Respond in this thread to join the discussion, additionally there's the Tokenization WG meeting every other Tuesday. + +- Are there other better approaches we've missed? +- Disagree with our viewpoint? Awesome, share your thoughts! +- 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? \ No newline at end of file From 918b60c41e995df3293898f2ce8d64f243c0124b Mon Sep 17 00:00:00 2001 From: sea-snake Date: Tue, 25 Mar 2025 14:30:29 +0100 Subject: [PATCH 11/13] Refactor standard to align with JSON approach. --- ICRCs/ICRC-97/ICRC-97.md | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/ICRCs/ICRC-97/ICRC-97.md b/ICRCs/ICRC-97/ICRC-97.md index 595b44ab..930123e3 100644 --- a/ICRCs/ICRC-97/ICRC-97.md +++ b/ICRCs/ICRC-97/ICRC-97.md @@ -17,17 +17,18 @@ ICRC-97 specifies a metadata property pointing to one or more URIs serving the m |-------------------|----------------------------------------| | `icrc97:metadata` | `variant { Array = variant { Text } }` | -## JSON Metadata properties +## JSON Metadata Properties The following properties are defined for token metadata under the ICRC-97 standard. These fields are designed to be user-facing and provide essential information about the NFT. -| Property | Required | Description | -|----------------|----------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| `name` | Yes | The name of the NFT e.g. "CoolToken #1" | -| `description` | Yes | A detailed description of the NFT or token. It can describe its history, rarity, use case, or special properties. | -| `image` | Yes | URI pointing to the primary image representing the NFT. Supported formats include PNG, JPEG, and SVG. | -| `external_url` | No | URI pointing to an external URL defining the asset — e.g. the game's main site. | -| `attributes` | No | Array of attributes defining the characteristics of the asset. | +| Property | Required | Description | +|-----------------|----------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| `name` | Yes | The name of the NFT e.g. "CoolToken #1" | +| `description` | Yes | A detailed description of the NFT or token. It can describe its history, rarity, use case, or special properties. | +| `image` | Yes | URI pointing to the primary image representing the NFT. Supported formats include **PNG**, **JPEG**, and **SVG**. | +| `animation_url` | No | URI pointing to interactive NFT. This property supports the following file extensions and functionalities: | +| `external_url` | No | URI pointing to an external URL defining the asset — e.g. the game's main site. | +| `attributes` | No | Array of attributes defining the characteristics of the asset. | The attribute fields supports an optional `display_type` to enhance the visual representation of certain traits. @@ -41,6 +42,8 @@ The attribute fields supports an optional `display_type` to enhance the visual r Adding an optional `max_value` sets a ceiling for a numerical trait's possible values. If you set a `max_value`, make sure not to pass in a higher value. +While additional metadata properties and other file types (beyond those specified in this standard) are technically allowed, there is a risk that some platforms or services may not support them fully. This could lead to incompatibilities or issues with rendering/displaying the metadata across different systems. + ## URI Storage Recommendations To reduce risks associated with off-chain storage, developers can adopt one of the following decentralized approaches. Multiple URIs can be provided for resilience (clients can attempt the next one if the first fails). From ba4999c77c3cf33732ffb4cd81f8a8e05ab06cc2 Mon Sep 17 00:00:00 2001 From: sea-snake Date: Tue, 25 Mar 2025 14:31:45 +0100 Subject: [PATCH 12/13] Refactor standard to align with JSON approach. --- ICRCs/ICRC-97/approaches.md | 185 ------------------------------------ 1 file changed, 185 deletions(-) delete mode 100644 ICRCs/ICRC-97/approaches.md diff --git a/ICRCs/ICRC-97/approaches.md b/ICRCs/ICRC-97/approaches.md deleted file mode 100644 index a937eec5..00000000 --- a/ICRCs/ICRC-97/approaches.md +++ /dev/null @@ -1,185 +0,0 @@ -# Approaches to ICRC-7 NFT User Facing Metadata - -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. - - ```candid - vec { - record { - "icrc97:metadata"; - variant { Array = vec { - variant { Text = "data:text/json;charset=utf-8;base64,ew0KICAgImtleSIgOiAidmFsdWUiDQp9" }; - }; }; - } - } - ``` - - > **Notes**: - > - This approach is only recommended for limited metadata, large data would limit the number of NFTs that can be queried at once. - > - For larger amounts, dynamic or other advanced types of metadata, it's recommended to use below approach instead. - - -- **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. - - ```candid - vec { - record { - "icrc97:metadata"; - variant { Array = vec { - variant { Text = "ic-http://2225w-rqaaa-aaaai-qtqca-cai/metadata/3456" }; - variant { Text = "https://2225w-rqaaa-aaaai-qtqca-cai.icp0.io/metadata/3456" }; - }; }; - } - } - ``` - - > **Notes**: - > - The URL path is not a part of this standard and could be any provided value. - > - ICRC-91 is still work in progress and is likely to change, the value here should be seen as a placeholder. - > - Efforts are currently being made to align this standard with the ICRC namespacing and payment URI standards. - > - Multiple entries can be provided for resiliency. If the first one is not compatible with a client, the next one can be attempted. - > - HTTP cache headers can be used to optimize the number of incoming requests, particularly if metadata is immutable. - - -- **Recommended for Bringing NFTs from Other Chains** - Store metadata on IPFS, a common decentralized file system, to facilitate interoperability with NFTs from other blockchains. - - ```candid - vec { - record { - "icrc97:metadata"; - variant { Array = vec { - variant { Text = "ipfs://bafybeihkoviema7g3gxyt6la7vd5ho32ictqbilu3wnlo3rs7ewhnp7lly" }; - variant { Text = "https://ipfs.io/ipfs/bafybeihkoviema7g3gxyt6la7vd5ho32ictqbilu3wnlo3rs7ewhnp7lly" }; - }; }; - } - } - ``` - - > **Notes:** - > - Multiple entries can be provided for resiliency. If the first one is not compatible with a client, the next one can be attempted. - > - In IPFS, the URI itself is a content identifier (CID), derived from the hash of the file's content, ensuring immutability and authenticity. - -### 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 regarding our current viewpoint and approach: - -- Initially we considered the hybrid approach to cover all use cases. Looking further into the consequences of such an approach, we discovered it would make implementation and adoption a significant challenge. Two approaches in a single standard would need result in developers need to implement and maintain things twice everywhere. -- Trying to define a metadata standards that cover all use cases is a big goal but is likely to result in a standard that falls short for each individual use case. So instead we decided to focus on a single use case **user facing metadata**, this use case covers the data shown to end users within wallets and marketplaces. -- 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. Therefore, we think the JSON approach, which indeed seems less "IC" than candid, aligns better with this goal. -- Immutability, dynamic and other metadata topics are interesting and should definitely be covered. But from our viewpoint, these topics require further discussion with developers within the WG and the community. Meanwhile, these topics are not directly affecting the use case of **user facing metadata** shown by wallet and marketplaces. - -## Join the discussion - -Respond in this thread to join the discussion, additionally there's the Tokenization WG meeting every other Tuesday. - -- Are there other better approaches we've missed? -- Disagree with our viewpoint? Awesome, share your thoughts! -- 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? \ No newline at end of file From fda2baab98434928f57a595f8ab94273f1f063b0 Mon Sep 17 00:00:00 2001 From: sea-snake <104725312+sea-snake@users.noreply.github.com> Date: Tue, 4 Nov 2025 17:08:53 +0100 Subject: [PATCH 13/13] Remove ICRC-91 Remove ICRC-91 since it's not finalized yet and doesn't need to be in this standard. --- ICRCs/ICRC-97/ICRC-97.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/ICRCs/ICRC-97/ICRC-97.md b/ICRCs/ICRC-97/ICRC-97.md index 930123e3..42b51045 100644 --- a/ICRCs/ICRC-97/ICRC-97.md +++ b/ICRCs/ICRC-97/ICRC-97.md @@ -65,14 +65,13 @@ vec { ### 2. Multi-Canister Approach (Advanced) -Store JSON metadata on the same canister or another certified canister, served via HTTPS. The ICRC-91 standard improves decentralization by removing the `ic0.app`/`icp0.io` dependency. +Store JSON metadata on the same canister or another certified canister, served via HTTPS. ```candid vec { record { "icrc97:metadata"; variant { Array = vec { - variant { Text = "ic-http://2225w-rqaaa-aaaai-qtqca-cai/metadata/3456" }; variant { Text = "https://2225w-rqaaa-aaaai-qtqca-cai.icp0.io/metadata/3456" }; }; }; } @@ -93,4 +92,4 @@ vec { }; }; } } -``` \ No newline at end of file +```