From f5f17c08d6c0c7d21a469861fbc241de078ab67c Mon Sep 17 00:00:00 2001 From: Merul <69296233+coodos@users.noreply.github.com> Date: Fri, 4 Mar 2022 19:25:39 +0530 Subject: [PATCH 01/28] feat: add IOTA NFT tip --- tips/TIP-0027/tip-0027.md | 278 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 278 insertions(+) create mode 100644 tips/TIP-0027/tip-0027.md diff --git a/tips/TIP-0027/tip-0027.md b/tips/TIP-0027/tip-0027.md new file mode 100644 index 000000000..1dabc1fee --- /dev/null +++ b/tips/TIP-0027/tip-0027.md @@ -0,0 +1,278 @@ +--- +tip: 27 +title: IOTA NFT Standard IRC2 +description: Define NFT metadata standard, collection registry and creator royalties +author: Adam (@AdamCroply) , Merul (@coodos) +discussions-to: https://github.com/iotaledger/tips/discussions/59 +status: Draft +type: Standards +layer: Core +created: 2022-03-04 +--- + +# iNFT Standard - IRC2 + +## Introduction + +**IRC2** is a series of standards to support interoperable and universal NFT systems throughout the IOTA eco-system, to provide a more robust and secure system for creators and buyers. + +## Why iNFT Standards? + +Non-Standardised NFT systems have caused concerns and issues across a number of areas in other eco-systems. The lack of interoperable standards present numerous awkward and complicated experiences and in some eco-systems has resulted in countless verification and API issues that segment the NFT community. + +Early safeguards are possible to put in place to support a more secure and interoperable eco-system that puts creators and buyer security at the forefront, providing developers and dApp makers the grounds to build a more connected and consistent eco-system. + +With the IOTA Tokenisation Framework in its infancy, the early adoption of an iNFT Standard can support a safer, more secure environment for creators and dApp providers, to allow an easily interoperable experience through-out the IOTA eco-system. + +In this document we will present the iNFT Standard - IRC2. + +## The Aim + +This document aims to support a universal system that can provide dApp developers and creators with an interoperable foundation of standards to support ease-of-adoption and a connected NFT eco-system. To bring value, security, trust, and interoperability. + +Focusing on the primary use case for digital assets as NFTs, this defined standard supports key aspects in the creation, trade, and exchange of different assets with a focus on image, video, audio, and 3d asset file types. + +To support an easy-to-implement system the iNFT Standard supports: + +- **Policy ID** system should define NFT origins by creatorID and policyID for authenticity and verification within the iNFT space. +- **Policy Registry** system to allow open-source verifiable collection details. +- **Creator Royalty** System that can support universal creator royalties throughout the eco-system. +- **NFT Schema Standard** allowing for easily definable keys and values for ease-of-integration. +- **Version Modelling** to allow for easy updates as well as backwards compatibility. +- **Modular System Design** to provide developers freedom to utilise only required elements, as well as for future standards expansion beyond the existing standard model. + +The standard provides the foundation for future expansion, supporting a modular design to provide an opportunity for selective integration, as well as further use case expansion through additional modules as time goes by. + +## The Standards + +### Policy ID + +The IOTA Tokenisation Framework allows for a unique and robust solution when defining the identity of a collection. The integration of such a system can support verification of the origins of the creation of an NFT. For example, an artist creating a collection of works that will be labelled under a single collection. This allows for ease of verification for buyers and 3rd party application developers to provide an easily observable system of authenticity for users navigating the iNFT space. + +The standard is defined utilising the creation mechanism for NFTs. + +`creatorID` is already defined in the framework, allowing every NFT created from the same source to be easily defined. + +Each created NFT is also defined by a unique **UTXO identifier.** + +With the unique inclusion of UTXO addresses in the NFT framework, this allows the ability to define a **collection UTXO** that can subsequently mint each unique NFT within that collection. + +This is defined as the `policyId` + +the policyId will act as a unique identifier for the collection and would allow the `policyNft` to control the NFTs in a collection. This allows for unprecedented amounts of control where you can lock a collection for some time. Transfer the ownership of an entire collection via transfer of the `policyNft`. + +A creator should define the UTXO of their collection NFT as the sole minting source of an entire collection that is the 'policyId'. + +A creator may choose to burn the collection NFT on completion of minting or retain the collection NFT to add further NFTs to the collection over time. + +The UTXO of the collection NFT acts as the `policyId` for the collection and can be used in dApps to define the verified origin of an NFT. + +To call the defined `policyID` you should request the `policyID` UTXO of the collection NFT and resolve to the Policy Registry for human identifiable verification. + +### Policy Registry + +An open-source human identifiable registry of UTXO `policyId`s will be established to allow individuals the ability to support API integrations into dApps and websites that can support the connection of human identifiable names to `policyID`s. + +A creator should register their `policyID` UTXO to a human identifiable value (`policyName`) as a defined unique and verified collection. + +Reference to their `policyID` should be publicly visible on an official website or social media page. + +A `policyName` must be a unique string. + +An open-source committee must humanly verify the collection input to the registry. + +The Policy Registry has to be kept off-chain, but a commitment to its current state has to be stored in an output. + +An API to support the integration of the policy registry into dApps can be called from the open-source repository. + +When submitting a `policyID` to the registry the following keys should be defined. + +- `creatorID` must be the original creatorID UTXO string +- `policyId` must be the unique UTXO string of the collection NFT +- `policyName` must be a unique human identifiable string +- `websiteUrl` must be an official website or social media page url that illustrates publicly the `policyId` + +```json +{ + "registration": { + "creatorId": "s345d6f7g8h9ji07gy8h99", + "policyId": "a3s45dr6ft7gy87hu98ji09", + "policyName": "My iNFT Collection", + "websiteUrl": "https://mywebsite.com/policyid" + } +} +``` + +### Creator Royalties + +A system to support interoperable royalty payments across dApps. Allowing universal secondary market reward systems to be integrated through-out the eco-system. Integration of such systems is at the choosing of the dApp developer but is encouraged to support creator royalties. + +Within the NFT creation process a creator must define the two (or more) keys: +`royaltyAddress` - must be defined as a valid iota1 address string +`royaltyPercentage` must be defined as a numeric decimal from 0-1 + +```json +// royaltyAddress must be a valid iota1 address where royalties will be sent too +// royaltyPercentage must be a numeric decimal representative of the percentage required ie. 0.05=5% + +"royaltyAddress": "iota1f8a76dg678....", +"royaltyPercentage": "0.05", +``` + +In the event there are further royalty, multiple royalty addresses could be used in the form of an object where the address and percentage are mapped in a key value format inside the `royalties` field. + +```json +{ + ... + "royalties": { + "iota1...a": 0.25, + "iota1...b": 0.25, + "iota1...c": 0.25, + "iota1...d": 0.25 + } +} +``` + +The total decimal sum of all `royaltyPercentage` must never exceed 1 and is recommended not to exceed 0.5 + +Calling the `royaltyAddress` and `royaltyPercentage` in the Smart Contract used for transfer and trade should be defined as: + +If `royaltyAddress` exists only one royalty is paid out, if `royalties` exists, it is iterated over the keys and then all the royalties are paid out till there are no keys left to iterate over. + + + +### NFT Schema + +For ease of development and interoperability between applications within the eco-system an extendable schema standard is defined to support ease of integration of NFTs for developers. + +Each schema is defined by three main keys: + +- `standard` – the standard model +- `schema` – the defined schema type +- `version` – the version of the standard + +**Universal schema** +Each NFT schema should consist of a collection of universal keys to define key properties of the NFT + +The standard defined is: +`IRC2` + +The schema is defined by one of the following +`image` – ie. jpeg, gif, png, bmp, webp +`video` – ie. avi, mp4, webm +`audio` – ie. wav, mp3 +`3dAsset` – ie. obj, fbx, glb +`document` – ie. doc, xls, pdf, txt + + +The version is defined by the version number used preceded with the letter v, current version: +`v1.0` + +```json +// Define the standard, the type, and the version +{ + "IRC2, image, v1.0": + { +``` + +Additional keys that must be included in every NFT schema: +`nftId` – UTXO string of the NFT +`issuerId` – UTXO string of the issuer of the NFT +`tokenURI` – url pointing to the NFT file location + +```json +{ + "IRC2, image, v1.0": { + // define the required utxo identifier for the NFT, + // the utxo identitfier for the issuer and the file location + "nftId": "vt7rye8tgvr7e89w", + "issuerId": "fy8e9wryf8e9wyf8e9w", + "tokenURI": "https://mywebsite.com/myfile.png", +``` + +Optional, but recommended keys, that may be included in NFT schema include: +`tokenName` – alphanumeric text string defining the human identifiable name for the NFT +`policyId` – UTXO string of the policy NFT +`policyName` – alphanumeric text string defining the human identifiable collection name +`royaltyAddress` – iota1 address string of target royalty payments +`royaltyPercentage` – numeric decimal defining the royalty percentage +`issuerName` – alphanumeric text string to define the human identifiable name of the creator +`description` – alphanumeric text string to define a basic description of the NFT + +```json +{ + "IRC2, image, v1.0": { + // define the required utxo identifier for the NFT, + // the utxo identitfier for the issuer and the file location + "nftId": "vt7rye8tgvr7e89w", + "issuerId": "fy8e9wryf8e9wyf8e9w", + "tokenURI": "https://mywebsite.com/myfile.png", + + // define the optional keys for the base schema + "tokenName": "My NFT #0001", + "policyId": "7f9e0rwf7e90w", + "policyName": "My Collection of Art", + "royaltyAddress": "iota178d97....", + "royaltyPercentage": 0.05, + "issuerName": "My Artist Name", + "description": "A little information about my NFT collection", +``` + +In addition to the required and recommended schema, the inclusion of `attributes` allows for versatile expansion for NFT metadata. + +`attributes` are defined as a unique key and string that can be referenced in dApps to display metadata as required. + +```json +{ + "IRC2, image, v1.0": { + // define the required utxo identifier for the NFT, + // the utxo identitfier for the issuer and the file location + "nftId": "vt7rye8tgvr7e89w", + "issuerId": "fy8e9wryf8e9wyf8e9w", + "tokenURI": "https://mywebsite.com/myfile.png", + + // define the optional keys for the base schema + "tokenName": "My NFT #0001", + "policyId": "7f9e0rwf7e90w", + "policyName": "My Collection of Art", + "royaltyAddress": "iota178d97....", + "royaltyPercentage": 0.05, + "issuerName": "My Artist Name", + "description": "A little information about my NFT collection", + + // define optional attributes for NFT metadata + "attributes": { + "Background": "Purple", + "Element": "Water", + "Attack": "150", + "Health": "500" + } + } +} +``` + + +## Interoperable Standards + +For a unified iNFT eco-system the standards have been designed to support ease of integration and cross-compatibility of NFTs throughout the IOTA network. Observations of undefined standards in other eco-systems has illustrated the importance of such developments in the early stages of the technology. Simple defined keys such as `nftId`, instead of `assetId` or `tokenId`, or `tokenURI`, instead of `nftUrl` or `fileLocation`can support a much more interoperable experience for creators and dApp developers with everyone working from the same foundations. + +Supporting creators is also a key element in driving adoption for the technology, royalty integrations vary substantially in other blockchain eco-systems which remains a challenge for both 3rd party applications and creators in sustaining a consistent and reliable eco-system across different applications. + +This standard also supports expansion, backwards compatibility, and a universal guideline for the eco-system to develop with. Allowing an immediate interoperable environment that can support ease-of-adoption in the early stages of iNFTs, whilst continually supporting feature expansion and future development. + +### Versioning + +Expanding use-cases in the NFT space will present multiple requirements for different standards and schemas to be developed and over time alterations and updates will be presented to support an evolving technology and future developments. + +Version is introduced from the start to allow dApp developers and creators to maintain backwards compatibility with differing versions of the standard, which can be defined as a numeric value proceeded with the letter v. + +Current version `v1.0` + +### Modular Structure Expansion + +A modular structure to the standard has been created to support use case expansion, file type extension, standards catalogue. Allowing creators to utilise minimalist implementations as well as the more advanced expanded standards. + + +### Copyright + +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 74b233ad32a63c82469e061d4cb69d2824bffac4 Mon Sep 17 00:00:00 2001 From: Merul <69296233+coodos@users.noreply.github.com> Date: Fri, 4 Mar 2022 19:29:19 +0530 Subject: [PATCH 02/28] chore: update IRC-2 TIP --- tips/TIP-0027/tip-0027.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/tips/TIP-0027/tip-0027.md b/tips/TIP-0027/tip-0027.md index 1dabc1fee..c2cb6614c 100644 --- a/tips/TIP-0027/tip-0027.md +++ b/tips/TIP-0027/tip-0027.md @@ -1,8 +1,8 @@ --- tip: 27 title: IOTA NFT Standard IRC2 -description: Define NFT metadata standard, collection registry and creator royalties -author: Adam (@AdamCroply) , Merul (@coodos) +description: Define NFT metadata standard, policy registry and creator royalties +author: Adam Eunson (@AdamCroply) , Merul Dhiman (@coodos) discussions-to: https://github.com/iotaledger/tips/discussions/59 status: Draft type: Standards @@ -87,7 +87,7 @@ An API to support the integration of the policy registry into dApps can be calle When submitting a `policyID` to the registry the following keys should be defined. -- `creatorID` must be the original creatorID UTXO string +- `issuerId` must be the original creatorID UTXO string - `policyId` must be the unique UTXO string of the collection NFT - `policyName` must be a unique human identifiable string - `websiteUrl` must be an official website or social media page url that illustrates publicly the `policyId` @@ -95,7 +95,7 @@ When submitting a `policyID` to the registry the following keys should be define ```json { "registration": { - "creatorId": "s345d6f7g8h9ji07gy8h99", + "issuerId": "s345d6f7g8h9ji07gy8h99", "policyId": "a3s45dr6ft7gy87hu98ji09", "policyName": "My iNFT Collection", "websiteUrl": "https://mywebsite.com/policyid" From eb0f15c61e0cd59cf0ae26870dca6c694d6a249f Mon Sep 17 00:00:00 2001 From: Adamski <61834907+AdamCroply@users.noreply.github.com> Date: Fri, 4 Mar 2022 15:06:00 +0100 Subject: [PATCH 03/28] Update tip-0027.md --- tips/TIP-0027/tip-0027.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/tips/TIP-0027/tip-0027.md b/tips/TIP-0027/tip-0027.md index c2cb6614c..48facf0a3 100644 --- a/tips/TIP-0027/tip-0027.md +++ b/tips/TIP-0027/tip-0027.md @@ -34,7 +34,7 @@ Focusing on the primary use case for digital assets as NFTs, this defined standa To support an easy-to-implement system the iNFT Standard supports: -- **Policy ID** system should define NFT origins by creatorID and policyID for authenticity and verification within the iNFT space. +- **Policy ID** system should define NFT origins by issuerId and policyId for authenticity and verification within the iNFT space. - **Policy Registry** system to allow open-source verifiable collection details. - **Creator Royalty** System that can support universal creator royalties throughout the eco-system. - **NFT Schema Standard** allowing for easily definable keys and values for ease-of-integration. @@ -51,7 +51,7 @@ The IOTA Tokenisation Framework allows for a unique and robust solution when def The standard is defined utilising the creation mechanism for NFTs. -`creatorID` is already defined in the framework, allowing every NFT created from the same source to be easily defined. +`issuerId` is already defined in the framework, allowing every NFT created from the same source to be easily defined. Each created NFT is also defined by a unique **UTXO identifier.** @@ -67,15 +67,15 @@ A creator may choose to burn the collection NFT on completion of minting or reta The UTXO of the collection NFT acts as the `policyId` for the collection and can be used in dApps to define the verified origin of an NFT. -To call the defined `policyID` you should request the `policyID` UTXO of the collection NFT and resolve to the Policy Registry for human identifiable verification. +To call the defined `policyId` you should request the `policyId` UTXO of the collection NFT and resolve to the Policy Registry for human identifiable verification. ### Policy Registry -An open-source human identifiable registry of UTXO `policyId`s will be established to allow individuals the ability to support API integrations into dApps and websites that can support the connection of human identifiable names to `policyID`s. +An open-source human identifiable registry of UTXO `policyId`s will be established to allow individuals the ability to support API integrations into dApps and websites that can support the connection of human identifiable names to `policyId`s. -A creator should register their `policyID` UTXO to a human identifiable value (`policyName`) as a defined unique and verified collection. +A creator should register their `policyId` UTXO to a human identifiable value (`policyName`) as a defined unique and verified collection. -Reference to their `policyID` should be publicly visible on an official website or social media page. +Reference to their `policyId` should be publicly visible on an official website or social media page. A `policyName` must be a unique string. @@ -85,7 +85,7 @@ The Policy Registry has to be kept off-chain, but a commitment to its current st An API to support the integration of the policy registry into dApps can be called from the open-source repository. -When submitting a `policyID` to the registry the following keys should be defined. +When submitting a `policyId` to the registry the following keys should be defined. - `issuerId` must be the original creatorID UTXO string - `policyId` must be the unique UTXO string of the collection NFT From 8fd365510502631327acdbfbb3cfabf8fee52240 Mon Sep 17 00:00:00 2001 From: Adamski <61834907+AdamCroply@users.noreply.github.com> Date: Fri, 4 Mar 2022 17:39:41 +0100 Subject: [PATCH 04/28] Update tip-0027.md --- tips/TIP-0027/tip-0027.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tips/TIP-0027/tip-0027.md b/tips/TIP-0027/tip-0027.md index 48facf0a3..008f68a24 100644 --- a/tips/TIP-0027/tip-0027.md +++ b/tips/TIP-0027/tip-0027.md @@ -87,8 +87,8 @@ An API to support the integration of the policy registry into dApps can be calle When submitting a `policyId` to the registry the following keys should be defined. -- `issuerId` must be the original creatorID UTXO string -- `policyId` must be the unique UTXO string of the collection NFT +- `issuerId` must be the original issuerId UTXO string +- `policyId` must be the unique UTXO string of the policyNFT - `policyName` must be a unique human identifiable string - `websiteUrl` must be an official website or social media page url that illustrates publicly the `policyId` From 32b67343c96221579627c7152fc12caec86f44fd Mon Sep 17 00:00:00 2001 From: Adamski <61834907+AdamCroply@users.noreply.github.com> Date: Fri, 4 Mar 2022 17:45:16 +0100 Subject: [PATCH 05/28] Update tip-0027.md --- tips/TIP-0027/tip-0027.md | 49 +++++++++++++++++++++++++-------------- 1 file changed, 31 insertions(+), 18 deletions(-) diff --git a/tips/TIP-0027/tip-0027.md b/tips/TIP-0027/tip-0027.md index 008f68a24..a036b5771 100644 --- a/tips/TIP-0027/tip-0027.md +++ b/tips/TIP-0027/tip-0027.md @@ -151,22 +151,29 @@ Each schema is defined by three main keys: - `schema` – the defined schema type - `version` – the version of the standard + **Universal schema** Each NFT schema should consist of a collection of universal keys to define key properties of the NFT The standard defined is: -`IRC2` -The schema is defined by one of the following -`image` – ie. jpeg, gif, png, bmp, webp -`video` – ie. avi, mp4, webm -`audio` – ie. wav, mp3 -`3dAsset` – ie. obj, fbx, glb -`document` – ie. doc, xls, pdf, txt +- `IRC2` + + +The schema is defined by one of the following: + +- `image` – ie. jpeg, gif, png, bmp, webp +- `video` – ie. avi, mp4, webm +- `audio` – ie. wav, mp3 +- `3dAsset` – ie. obj, fbx, glb +- `document` – ie. doc, xls, pdf, txt + The version is defined by the version number used preceded with the letter v, current version: -`v1.0` + +- `v1.0` + ```json // Define the standard, the type, and the version @@ -176,9 +183,10 @@ The version is defined by the version number used preceded with the letter v, cu ``` Additional keys that must be included in every NFT schema: -`nftId` – UTXO string of the NFT -`issuerId` – UTXO string of the issuer of the NFT -`tokenURI` – url pointing to the NFT file location +- `nftId` – UTXO string of the NFT +- `issuerId` – UTXO string of the issuer of the NFT +- `tokenURI` – url pointing to the NFT file location + ```json { @@ -190,14 +198,16 @@ Additional keys that must be included in every NFT schema: "tokenURI": "https://mywebsite.com/myfile.png", ``` + Optional, but recommended keys, that may be included in NFT schema include: -`tokenName` – alphanumeric text string defining the human identifiable name for the NFT -`policyId` – UTXO string of the policy NFT -`policyName` – alphanumeric text string defining the human identifiable collection name -`royaltyAddress` – iota1 address string of target royalty payments -`royaltyPercentage` – numeric decimal defining the royalty percentage -`issuerName` – alphanumeric text string to define the human identifiable name of the creator -`description` – alphanumeric text string to define a basic description of the NFT +- `tokenName` – alphanumeric text string defining the human identifiable name for the NFT +- `policyId` – UTXO string of the policy NFT +- `policyName` – alphanumeric text string defining the human identifiable collection name +- `royaltyAddress` – iota1 address string of target royalty payments +- `royaltyPercentage` – numeric decimal defining the royalty percentage +- `issuerName` – alphanumeric text string to define the human identifiable name of the creator +- `description` – alphanumeric text string to define a basic description of the NFT + ```json { @@ -218,10 +228,13 @@ Optional, but recommended keys, that may be included in NFT schema include: "description": "A little information about my NFT collection", ``` + In addition to the required and recommended schema, the inclusion of `attributes` allows for versatile expansion for NFT metadata. + `attributes` are defined as a unique key and string that can be referenced in dApps to display metadata as required. + ```json { "IRC2, image, v1.0": { From 066e1cb833431cd7e2cbbda9fd597120c94e7403 Mon Sep 17 00:00:00 2001 From: Merul <69296233+coodos@users.noreply.github.com> Date: Wed, 9 Mar 2022 17:05:40 +0530 Subject: [PATCH 06/28] chore: bump standard name and commit suggested changes --- tips/TIP-0027/tip-0027.md | 60 +++++++++++++++++++++++---------------- 1 file changed, 35 insertions(+), 25 deletions(-) diff --git a/tips/TIP-0027/tip-0027.md b/tips/TIP-0027/tip-0027.md index a036b5771..fe34a60d2 100644 --- a/tips/TIP-0027/tip-0027.md +++ b/tips/TIP-0027/tip-0027.md @@ -1,20 +1,20 @@ --- tip: 27 -title: IOTA NFT Standard IRC2 +title: IOTA NFT Standard IRC27 description: Define NFT metadata standard, policy registry and creator royalties author: Adam Eunson (@AdamCroply) , Merul Dhiman (@coodos) discussions-to: https://github.com/iotaledger/tips/discussions/59 status: Draft type: Standards -layer: Core +layer: IRC created: 2022-03-04 --- -# iNFT Standard - IRC2 +# iNFT Standard - IRC27 ## Introduction -**IRC2** is a series of standards to support interoperable and universal NFT systems throughout the IOTA eco-system, to provide a more robust and secure system for creators and buyers. +**IRC27** is a series of standards to support interoperable and universal NFT systems throughout the IOTA eco-system, to provide a more robust and secure system for creators and buyers. ## Why iNFT Standards? @@ -24,7 +24,7 @@ Early safeguards are possible to put in place to support a more secure and inter With the IOTA Tokenisation Framework in its infancy, the early adoption of an iNFT Standard can support a safer, more secure environment for creators and dApp providers, to allow an easily interoperable experience through-out the IOTA eco-system. -In this document we will present the iNFT Standard - IRC2. +In this document we will present the iNFT Standard - IRC27. ## The Aim @@ -53,11 +53,9 @@ The standard is defined utilising the creation mechanism for NFTs. `issuerId` is already defined in the framework, allowing every NFT created from the same source to be easily defined. -Each created NFT is also defined by a unique **UTXO identifier.** +Each NFT in the IOTA Tokenization Framework has its own unique address, that allows the ability to define a **collection UTXO** that can subsequently mint each unique NFT within that collection. -With the unique inclusion of UTXO addresses in the NFT framework, this allows the ability to define a **collection UTXO** that can subsequently mint each unique NFT within that collection. - -This is defined as the `policyId` +The `nftId` of a collection NFT is defined as the `policyId`. the policyId will act as a unique identifier for the collection and would allow the `policyNft` to control the NFTs in a collection. This allows for unprecedented amounts of control where you can lock a collection for some time. Transfer the ownership of an entire collection via transfer of the `policyNft`. @@ -107,16 +105,17 @@ When submitting a `policyId` to the registry the following keys should be define A system to support interoperable royalty payments across dApps. Allowing universal secondary market reward systems to be integrated through-out the eco-system. Integration of such systems is at the choosing of the dApp developer but is encouraged to support creator royalties. -Within the NFT creation process a creator must define the two (or more) keys: -`royaltyAddress` - must be defined as a valid iota1 address string -`royaltyPercentage` must be defined as a numeric decimal from 0-1 - -```json -// royaltyAddress must be a valid iota1 address where royalties will be sent too -// royaltyPercentage must be a numeric decimal representative of the percentage required ie. 0.05=5% +royalty addresses can be defined inside the royalty addresses +```js +// the key inside the royalties object must be a valid iota1 address where royalties will be sent too +// the value must be a numeric decimal representative of the percentage required ie. 0.05=5% -"royaltyAddress": "iota1f8a76dg678....", -"royaltyPercentage": "0.05", +{ + ... + "royalties": { + "iota1...a": 0.5 + } +} ``` In the event there are further royalty, multiple royalty addresses could be used in the form of an object where the address and percentage are mapped in a key value format inside the `royalties` field. @@ -137,7 +136,7 @@ The total decimal sum of all `royaltyPercentage` must never exceed 1 and is reco Calling the `royaltyAddress` and `royaltyPercentage` in the Smart Contract used for transfer and trade should be defined as: -If `royaltyAddress` exists only one royalty is paid out, if `royalties` exists, it is iterated over the keys and then all the royalties are paid out till there are no keys left to iterate over. +if `royalties` exists, it is iterated over the keys and then all the royalties are paid out till there are no keys left to iterate over. @@ -157,7 +156,7 @@ Each NFT schema should consist of a collection of universal keys to define key p The standard defined is: -- `IRC2` +- `IRC27` The schema is defined by one of the following: @@ -178,8 +177,10 @@ The version is defined by the version number used preceded with the letter v, cu ```json // Define the standard, the type, and the version { - "IRC2, image, v1.0": - { + "standard" : "IRC27", + "type": "image", + "version": "v1.0", + "object": { ``` Additional keys that must be included in every NFT schema: @@ -190,7 +191,10 @@ Additional keys that must be included in every NFT schema: ```json { - "IRC2, image, v1.0": { + "standard" : "IRC27", + "type": "image", + "version": "v1.0", + "object": { // define the required utxo identifier for the NFT, // the utxo identitfier for the issuer and the file location "nftId": "vt7rye8tgvr7e89w", @@ -211,7 +215,10 @@ Optional, but recommended keys, that may be included in NFT schema include: ```json { - "IRC2, image, v1.0": { + "standard" : "IRC27", + "type": "image", + "version": "v1.0", + "object": { // define the required utxo identifier for the NFT, // the utxo identitfier for the issuer and the file location "nftId": "vt7rye8tgvr7e89w", @@ -237,7 +244,10 @@ In addition to the required and recommended schema, the inclusion of `attributes ```json { - "IRC2, image, v1.0": { + "standard" : "IRC27", + "type": "image", + "version": "v1.0", + "object": { // define the required utxo identifier for the NFT, // the utxo identitfier for the issuer and the file location "nftId": "vt7rye8tgvr7e89w", From ecac842cb8cf7ba14b97779c693297a43a5361b3 Mon Sep 17 00:00:00 2001 From: Adamski <61834907+AdamCroply@users.noreply.github.com> Date: Wed, 9 Mar 2022 13:22:13 +0100 Subject: [PATCH 07/28] Updated Section headers Added TIP-1 headers to the sections and re-ordered out of place segments. --- tips/TIP-0027/tip-0027.md | 45 ++++++++++++++++++++++++++++----------- 1 file changed, 32 insertions(+), 13 deletions(-) diff --git a/tips/TIP-0027/tip-0027.md b/tips/TIP-0027/tip-0027.md index fe34a60d2..5f3b082d2 100644 --- a/tips/TIP-0027/tip-0027.md +++ b/tips/TIP-0027/tip-0027.md @@ -10,23 +10,17 @@ layer: IRC created: 2022-03-04 --- -# iNFT Standard - IRC27 -## Introduction +# iNFT Standard - IRC27 -**IRC27** is a series of standards to support interoperable and universal NFT systems throughout the IOTA eco-system, to provide a more robust and secure system for creators and buyers. -## Why iNFT Standards? +## Abstract -Non-Standardised NFT systems have caused concerns and issues across a number of areas in other eco-systems. The lack of interoperable standards present numerous awkward and complicated experiences and in some eco-systems has resulted in countless verification and API issues that segment the NFT community. -Early safeguards are possible to put in place to support a more secure and interoperable eco-system that puts creators and buyer security at the forefront, providing developers and dApp makers the grounds to build a more connected and consistent eco-system. +**IRC27** is a series of standards to support interoperable and universal NFT systems throughout the IOTA eco-system, to provide a more robust and secure system for creators and buyers. -With the IOTA Tokenisation Framework in its infancy, the early adoption of an iNFT Standard can support a safer, more secure environment for creators and dApp providers, to allow an easily interoperable experience through-out the IOTA eco-system. -In this document we will present the iNFT Standard - IRC27. - -## The Aim +### Introduction This document aims to support a universal system that can provide dApp developers and creators with an interoperable foundation of standards to support ease-of-adoption and a connected NFT eco-system. To bring value, security, trust, and interoperability. @@ -43,7 +37,23 @@ To support an easy-to-implement system the iNFT Standard supports: The standard provides the foundation for future expansion, supporting a modular design to provide an opportunity for selective integration, as well as further use case expansion through additional modules as time goes by. -## The Standards + +## Motivation + + +### Why iNFT Standards? + +Non-Standardised NFT systems have caused concerns and issues across a number of areas in other eco-systems. The lack of interoperable standards present numerous awkward and complicated experiences and in some eco-systems has resulted in countless verification and API issues that segment the NFT community. + +Early safeguards are possible to put in place to support a more secure and interoperable eco-system that puts creators and buyer security at the forefront, providing developers and dApp makers the grounds to build a more connected and consistent eco-system. + +With the IOTA Tokenisation Framework in its infancy, the early adoption of an iNFT Standard can support a safer, more secure environment for creators and dApp providers, to allow an easily interoperable experience through-out the IOTA eco-system. + +In this document we will present the iNFT Standard - IRC27. + + +## Specification + ### Policy ID @@ -275,7 +285,10 @@ In addition to the required and recommended schema, the inclusion of `attributes ``` -## Interoperable Standards +## Rationale + + +### Interoperable Standards For a unified iNFT eco-system the standards have been designed to support ease of integration and cross-compatibility of NFTs throughout the IOTA network. Observations of undefined standards in other eco-systems has illustrated the importance of such developments in the early stages of the technology. Simple defined keys such as `nftId`, instead of `assetId` or `tokenId`, or `tokenURI`, instead of `nftUrl` or `fileLocation`can support a much more interoperable experience for creators and dApp developers with everyone working from the same foundations. @@ -283,6 +296,10 @@ Supporting creators is also a key element in driving adoption for the technology This standard also supports expansion, backwards compatibility, and a universal guideline for the eco-system to develop with. Allowing an immediate interoperable environment that can support ease-of-adoption in the early stages of iNFTs, whilst continually supporting feature expansion and future development. + +## Backwards Compatibility + + ### Versioning Expanding use-cases in the NFT space will present multiple requirements for different standards and schemas to be developed and over time alterations and updates will be presented to support an evolving technology and future developments. @@ -296,6 +313,8 @@ Current version `v1.0` A modular structure to the standard has been created to support use case expansion, file type extension, standards catalogue. Allowing creators to utilise minimalist implementations as well as the more advanced expanded standards. -### Copyright + +## Copyright + Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From a1d9bd5c4f31e3b5645e8fed8726fd027849c818 Mon Sep 17 00:00:00 2001 From: Adamski <61834907+AdamCroply@users.noreply.github.com> Date: Wed, 9 Mar 2022 13:30:50 +0100 Subject: [PATCH 08/28] Added Versions as TIPs comment Added a comment for future versioning to be submitted as a separate TIP --- tips/TIP-0027/tip-0027.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tips/TIP-0027/tip-0027.md b/tips/TIP-0027/tip-0027.md index 5f3b082d2..6816f0a50 100644 --- a/tips/TIP-0027/tip-0027.md +++ b/tips/TIP-0027/tip-0027.md @@ -304,7 +304,7 @@ This standard also supports expansion, backwards compatibility, and a universal Expanding use-cases in the NFT space will present multiple requirements for different standards and schemas to be developed and over time alterations and updates will be presented to support an evolving technology and future developments. -Version is introduced from the start to allow dApp developers and creators to maintain backwards compatibility with differing versions of the standard, which can be defined as a numeric value proceeded with the letter v. +Version is introduced from the start to allow dApp developers and creators to maintain backwards compatibility with differing versions of the standard, which can be defined as a numeric value proceeded with the letter v. All future versions will be submitted as separate TIPs. Current version `v1.0` From 4d5ea15b4db939d9d39c8f6207d5e52c78c969dc Mon Sep 17 00:00:00 2001 From: Merul <69296233+coodos@users.noreply.github.com> Date: Tue, 29 Mar 2022 22:01:48 +0530 Subject: [PATCH 09/28] docs: added description for royalty system --- tips/TIP-0027/tip-0027.md | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/tips/TIP-0027/tip-0027.md b/tips/TIP-0027/tip-0027.md index 6816f0a50..21aa3a9d5 100644 --- a/tips/TIP-0027/tip-0027.md +++ b/tips/TIP-0027/tip-0027.md @@ -61,13 +61,13 @@ The IOTA Tokenisation Framework allows for a unique and robust solution when def The standard is defined utilising the creation mechanism for NFTs. -`issuerId` is already defined in the framework, allowing every NFT created from the same source to be easily defined. +`issuerId` (referred to as [Issuer Block in TIP-18](https://github.com/iotaledger/tips/pull/38)) is already defined in the framework, allowing every NFT created from the same source to be easily defined. Each NFT in the IOTA Tokenization Framework has its own unique address, that allows the ability to define a **collection UTXO** that can subsequently mint each unique NFT within that collection. The `nftId` of a collection NFT is defined as the `policyId`. -the policyId will act as a unique identifier for the collection and would allow the `policyNft` to control the NFTs in a collection. This allows for unprecedented amounts of control where you can lock a collection for some time. Transfer the ownership of an entire collection via transfer of the `policyNft`. +the policyId will act as a unique identifier for the collection and would allow the `policyNft` to control the NFTs in a collection. This allows for unprecedented amounts of control where you can lock a collection for some time. It also allows for the ability to transfer the `policyNft` (parent NFT of all the NFTs minted within a collection) on transfer of which the new holder will be able to add NFTs to the collection, lock the collection etc. A creator should define the UTXO of their collection NFT as the sole minting source of an entire collection that is the 'policyId'. @@ -87,9 +87,9 @@ Reference to their `policyId` should be publicly visible on an official website A `policyName` must be a unique string. -An open-source committee must humanly verify the collection input to the registry. +Proposed as a part of this TIP is a policy registry, the policy registry will be similar to [CNFT Policy IDs Repo](https://github.com/Cardano-NFTs/policyIDs) where a collection creator can open a pull request with their socials, policy ID and collection name and a committe of human verifiers will approve or reject the colleciton. Apart from being used for NFTs the registry will also serve as a token registry with similar mechanics for human verification. Before a merge to the registry there must be atleat 5 approving reviews by human validators. And CI checks to ensure that the socials contain the policyID and the collection name isn't already taken, another cautionary check for too similar of a name to an existing collection can exist, for example a CI check that raises an warning for a collection named "TanglleLabs" when "TangleLabs" is already a part of the registry, the rationale behind this check is to mitigate fake collections for popping up which steal the IP from another colleciton and use a very similar name. -The Policy Registry has to be kept off-chain, but a commitment to its current state has to be stored in an output. +The Committe of human validators will be managed and compensated with a DAO infratructure where we can setup multisig requirements for any vote to conclude. An API to support the integration of the policy registry into dApps can be called from the open-source repository. @@ -195,7 +195,6 @@ The version is defined by the version number used preceded with the letter v, cu Additional keys that must be included in every NFT schema: - `nftId` – UTXO string of the NFT -- `issuerId` – UTXO string of the issuer of the NFT - `tokenURI` – url pointing to the NFT file location @@ -208,7 +207,6 @@ Additional keys that must be included in every NFT schema: // define the required utxo identifier for the NFT, // the utxo identitfier for the issuer and the file location "nftId": "vt7rye8tgvr7e89w", - "issuerId": "fy8e9wryf8e9wyf8e9w", "tokenURI": "https://mywebsite.com/myfile.png", ``` @@ -232,7 +230,6 @@ Optional, but recommended keys, that may be included in NFT schema include: // define the required utxo identifier for the NFT, // the utxo identitfier for the issuer and the file location "nftId": "vt7rye8tgvr7e89w", - "issuerId": "fy8e9wryf8e9wyf8e9w", "tokenURI": "https://mywebsite.com/myfile.png", // define the optional keys for the base schema @@ -261,7 +258,6 @@ In addition to the required and recommended schema, the inclusion of `attributes // define the required utxo identifier for the NFT, // the utxo identitfier for the issuer and the file location "nftId": "vt7rye8tgvr7e89w", - "issuerId": "fy8e9wryf8e9wyf8e9w", "tokenURI": "https://mywebsite.com/myfile.png", // define the optional keys for the base schema From 5e1939e6bf39e4e351aa7b198fac3b947f91e00a Mon Sep 17 00:00:00 2001 From: Merul <69296233+coodos@users.noreply.github.com> Date: Tue, 29 Mar 2022 22:10:28 +0530 Subject: [PATCH 10/28] Create irc27.schema.json --- tips/TIP-0027/irc27.schema.json | 40 +++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 tips/TIP-0027/irc27.schema.json diff --git a/tips/TIP-0027/irc27.schema.json b/tips/TIP-0027/irc27.schema.json new file mode 100644 index 000000000..171b3d125 --- /dev/null +++ b/tips/TIP-0027/irc27.schema.json @@ -0,0 +1,40 @@ +{ + // name of the standard + "standard" : "IRC27", + // type can be "image", "audio", "video", "document", "3dAsset" + "type": "image", + // Version of IRC27 standard being used + "version": "v1.0", + // Object containing the actual NFT metadata + "object": { + // define the required utxo identifier for the NFT, + // the utxo identitfier for the issuer and the file location + "nftId": "vt7rye8tgvr7e89w", + // Link to the file + "tokenURI": "https://mywebsite.com/myfile.png", + // define the optional keys for the base schema + + // name of the asset + "tokenName": "My NFT #0001", + // unique policy ID identifier + "policyId": "7f9e0rwf7e90w", + // human readable name for the collection + "policyName": "My Collection of Art", + // Key Value pair collection of royalty addresses, where address is mapped to the percentage of payout to be sent to it + "royalties": { + "iota1...a": 0.5, + "iota1...b": 0.5 + }, + // Name of the artist + "issuerName": "My Artist Name", + // description of the asset + "description": "A little information about my NFT collection", + // define optional attributes for NFT metadata + "attributes": { + "Background": "Purple", + "Element": "Water", + "Attack": "150", + "Health": "500" + } + } +} From 02c16b9ce5fec8a9e7969006c624d31e802f30b1 Mon Sep 17 00:00:00 2001 From: Merul <69296233+coodos@users.noreply.github.com> Date: Tue, 29 Mar 2022 22:13:00 +0530 Subject: [PATCH 11/28] chore: fix royalties part --- tips/TIP-0027/tip-0027.md | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/tips/TIP-0027/tip-0027.md b/tips/TIP-0027/tip-0027.md index 21aa3a9d5..9028a07c3 100644 --- a/tips/TIP-0027/tip-0027.md +++ b/tips/TIP-0027/tip-0027.md @@ -144,7 +144,6 @@ In the event there are further royalty, multiple royalty addresses could be used The total decimal sum of all `royaltyPercentage` must never exceed 1 and is recommended not to exceed 0.5 -Calling the `royaltyAddress` and `royaltyPercentage` in the Smart Contract used for transfer and trade should be defined as: if `royalties` exists, it is iterated over the keys and then all the royalties are paid out till there are no keys left to iterate over. @@ -215,8 +214,7 @@ Optional, but recommended keys, that may be included in NFT schema include: - `tokenName` – alphanumeric text string defining the human identifiable name for the NFT - `policyId` – UTXO string of the policy NFT - `policyName` – alphanumeric text string defining the human identifiable collection name -- `royaltyAddress` – iota1 address string of target royalty payments -- `royaltyPercentage` – numeric decimal defining the royalty percentage +- `royalties` - Object containing key value pair where payment address mapped to the payout percentage - `issuerName` – alphanumeric text string to define the human identifiable name of the creator - `description` – alphanumeric text string to define a basic description of the NFT @@ -236,8 +234,10 @@ Optional, but recommended keys, that may be included in NFT schema include: "tokenName": "My NFT #0001", "policyId": "7f9e0rwf7e90w", "policyName": "My Collection of Art", - "royaltyAddress": "iota178d97....", - "royaltyPercentage": 0.05, + "royalties": { + "iota1...a": 0.5, + "iota1...b": 0.5 + }, "issuerName": "My Artist Name", "description": "A little information about my NFT collection", ``` @@ -264,8 +264,10 @@ In addition to the required and recommended schema, the inclusion of `attributes "tokenName": "My NFT #0001", "policyId": "7f9e0rwf7e90w", "policyName": "My Collection of Art", - "royaltyAddress": "iota178d97....", - "royaltyPercentage": 0.05, + "royalties": { + "iota1...a": 0.5, + "iota1...b": 0.5 + }, "issuerName": "My Artist Name", "description": "A little information about my NFT collection", From f12a5eb404d691a0f691703293c14e709ceebe83 Mon Sep 17 00:00:00 2001 From: Adamski <61834907+AdamCroply@users.noreply.github.com> Date: Sat, 2 Apr 2022 12:30:00 +0200 Subject: [PATCH 12/28] Edited out the registry section and updates Removed the section on registry and updated a couple of sections. STILL NEED TO ADD A LINK TO TIP30 - upon submission. --- tips/TIP-0027/tip-0027.md | 41 ++++----------------------------------- 1 file changed, 4 insertions(+), 37 deletions(-) diff --git a/tips/TIP-0027/tip-0027.md b/tips/TIP-0027/tip-0027.md index 9028a07c3..96f41a8bb 100644 --- a/tips/TIP-0027/tip-0027.md +++ b/tips/TIP-0027/tip-0027.md @@ -29,7 +29,6 @@ Focusing on the primary use case for digital assets as NFTs, this defined standa To support an easy-to-implement system the iNFT Standard supports: - **Policy ID** system should define NFT origins by issuerId and policyId for authenticity and verification within the iNFT space. -- **Policy Registry** system to allow open-source verifiable collection details. - **Creator Royalty** System that can support universal creator royalties throughout the eco-system. - **NFT Schema Standard** allowing for easily definable keys and values for ease-of-integration. - **Version Modelling** to allow for easy updates as well as backwards compatibility. @@ -67,49 +66,17 @@ Each NFT in the IOTA Tokenization Framework has its own unique address, that all The `nftId` of a collection NFT is defined as the `policyId`. -the policyId will act as a unique identifier for the collection and would allow the `policyNft` to control the NFTs in a collection. This allows for unprecedented amounts of control where you can lock a collection for some time. It also allows for the ability to transfer the `policyNft` (parent NFT of all the NFTs minted within a collection) on transfer of which the new holder will be able to add NFTs to the collection, lock the collection etc. +The policyId will act as a unique identifier for the collection and would allow the `policyNft` to control the NFTs in a collection. This allows for unprecedented amounts of control where you can lock a collection for some time. It also allows for the ability to transfer the `policyNft` (parent NFT of all the NFTs minted within a collection) on transfer of which the new holder will be able to add NFTs to the collection, gaining control over ownership of the collection brand, but also with the ability to lock the collection by the destruction of the collection NFT. -A creator should define the UTXO of their collection NFT as the sole minting source of an entire collection that is the 'policyId'. +A creator should define the UTXO of their collection NFT as the sole minting source of an entire collection that is the `policyId`. A creator may choose to burn the collection NFT on completion of minting or retain the collection NFT to add further NFTs to the collection over time. -The UTXO of the collection NFT acts as the `policyId` for the collection and can be used in dApps to define the verified origin of an NFT. +The UTXO of the collection NFT, `nftId`, acts as the `policyId` for the collection and can be used in dApps to define the verified origin of an NFT. To call the defined `policyId` you should request the `policyId` UTXO of the collection NFT and resolve to the Policy Registry for human identifiable verification. -### Policy Registry - -An open-source human identifiable registry of UTXO `policyId`s will be established to allow individuals the ability to support API integrations into dApps and websites that can support the connection of human identifiable names to `policyId`s. - -A creator should register their `policyId` UTXO to a human identifiable value (`policyName`) as a defined unique and verified collection. - -Reference to their `policyId` should be publicly visible on an official website or social media page. - -A `policyName` must be a unique string. - -Proposed as a part of this TIP is a policy registry, the policy registry will be similar to [CNFT Policy IDs Repo](https://github.com/Cardano-NFTs/policyIDs) where a collection creator can open a pull request with their socials, policy ID and collection name and a committe of human verifiers will approve or reject the colleciton. Apart from being used for NFTs the registry will also serve as a token registry with similar mechanics for human verification. Before a merge to the registry there must be atleat 5 approving reviews by human validators. And CI checks to ensure that the socials contain the policyID and the collection name isn't already taken, another cautionary check for too similar of a name to an existing collection can exist, for example a CI check that raises an warning for a collection named "TanglleLabs" when "TangleLabs" is already a part of the registry, the rationale behind this check is to mitigate fake collections for popping up which steal the IP from another colleciton and use a very similar name. - -The Committe of human validators will be managed and compensated with a DAO infratructure where we can setup multisig requirements for any vote to conclude. - -An API to support the integration of the policy registry into dApps can be called from the open-source repository. - -When submitting a `policyId` to the registry the following keys should be defined. - -- `issuerId` must be the original issuerId UTXO string -- `policyId` must be the unique UTXO string of the policyNFT -- `policyName` must be a unique human identifiable string -- `websiteUrl` must be an official website or social media page url that illustrates publicly the `policyId` - -```json -{ - "registration": { - "issuerId": "s345d6f7g8h9ji07gy8h99", - "policyId": "a3s45dr6ft7gy87hu98ji09", - "policyName": "My iNFT Collection", - "websiteUrl": "https://mywebsite.com/policyid" - } -} -``` +To better serve the ecosystem with a single point of record for registered collections a Public Token Registry is defined in TIP30 and can be further read about here. ### Creator Royalties From ae29bcfa8e02903c0102904841c01e30134179ff Mon Sep 17 00:00:00 2001 From: Adamski <61834907+AdamCroply@users.noreply.github.com> Date: Sat, 2 Apr 2022 12:32:09 +0200 Subject: [PATCH 13/28] Edited tip30 to tip31 --- tips/TIP-0027/tip-0027.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tips/TIP-0027/tip-0027.md b/tips/TIP-0027/tip-0027.md index 96f41a8bb..d5f238c89 100644 --- a/tips/TIP-0027/tip-0027.md +++ b/tips/TIP-0027/tip-0027.md @@ -76,7 +76,7 @@ The UTXO of the collection NFT, `nftId`, acts as the `policyId` for the collecti To call the defined `policyId` you should request the `policyId` UTXO of the collection NFT and resolve to the Policy Registry for human identifiable verification. -To better serve the ecosystem with a single point of record for registered collections a Public Token Registry is defined in TIP30 and can be further read about here. +To better serve the ecosystem with a single point of record for registered collections a Public Token Registry is defined in TIP31 and can be further read about here. ### Creator Royalties From bf3120cc952639bff61b7e34234fc5a479168952 Mon Sep 17 00:00:00 2001 From: Adamski <61834907+AdamCroply@users.noreply.github.com> Date: Tue, 5 Apr 2022 17:39:49 +0200 Subject: [PATCH 14/28] Updated tip link and royalties Made a couple of minor edits --- tips/TIP-0027/tip-0027.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/tips/TIP-0027/tip-0027.md b/tips/TIP-0027/tip-0027.md index d5f238c89..885a2e303 100644 --- a/tips/TIP-0027/tip-0027.md +++ b/tips/TIP-0027/tip-0027.md @@ -76,7 +76,7 @@ The UTXO of the collection NFT, `nftId`, acts as the `policyId` for the collecti To call the defined `policyId` you should request the `policyId` UTXO of the collection NFT and resolve to the Policy Registry for human identifiable verification. -To better serve the ecosystem with a single point of record for registered collections a Public Token Registry is defined in TIP31 and can be further read about here. +To better serve the ecosystem with a single point of record for registered collections a Public Token Registry is defined in [IOTA Public Token Registry - TIP 33](https://github.com/iotaledger/tips/pull/--) where further reading can be found. ### Creator Royalties @@ -90,7 +90,7 @@ royalty addresses can be defined inside the royalty addresses { ... "royalties": { - "iota1...a": 0.5 + "iota1...a": 0.05 } } ``` @@ -101,15 +101,15 @@ In the event there are further royalty, multiple royalty addresses could be used { ... "royalties": { - "iota1...a": 0.25, - "iota1...b": 0.25, - "iota1...c": 0.25, - "iota1...d": 0.25 + "iota1...a": 0.025, + "iota1...b": 0.025, + "iota1...c": 0.025, + "iota1...d": 0.025 } } ``` -The total decimal sum of all `royaltyPercentage` must never exceed 1 and is recommended not to exceed 0.5 +The total decimal sum of all `royaltyPercentage` must never exceed 1 and is recommended not to exceed 0.5. if `royalties` exists, it is iterated over the keys and then all the royalties are paid out till there are no keys left to iterate over. From c658d1efe6eadd5b4f56d31ef7e86f6413188430 Mon Sep 17 00:00:00 2001 From: Adamski <61834907+AdamCroply@users.noreply.github.com> Date: Tue, 5 Apr 2022 17:43:04 +0200 Subject: [PATCH 15/28] Updated example royalties Updated example royalties --- tips/TIP-0027/tip-0027.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/tips/TIP-0027/tip-0027.md b/tips/TIP-0027/tip-0027.md index 885a2e303..55b176ee5 100644 --- a/tips/TIP-0027/tip-0027.md +++ b/tips/TIP-0027/tip-0027.md @@ -202,8 +202,8 @@ Optional, but recommended keys, that may be included in NFT schema include: "policyId": "7f9e0rwf7e90w", "policyName": "My Collection of Art", "royalties": { - "iota1...a": 0.5, - "iota1...b": 0.5 + "iota1...a": 0.025, + "iota1...b": 0.025 }, "issuerName": "My Artist Name", "description": "A little information about my NFT collection", @@ -232,8 +232,8 @@ In addition to the required and recommended schema, the inclusion of `attributes "policyId": "7f9e0rwf7e90w", "policyName": "My Collection of Art", "royalties": { - "iota1...a": 0.5, - "iota1...b": 0.5 + "iota1...a": 0.025, + "iota1...b": 0.025 }, "issuerName": "My Artist Name", "description": "A little information about my NFT collection", From 5dbf82987352d211a43e1aec4a42bbf92c057efb Mon Sep 17 00:00:00 2001 From: Adamski <61834907+AdamCroply@users.noreply.github.com> Date: Tue, 5 Apr 2022 17:43:34 +0200 Subject: [PATCH 16/28] Updated example royalties Updated example royalties --- tips/TIP-0027/irc27.schema.json | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tips/TIP-0027/irc27.schema.json b/tips/TIP-0027/irc27.schema.json index 171b3d125..e453b3544 100644 --- a/tips/TIP-0027/irc27.schema.json +++ b/tips/TIP-0027/irc27.schema.json @@ -22,8 +22,8 @@ "policyName": "My Collection of Art", // Key Value pair collection of royalty addresses, where address is mapped to the percentage of payout to be sent to it "royalties": { - "iota1...a": 0.5, - "iota1...b": 0.5 + "iota1...a": 0.025, + "iota1...b": 0.025 }, // Name of the artist "issuerName": "My Artist Name", From 481a35999879a9e71bb8e908467c29c3efe0a912 Mon Sep 17 00:00:00 2001 From: Adamski <61834907+AdamCroply@users.noreply.github.com> Date: Tue, 5 Apr 2022 18:19:24 +0200 Subject: [PATCH 17/28] Create tip-0033.md Created new TIP 33 - IOTA Public Token Registry --- tips/TIP-0033/tip-0033.md | 201 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 201 insertions(+) create mode 100644 tips/TIP-0033/tip-0033.md diff --git a/tips/TIP-0033/tip-0033.md b/tips/TIP-0033/tip-0033.md new file mode 100644 index 000000000..d2fade6a7 --- /dev/null +++ b/tips/TIP-0033/tip-0033.md @@ -0,0 +1,201 @@ +--- +tip: 33 +title: IOTA Public Token Registry +description: Defines an open public registry for iNFT policy ID and Native Tokens +author: Adam Eunson (@AdamCroply) , Merul Dhiman (@coodos) +discussions-to: https://github.com/iotaledger/tips/discussions/59 +status: Draft +type: Standards +layer: Interface +created: 2022-04-05 +--- + + +# IOTA Public Token Registry + + +## Abstract + + +The IOTA Public Token Registry is an open registry system built to maintain security and consistency through a **publicly maintained collection** of registered **iNFT Policy IDs** and **Native Token Names and Tickers** as defined by the standards of: +- **[TIP-27 - IOTA NFT Standards IRC27](https://github.com/iotaledger/tips/pull/65)** +- **[TIP-30 - Native Token Metadata Standard](https://github.com/iotaledger/tips/pull/68)** + +Providing the facility to support referenceable records that can provide universal verification of the authenticity and origins of NFTs and Tokens deployed on the IOTA Network. + + +### Introduction + +This document aims to support a universal system that can provide dApp developers and creators with an interoperable platform to verify and register tokens providing ease-of-adoption through visible trust in token and NFT origins following recommended standards. + +An open-source and publicly maintained registry, the system provides a portal for projects to register their tokens to maintain a publicly accessible reference for dApp providers and users to validate official project tokens. + +The registry comprises of: +- **iNFT Policy Registry** to allow open-source verifiable collection details +- **IOTA Native Token Registry** to allow open-source verifiable token details +- **REST API** to allow easy integrations into dApps +- **Registry Front-End** to provide an accessible registry search that can be added to any application +- **GitHub PR Bot** to provide easily accessible registry applications + +Utilising the schema from **IRC27 Standards for iNFTs** and **IRC30 Standards for IOTA Native Tokens**, supported with easily deployable end-points and APIs, the registry provides an accessible integration to build trust and security within the IOTA tokenisation ecosystem. + + +## Motivation + + +### Why a Public Registry? + +With an expanding decentralised ecosystem the number of tokens, digital assets, and NFT collections will grow at an extremely high rate. Keeping track of authentic sources is a continued struggle, with opportunists often building out potentially malicious clone tokens and NFT collections in order to take advantage of purchasers through deceptive means. + +A universal registry built not only for managing Native Tokens, but also for the management of verified NFT Policy IDs, provides an open-source point of trust and validation, that can enable creators and users to easily verify the authenticity of a project's token or assets through a simple API call or live reference on the public registry. + +This document we will present the deployment and maintenance of the **IOTA Public Token Registry**. + + +## Specification + +### The Registry + +An open source registry with files containing JSON(s) for registered native tokens and NFT collections that can support project creators in opening a Pull Request to add their token to the registry. + +The registry repository will follow the below folder structure whereby users can submit a JSON file with their project schema and wait for it to be approved by the committee of verifiers. + + +``` + repository + | + |__ tokens + | |__ sample-token-project-1.json + | |__ sample-token-project-2.json + | + |-- NFTs + |__ sample-nft-project-1.json + |__ sample-nft-project-2.json +``` + +The registry will be moderated and maintained by a Committee of Human validators whose approval is needed before anything get's merged. The Committee itself will be a operated via a DAO, the DAO will control who get's to be a part of the approval committee and members can be removed or added by the DAO. + +A minimum threshold of the number of approvals needed before the merge will be determined by the Registry DAO. + +A lot of the most common checks will be extracted to CI such as +- Checking if a name of the project is already taken +- Raise a warning if the name is too similar to an already approved project +- make sure that the project's policy ID is listed on their website + + + +### IRC27 NFT PolicyID Registry + +An open-source human identifiable registry of UTXO `policyId`s to allow projects the ability to support API integrations within their dApps and websites that can support the connection of human identifiable names to verified `policyId`s. + +A creator should register their `policyId` UTXO to a human identifiable value (`policyName`) as a defined unique and verified collection. + +Reference to their `policyId` should be publicly visible on an **official website** or **social media page**. + +A `policyName` must be a unique string. + +The policy registry takes some inspiration from the [CNFT Policy IDs Repo](https://github.com/Cardano-NFTs/policyIDs) whereby a collection creator can open a pull request with their socials, policy ID and collection name and a committe of human verifiers will approve or reject the collection. + +Before a merge to the registry there must be at least 5 approving reviews by human validators. And CI checks to ensure that the socials contain the `policyId` and the `policyName` and there are no duplicate records within the registry. + +An additional cautionary CI check that raises a warning for potentially malicious entries to monitor `policyName`s will also provide additional support for verifiers maintaining the repository. For example, a potential malicious entry of "TanglleLabs" when "Tangle Labs" is already a part of the registry. The rationale behind this is to mitigate fake collections or copy-cat tokens from popping up to take opportune advantage of other projects IP through deceptive means. + +The Committe of human validators will be managed and compensated with a DAO infratructure where we can setup multisig requirements for any vote to conclude. + +An API to support the integration of the policy registry into dApps can be called from the open-source repository. + +When submitting an entry to the iNFT registry the required keys, as defined by the standard schema in TIP 27, must be included and structured as outlined in the example below. + +- `issuerId` must be the original issuerId UTXO string +- `policyId` must be the unique UTXO string of the policyNFT +- `policyName` must be a unique human identifiable string +- `websiteUrl` must be an official website or social media page url that illustrates publicly the `policyId` + +#### EXAMPLE + +```json +{ + "registration": { + "issuerId": " iota1qrhacyfwlcnzkvzteumekfkrrwks98mpdm37cj4xx3drvmjvnep6xqgyzyx", + "policyId": "iota1ppk6m4x7m2t6k5pvgs0yd2nqelfaz09ueyyv6fwn", + "policyName": "My iNFT Collection", + "websiteUrl": "https://mywebsite.com/policyid" + } +} +``` + +### IRC30 Native Token Registry + +An open-source human identifiable registry of Native Token Metadata to allow individuals the ability to support API integrations into dApps and websites that allows the connection of human identifiable names to Native Tokens. + + +The metadata of registry entries must follow the schema standards outlined in TIP 30 as referenced by the examples below. + +#### EXAMPLES + +#### 1. A minimum valid token metadata JSON + +```json +{ + "name": "FooCoin", + "symbol": "FOO", + "decimals": 3, +} +``` + +#### 2. A more descriptive valid token metadata JSON + +```json +{ + "name": "FooCoin", + "description": "FooCoin is the utility and governance token of FooLand, a revolutionary protocol in the play-to-earn crypto gaming field.", + "symbol": "FOO", + "decimals": 3, + "url": "https://foocoin.io", + "logoUrl": "https://ipfs.io/ipfs/QmR36VFfo1hH2RAwVs4zVJ5btkopGip5cW7ydY4jUQBrkR" +} +``` + + + + +### Public Registry Front-End and API + +A REST API is included in the registry to provide easy access for applications to lookup projects through a HTTP request instead of having to scour through the files manually on github. + +A front-end web application is also included to provide simple search functionality to allow users to easily verify a collection or token and to provide an easily accessible option to open a PR through a web form that will extract input data and open a PR in the community Github repository on the user's behalf utilising a custom bot development. + +## Rationale + +The primary reason for the implementation of a token registry is to support human identifiable verification and ease of interoperability between applications handling NFTs and native tokens. Presenting increased trust and security in the tokenised aspects of the IOTA ecosystem. + +Without such a store of registered project tokens an environment without a single source of easy verification would lead to an easy ecosystem for fraudsters to attack with false tokens and fake collections. that would worsen user experience and instill doubt from buyers which can hinder the expansion of the acosystem. + +This registry also supports expansion, backwards compatibility, and a universal guideline for the ecosystem to develop with. Allowing an immediate interoperable environment that can support ease-of-adoption in the early stages of iNFTs and Native Tokens, whilst continually supporting feature expansion and future development. + + +## Backwards Compatibility + + +### Versioning + +Expanding use-cases in the NFT and Native Token spaces will present multiple needs for different registry requirements over time. Alterations and updates will be presented to support an evolving technology and future developments. + +Version is introduced from the start to allow dApp developers and creators to maintain backwards compatibility with differing versions of the registry, APIs and components. + +The version is defined by the version number used preceded with the letter v, current version: + +- `v1.0` + +Current version `v1.0` + + +### Modular Structure Expansion + +A modular structure to the registry has been created to support use case expansion, asset extension, alernative asset registries, or any additional requirements. Allowing creators to utilise individual registry implementations as well as the more expanded options. + + +## Copyright + + +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From ba48997e4e28b18885d96557e839a57b33a5a87e Mon Sep 17 00:00:00 2001 From: Merul <69296233+coodos@users.noreply.github.com> Date: Wed, 6 Apr 2022 17:10:17 +0530 Subject: [PATCH 18/28] fix: irc27 schema --- tips/TIP-0027/irc27.schema.json | 89 ++++++++++++++++++++------------- 1 file changed, 54 insertions(+), 35 deletions(-) diff --git a/tips/TIP-0027/irc27.schema.json b/tips/TIP-0027/irc27.schema.json index e453b3544..65774b700 100644 --- a/tips/TIP-0027/irc27.schema.json +++ b/tips/TIP-0027/irc27.schema.json @@ -1,40 +1,59 @@ + { - // name of the standard - "standard" : "IRC27", - // type can be "image", "audio", "video", "document", "3dAsset" - "type": "image", - // Version of IRC27 standard being used - "version": "v1.0", - // Object containing the actual NFT metadata - "object": { - // define the required utxo identifier for the NFT, - // the utxo identitfier for the issuer and the file location - "nftId": "vt7rye8tgvr7e89w", - // Link to the file - "tokenURI": "https://mywebsite.com/myfile.png", - // define the optional keys for the base schema - - // name of the asset - "tokenName": "My NFT #0001", - // unique policy ID identifier - "policyId": "7f9e0rwf7e90w", - // human readable name for the collection - "policyName": "My Collection of Art", - // Key Value pair collection of royalty addresses, where address is mapped to the percentage of payout to be sent to it + "$schema": "https://json-schema.org/draft/2020-12/schema", + "$id": "https://github.com/iotaledger/tips/main/tips/TIP-0027/irc27.schema.json", + "title": "IRC27 IOTA NFT Metadata Schema", + "description": "A JSON schema for validating IRC27 compliant NFT metadata", + "type": "object", + "properties": { + "standard": { + "type": "string", + "description": "identifier for the metadata standard used" + }, + "version": { + "type": "string", + "description": "version of the metadata standard used", + }, + "type": { + "type": "string", + "description": "MIME type of the asset" + }, + "nftId": { + "type": "string", + "description": "UTXO identifier for the NFT" + }, + "tokenUri": { + "type": "string", + "description": "URI pointing to the resource where the file is hosted" + }, + "tokenName": { + "type": "string", + "description": "name of the specific token" + }, + "policyId": { + "type": "string", + "description": "unique policy ID identifier for the collection" + }, + "policyName": { + "type": "string", + "description": "human readable name for the NFT" + }, "royalties": { - "iota1...a": 0.025, - "iota1...b": 0.025 - }, - // Name of the artist - "issuerName": "My Artist Name", - // description of the asset - "description": "A little information about my NFT collection", - // define optional attributes for NFT metadata + "type": "object", + "description": "object containing the payout addresses mapped to their percentage share" + }, + "issuerName": { + "type": "object", + "description": "name of the artist" + }, + "description": { + "type": "string", + "description": "some information abou the NFT project" + }, "attributes": { - "Background": "Purple", - "Element": "Water", - "Attack": "150", - "Health": "500" + "type": "object", + "description": "object containing any additional arbitrary key-pairs" } - } + }, + "required": [ "standard", "type", "version", "nftId", "tokenUri" ] } From b748957626cf22ce612b912ada508463ab14eef0 Mon Sep 17 00:00:00 2001 From: Merul <69296233+coodos@users.noreply.github.com> Date: Wed, 6 Apr 2022 17:13:30 +0530 Subject: [PATCH 19/28] Update tip-0027.md --- tips/TIP-0027/tip-0027.md | 88 +++++++++++++++++++-------------------- 1 file changed, 42 insertions(+), 46 deletions(-) diff --git a/tips/TIP-0027/tip-0027.md b/tips/TIP-0027/tip-0027.md index 55b176ee5..83dfe47ee 100644 --- a/tips/TIP-0027/tip-0027.md +++ b/tips/TIP-0027/tip-0027.md @@ -156,7 +156,6 @@ The version is defined by the version number used preceded with the letter v, cu "standard" : "IRC27", "type": "image", "version": "v1.0", - "object": { ``` Additional keys that must be included in every NFT schema: @@ -169,11 +168,10 @@ Additional keys that must be included in every NFT schema: "standard" : "IRC27", "type": "image", "version": "v1.0", - "object": { - // define the required utxo identifier for the NFT, - // the utxo identitfier for the issuer and the file location - "nftId": "vt7rye8tgvr7e89w", - "tokenURI": "https://mywebsite.com/myfile.png", + // define the required utxo identifier for the NFT, + // the utxo identitfier for the issuer and the file location + "nftId": "vt7rye8tgvr7e89w", + "tokenURI": "https://mywebsite.com/myfile.png", ``` @@ -191,22 +189,21 @@ Optional, but recommended keys, that may be included in NFT schema include: "standard" : "IRC27", "type": "image", "version": "v1.0", - "object": { - // define the required utxo identifier for the NFT, - // the utxo identitfier for the issuer and the file location - "nftId": "vt7rye8tgvr7e89w", - "tokenURI": "https://mywebsite.com/myfile.png", - - // define the optional keys for the base schema - "tokenName": "My NFT #0001", - "policyId": "7f9e0rwf7e90w", - "policyName": "My Collection of Art", - "royalties": { - "iota1...a": 0.025, - "iota1...b": 0.025 - }, - "issuerName": "My Artist Name", - "description": "A little information about my NFT collection", + // define the required utxo identifier for the NFT, + // the utxo identitfier for the issuer and the file location + "nftId": "vt7rye8tgvr7e89w", + "tokenURI": "https://mywebsite.com/myfile.png", + + // define the optional keys for the base schema + "tokenName": "My NFT #0001", + "policyId": "7f9e0rwf7e90w", + "policyName": "My Collection of Art", + "royalties": { + "iota1...a": 0.025, + "iota1...b": 0.025 + }, + "issuerName": "My Artist Name", + "description": "A little information about my NFT collection", ``` @@ -221,30 +218,29 @@ In addition to the required and recommended schema, the inclusion of `attributes "standard" : "IRC27", "type": "image", "version": "v1.0", - "object": { - // define the required utxo identifier for the NFT, - // the utxo identitfier for the issuer and the file location - "nftId": "vt7rye8tgvr7e89w", - "tokenURI": "https://mywebsite.com/myfile.png", - - // define the optional keys for the base schema - "tokenName": "My NFT #0001", - "policyId": "7f9e0rwf7e90w", - "policyName": "My Collection of Art", - "royalties": { - "iota1...a": 0.025, - "iota1...b": 0.025 - }, - "issuerName": "My Artist Name", - "description": "A little information about my NFT collection", - - // define optional attributes for NFT metadata - "attributes": { - "Background": "Purple", - "Element": "Water", - "Attack": "150", - "Health": "500" - } + + // define the required utxo identifier for the NFT, + // the utxo identitfier for the issuer and the file location + "nftId": "vt7rye8tgvr7e89w", + "tokenURI": "https://mywebsite.com/myfile.png", + + // define the optional keys for the base schema + "tokenName": "My NFT #0001", + "policyId": "7f9e0rwf7e90w", + "policyName": "My Collection of Art", + "royalties": { + "iota1...a": 0.025, + "iota1...b": 0.025 + }, + "issuerName": "My Artist Name", + "description": "A little information about my NFT collection", + + // define optional attributes for NFT metadata + "attributes": { + "Background": "Purple", + "Element": "Water", + "Attack": "150", + "Health": "500" } } ``` From c696eaac761fc2d92257ddc9c2612af98c84fe6f Mon Sep 17 00:00:00 2001 From: Coodos Date: Wed, 6 Apr 2022 20:28:06 +0530 Subject: [PATCH 20/28] chore: remove tip 33 --- tips/TIP-0033/tip-0033.md | 201 -------------------------------------- 1 file changed, 201 deletions(-) delete mode 100644 tips/TIP-0033/tip-0033.md diff --git a/tips/TIP-0033/tip-0033.md b/tips/TIP-0033/tip-0033.md deleted file mode 100644 index d2fade6a7..000000000 --- a/tips/TIP-0033/tip-0033.md +++ /dev/null @@ -1,201 +0,0 @@ ---- -tip: 33 -title: IOTA Public Token Registry -description: Defines an open public registry for iNFT policy ID and Native Tokens -author: Adam Eunson (@AdamCroply) , Merul Dhiman (@coodos) -discussions-to: https://github.com/iotaledger/tips/discussions/59 -status: Draft -type: Standards -layer: Interface -created: 2022-04-05 ---- - - -# IOTA Public Token Registry - - -## Abstract - - -The IOTA Public Token Registry is an open registry system built to maintain security and consistency through a **publicly maintained collection** of registered **iNFT Policy IDs** and **Native Token Names and Tickers** as defined by the standards of: -- **[TIP-27 - IOTA NFT Standards IRC27](https://github.com/iotaledger/tips/pull/65)** -- **[TIP-30 - Native Token Metadata Standard](https://github.com/iotaledger/tips/pull/68)** - -Providing the facility to support referenceable records that can provide universal verification of the authenticity and origins of NFTs and Tokens deployed on the IOTA Network. - - -### Introduction - -This document aims to support a universal system that can provide dApp developers and creators with an interoperable platform to verify and register tokens providing ease-of-adoption through visible trust in token and NFT origins following recommended standards. - -An open-source and publicly maintained registry, the system provides a portal for projects to register their tokens to maintain a publicly accessible reference for dApp providers and users to validate official project tokens. - -The registry comprises of: -- **iNFT Policy Registry** to allow open-source verifiable collection details -- **IOTA Native Token Registry** to allow open-source verifiable token details -- **REST API** to allow easy integrations into dApps -- **Registry Front-End** to provide an accessible registry search that can be added to any application -- **GitHub PR Bot** to provide easily accessible registry applications - -Utilising the schema from **IRC27 Standards for iNFTs** and **IRC30 Standards for IOTA Native Tokens**, supported with easily deployable end-points and APIs, the registry provides an accessible integration to build trust and security within the IOTA tokenisation ecosystem. - - -## Motivation - - -### Why a Public Registry? - -With an expanding decentralised ecosystem the number of tokens, digital assets, and NFT collections will grow at an extremely high rate. Keeping track of authentic sources is a continued struggle, with opportunists often building out potentially malicious clone tokens and NFT collections in order to take advantage of purchasers through deceptive means. - -A universal registry built not only for managing Native Tokens, but also for the management of verified NFT Policy IDs, provides an open-source point of trust and validation, that can enable creators and users to easily verify the authenticity of a project's token or assets through a simple API call or live reference on the public registry. - -This document we will present the deployment and maintenance of the **IOTA Public Token Registry**. - - -## Specification - -### The Registry - -An open source registry with files containing JSON(s) for registered native tokens and NFT collections that can support project creators in opening a Pull Request to add their token to the registry. - -The registry repository will follow the below folder structure whereby users can submit a JSON file with their project schema and wait for it to be approved by the committee of verifiers. - - -``` - repository - | - |__ tokens - | |__ sample-token-project-1.json - | |__ sample-token-project-2.json - | - |-- NFTs - |__ sample-nft-project-1.json - |__ sample-nft-project-2.json -``` - -The registry will be moderated and maintained by a Committee of Human validators whose approval is needed before anything get's merged. The Committee itself will be a operated via a DAO, the DAO will control who get's to be a part of the approval committee and members can be removed or added by the DAO. - -A minimum threshold of the number of approvals needed before the merge will be determined by the Registry DAO. - -A lot of the most common checks will be extracted to CI such as -- Checking if a name of the project is already taken -- Raise a warning if the name is too similar to an already approved project -- make sure that the project's policy ID is listed on their website - - - -### IRC27 NFT PolicyID Registry - -An open-source human identifiable registry of UTXO `policyId`s to allow projects the ability to support API integrations within their dApps and websites that can support the connection of human identifiable names to verified `policyId`s. - -A creator should register their `policyId` UTXO to a human identifiable value (`policyName`) as a defined unique and verified collection. - -Reference to their `policyId` should be publicly visible on an **official website** or **social media page**. - -A `policyName` must be a unique string. - -The policy registry takes some inspiration from the [CNFT Policy IDs Repo](https://github.com/Cardano-NFTs/policyIDs) whereby a collection creator can open a pull request with their socials, policy ID and collection name and a committe of human verifiers will approve or reject the collection. - -Before a merge to the registry there must be at least 5 approving reviews by human validators. And CI checks to ensure that the socials contain the `policyId` and the `policyName` and there are no duplicate records within the registry. - -An additional cautionary CI check that raises a warning for potentially malicious entries to monitor `policyName`s will also provide additional support for verifiers maintaining the repository. For example, a potential malicious entry of "TanglleLabs" when "Tangle Labs" is already a part of the registry. The rationale behind this is to mitigate fake collections or copy-cat tokens from popping up to take opportune advantage of other projects IP through deceptive means. - -The Committe of human validators will be managed and compensated with a DAO infratructure where we can setup multisig requirements for any vote to conclude. - -An API to support the integration of the policy registry into dApps can be called from the open-source repository. - -When submitting an entry to the iNFT registry the required keys, as defined by the standard schema in TIP 27, must be included and structured as outlined in the example below. - -- `issuerId` must be the original issuerId UTXO string -- `policyId` must be the unique UTXO string of the policyNFT -- `policyName` must be a unique human identifiable string -- `websiteUrl` must be an official website or social media page url that illustrates publicly the `policyId` - -#### EXAMPLE - -```json -{ - "registration": { - "issuerId": " iota1qrhacyfwlcnzkvzteumekfkrrwks98mpdm37cj4xx3drvmjvnep6xqgyzyx", - "policyId": "iota1ppk6m4x7m2t6k5pvgs0yd2nqelfaz09ueyyv6fwn", - "policyName": "My iNFT Collection", - "websiteUrl": "https://mywebsite.com/policyid" - } -} -``` - -### IRC30 Native Token Registry - -An open-source human identifiable registry of Native Token Metadata to allow individuals the ability to support API integrations into dApps and websites that allows the connection of human identifiable names to Native Tokens. - - -The metadata of registry entries must follow the schema standards outlined in TIP 30 as referenced by the examples below. - -#### EXAMPLES - -#### 1. A minimum valid token metadata JSON - -```json -{ - "name": "FooCoin", - "symbol": "FOO", - "decimals": 3, -} -``` - -#### 2. A more descriptive valid token metadata JSON - -```json -{ - "name": "FooCoin", - "description": "FooCoin is the utility and governance token of FooLand, a revolutionary protocol in the play-to-earn crypto gaming field.", - "symbol": "FOO", - "decimals": 3, - "url": "https://foocoin.io", - "logoUrl": "https://ipfs.io/ipfs/QmR36VFfo1hH2RAwVs4zVJ5btkopGip5cW7ydY4jUQBrkR" -} -``` - - - - -### Public Registry Front-End and API - -A REST API is included in the registry to provide easy access for applications to lookup projects through a HTTP request instead of having to scour through the files manually on github. - -A front-end web application is also included to provide simple search functionality to allow users to easily verify a collection or token and to provide an easily accessible option to open a PR through a web form that will extract input data and open a PR in the community Github repository on the user's behalf utilising a custom bot development. - -## Rationale - -The primary reason for the implementation of a token registry is to support human identifiable verification and ease of interoperability between applications handling NFTs and native tokens. Presenting increased trust and security in the tokenised aspects of the IOTA ecosystem. - -Without such a store of registered project tokens an environment without a single source of easy verification would lead to an easy ecosystem for fraudsters to attack with false tokens and fake collections. that would worsen user experience and instill doubt from buyers which can hinder the expansion of the acosystem. - -This registry also supports expansion, backwards compatibility, and a universal guideline for the ecosystem to develop with. Allowing an immediate interoperable environment that can support ease-of-adoption in the early stages of iNFTs and Native Tokens, whilst continually supporting feature expansion and future development. - - -## Backwards Compatibility - - -### Versioning - -Expanding use-cases in the NFT and Native Token spaces will present multiple needs for different registry requirements over time. Alterations and updates will be presented to support an evolving technology and future developments. - -Version is introduced from the start to allow dApp developers and creators to maintain backwards compatibility with differing versions of the registry, APIs and components. - -The version is defined by the version number used preceded with the letter v, current version: - -- `v1.0` - -Current version `v1.0` - - -### Modular Structure Expansion - -A modular structure to the registry has been created to support use case expansion, asset extension, alernative asset registries, or any additional requirements. Allowing creators to utilise individual registry implementations as well as the more expanded options. - - -## Copyright - - -Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 35ac461294e9aa89eec1d4519cff9ca2639df8e5 Mon Sep 17 00:00:00 2001 From: Merul <69296233+coodos@users.noreply.github.com> Date: Thu, 28 Apr 2022 15:26:22 +0530 Subject: [PATCH 21/28] chore: update INFT to IOTA NFT --- tips/TIP-0027/tip-0027.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/tips/TIP-0027/tip-0027.md b/tips/TIP-0027/tip-0027.md index 83dfe47ee..86718310f 100644 --- a/tips/TIP-0027/tip-0027.md +++ b/tips/TIP-0027/tip-0027.md @@ -11,7 +11,7 @@ created: 2022-03-04 --- -# iNFT Standard - IRC27 +# IOTA NFT Standard - IRC27 ## Abstract @@ -26,9 +26,9 @@ This document aims to support a universal system that can provide dApp developer Focusing on the primary use case for digital assets as NFTs, this defined standard supports key aspects in the creation, trade, and exchange of different assets with a focus on image, video, audio, and 3d asset file types. -To support an easy-to-implement system the iNFT Standard supports: +To support an easy-to-implement system the IOTA NFT Standard supports: -- **Policy ID** system should define NFT origins by issuerId and policyId for authenticity and verification within the iNFT space. +- **Policy ID** system should define NFT origins by issuerId and policyId for authenticity and verification within the IOTA NFT space. - **Creator Royalty** System that can support universal creator royalties throughout the eco-system. - **NFT Schema Standard** allowing for easily definable keys and values for ease-of-integration. - **Version Modelling** to allow for easy updates as well as backwards compatibility. @@ -40,15 +40,15 @@ The standard provides the foundation for future expansion, supporting a modular ## Motivation -### Why iNFT Standards? +### Why IOTA NFT Standards? Non-Standardised NFT systems have caused concerns and issues across a number of areas in other eco-systems. The lack of interoperable standards present numerous awkward and complicated experiences and in some eco-systems has resulted in countless verification and API issues that segment the NFT community. Early safeguards are possible to put in place to support a more secure and interoperable eco-system that puts creators and buyer security at the forefront, providing developers and dApp makers the grounds to build a more connected and consistent eco-system. -With the IOTA Tokenisation Framework in its infancy, the early adoption of an iNFT Standard can support a safer, more secure environment for creators and dApp providers, to allow an easily interoperable experience through-out the IOTA eco-system. +With the IOTA Tokenisation Framework in its infancy, the early adoption of an IOTA NFT Standard can support a safer, more secure environment for creators and dApp providers, to allow an easily interoperable experience through-out the IOTA eco-system. -In this document we will present the iNFT Standard - IRC27. +In this document we will present the IOTA NFT Standard - IRC27. ## Specification @@ -56,7 +56,7 @@ In this document we will present the iNFT Standard - IRC27. ### Policy ID -The IOTA Tokenisation Framework allows for a unique and robust solution when defining the identity of a collection. The integration of such a system can support verification of the origins of the creation of an NFT. For example, an artist creating a collection of works that will be labelled under a single collection. This allows for ease of verification for buyers and 3rd party application developers to provide an easily observable system of authenticity for users navigating the iNFT space. +The IOTA Tokenisation Framework allows for a unique and robust solution when defining the identity of a collection. The integration of such a system can support verification of the origins of the creation of an NFT. For example, an artist creating a collection of works that will be labelled under a single collection. This allows for ease of verification for buyers and 3rd party application developers to provide an easily observable system of authenticity for users navigating the IOTA NFT space. The standard is defined utilising the creation mechanism for NFTs. @@ -251,11 +251,11 @@ In addition to the required and recommended schema, the inclusion of `attributes ### Interoperable Standards -For a unified iNFT eco-system the standards have been designed to support ease of integration and cross-compatibility of NFTs throughout the IOTA network. Observations of undefined standards in other eco-systems has illustrated the importance of such developments in the early stages of the technology. Simple defined keys such as `nftId`, instead of `assetId` or `tokenId`, or `tokenURI`, instead of `nftUrl` or `fileLocation`can support a much more interoperable experience for creators and dApp developers with everyone working from the same foundations. +For a unified IOTA NFT eco-system the standards have been designed to support ease of integration and cross-compatibility of NFTs throughout the IOTA network. Observations of undefined standards in other eco-systems has illustrated the importance of such developments in the early stages of the technology. Simple defined keys such as `nftId`, instead of `assetId` or `tokenId`, or `tokenURI`, instead of `nftUrl` or `fileLocation`can support a much more interoperable experience for creators and dApp developers with everyone working from the same foundations. Supporting creators is also a key element in driving adoption for the technology, royalty integrations vary substantially in other blockchain eco-systems which remains a challenge for both 3rd party applications and creators in sustaining a consistent and reliable eco-system across different applications. -This standard also supports expansion, backwards compatibility, and a universal guideline for the eco-system to develop with. Allowing an immediate interoperable environment that can support ease-of-adoption in the early stages of iNFTs, whilst continually supporting feature expansion and future development. +This standard also supports expansion, backwards compatibility, and a universal guideline for the eco-system to develop with. Allowing an immediate interoperable environment that can support ease-of-adoption in the early stages of IOTA NFTs, whilst continually supporting feature expansion and future development. ## Backwards Compatibility From 4c8783e224e0be563da587ad511f28e0069adc5b Mon Sep 17 00:00:00 2001 From: Merul <69296233+coodos@users.noreply.github.com> Date: Thu, 28 Apr 2022 15:28:01 +0530 Subject: [PATCH 22/28] chore: update policyId to collecitonId --- tips/TIP-0027/tip-0027.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/tips/TIP-0027/tip-0027.md b/tips/TIP-0027/tip-0027.md index 86718310f..995f46cee 100644 --- a/tips/TIP-0027/tip-0027.md +++ b/tips/TIP-0027/tip-0027.md @@ -28,7 +28,7 @@ Focusing on the primary use case for digital assets as NFTs, this defined standa To support an easy-to-implement system the IOTA NFT Standard supports: -- **Policy ID** system should define NFT origins by issuerId and policyId for authenticity and verification within the IOTA NFT space. +- **Policy ID** system should define NFT origins by issuerId and collectionId for authenticity and verification within the IOTA NFT space. - **Creator Royalty** System that can support universal creator royalties throughout the eco-system. - **NFT Schema Standard** allowing for easily definable keys and values for ease-of-integration. - **Version Modelling** to allow for easy updates as well as backwards compatibility. @@ -64,17 +64,17 @@ The standard is defined utilising the creation mechanism for NFTs. Each NFT in the IOTA Tokenization Framework has its own unique address, that allows the ability to define a **collection UTXO** that can subsequently mint each unique NFT within that collection. -The `nftId` of a collection NFT is defined as the `policyId`. +The `nftId` of a collection NFT is defined as the `collectionId`. -The policyId will act as a unique identifier for the collection and would allow the `policyNft` to control the NFTs in a collection. This allows for unprecedented amounts of control where you can lock a collection for some time. It also allows for the ability to transfer the `policyNft` (parent NFT of all the NFTs minted within a collection) on transfer of which the new holder will be able to add NFTs to the collection, gaining control over ownership of the collection brand, but also with the ability to lock the collection by the destruction of the collection NFT. +The collectionId will act as a unique identifier for the collection and would allow the `collecitonNft` to control the NFTs in a collection. This allows for unprecedented amounts of control where you can lock a collection for some time. It also allows for the ability to transfer the `collectionNft` (parent NFT of all the NFTs minted within a collection) on transfer of which the new holder will be able to add NFTs to the collection, gaining control over ownership of the collection brand, but also with the ability to lock the collection by the destruction of the collection NFT. -A creator should define the UTXO of their collection NFT as the sole minting source of an entire collection that is the `policyId`. +A creator should define the UTXO of their collection NFT as the sole minting source of an entire collection that is the `collectionId`. A creator may choose to burn the collection NFT on completion of minting or retain the collection NFT to add further NFTs to the collection over time. -The UTXO of the collection NFT, `nftId`, acts as the `policyId` for the collection and can be used in dApps to define the verified origin of an NFT. +The UTXO of the collection NFT, `nftId`, acts as the `collectionId` for the collection and can be used in dApps to define the verified origin of an NFT. -To call the defined `policyId` you should request the `policyId` UTXO of the collection NFT and resolve to the Policy Registry for human identifiable verification. +To call the defined `collectionId` you should request the `collectionId` UTXO of the collection NFT and resolve to the Policy Registry for human identifiable verification. To better serve the ecosystem with a single point of record for registered collections a Public Token Registry is defined in [IOTA Public Token Registry - TIP 33](https://github.com/iotaledger/tips/pull/--) where further reading can be found. @@ -177,7 +177,7 @@ Additional keys that must be included in every NFT schema: Optional, but recommended keys, that may be included in NFT schema include: - `tokenName` – alphanumeric text string defining the human identifiable name for the NFT -- `policyId` – UTXO string of the policy NFT +- `collectionId` – UTXO string of the policy NFT - `policyName` – alphanumeric text string defining the human identifiable collection name - `royalties` - Object containing key value pair where payment address mapped to the payout percentage - `issuerName` – alphanumeric text string to define the human identifiable name of the creator @@ -196,7 +196,7 @@ Optional, but recommended keys, that may be included in NFT schema include: // define the optional keys for the base schema "tokenName": "My NFT #0001", - "policyId": "7f9e0rwf7e90w", + "collectionId": "7f9e0rwf7e90w", "policyName": "My Collection of Art", "royalties": { "iota1...a": 0.025, @@ -226,7 +226,7 @@ In addition to the required and recommended schema, the inclusion of `attributes // define the optional keys for the base schema "tokenName": "My NFT #0001", - "policyId": "7f9e0rwf7e90w", + "collectionId": "7f9e0rwf7e90w", "policyName": "My Collection of Art", "royalties": { "iota1...a": 0.025, From 197c87fc561c49705f5dcd9753191c1e62093c95 Mon Sep 17 00:00:00 2001 From: Levente Pap Date: Thu, 28 Apr 2022 17:51:51 +0200 Subject: [PATCH 23/28] Replace policy with collection --- tips/TIP-0027/irc27.schema.json | 14 ++--- tips/TIP-0027/tip-0027.md | 104 +++++++++++--------------------- 2 files changed, 41 insertions(+), 77 deletions(-) diff --git a/tips/TIP-0027/irc27.schema.json b/tips/TIP-0027/irc27.schema.json index 65774b700..f8aa9aab3 100644 --- a/tips/TIP-0027/irc27.schema.json +++ b/tips/TIP-0027/irc27.schema.json @@ -12,7 +12,7 @@ }, "version": { "type": "string", - "description": "version of the metadata standard used", + "description": "version of the metadata standard used" }, "type": { "type": "string", @@ -25,25 +25,25 @@ "tokenUri": { "type": "string", "description": "URI pointing to the resource where the file is hosted" - }, + }, "tokenName": { "type": "string", "description": "name of the specific token" }, - "policyId": { + "collectionId": { "type": "string", - "description": "unique policy ID identifier for the collection" + "description": "unique collection ID identifier for the collection" }, - "policyName": { + "collectionName": { "type": "string", - "description": "human readable name for the NFT" + "description": "human readable name for the NFT collection" }, "royalties": { "type": "object", "description": "object containing the payout addresses mapped to their percentage share" }, "issuerName": { - "type": "object", + "type": "string", "description": "name of the artist" }, "description": { diff --git a/tips/TIP-0027/tip-0027.md b/tips/TIP-0027/tip-0027.md index 995f46cee..2c6db1092 100644 --- a/tips/TIP-0027/tip-0027.md +++ b/tips/TIP-0027/tip-0027.md @@ -1,7 +1,7 @@ --- tip: 27 title: IOTA NFT Standard IRC27 -description: Define NFT metadata standard, policy registry and creator royalties +description: Define NFT metadata standard, collection registry and creator royalties author: Adam Eunson (@AdamCroply) , Merul Dhiman (@coodos) discussions-to: https://github.com/iotaledger/tips/discussions/59 status: Draft @@ -10,53 +10,46 @@ layer: IRC created: 2022-03-04 --- - # IOTA NFT Standard - IRC27 - ## Abstract - -**IRC27** is a series of standards to support interoperable and universal NFT systems throughout the IOTA eco-system, to provide a more robust and secure system for creators and buyers. - +**IRC27** is a series of standards to support interoperable and universal NFT systems throughout the IOTA ecosystem, to provide a more robust and secure system for creators and buyers. ### Introduction -This document aims to support a universal system that can provide dApp developers and creators with an interoperable foundation of standards to support ease-of-adoption and a connected NFT eco-system. To bring value, security, trust, and interoperability. +This document aims to support a universal system that can provide dApp developers and creators with an interoperable foundation of standards to support ease-of-adoption and a connected NFT ecosystem. To bring value, security, trust, and interoperability. Focusing on the primary use case for digital assets as NFTs, this defined standard supports key aspects in the creation, trade, and exchange of different assets with a focus on image, video, audio, and 3d asset file types. To support an easy-to-implement system the IOTA NFT Standard supports: -- **Policy ID** system should define NFT origins by issuerId and collectionId for authenticity and verification within the IOTA NFT space. -- **Creator Royalty** System that can support universal creator royalties throughout the eco-system. +- **Collection ID** system should define NFT origins by issuerId and collectionId for authenticity and verification within the IOTA NFT space. +- **Creator Royalty** System that can support universal creator royalties throughout the ecosystem. - **NFT Schema Standard** allowing for easily definable keys and values for ease-of-integration. - **Version Modelling** to allow for easy updates as well as backwards compatibility. - **Modular System Design** to provide developers freedom to utilise only required elements, as well as for future standards expansion beyond the existing standard model. The standard provides the foundation for future expansion, supporting a modular design to provide an opportunity for selective integration, as well as further use case expansion through additional modules as time goes by. - ## Motivation - ### Why IOTA NFT Standards? -Non-Standardised NFT systems have caused concerns and issues across a number of areas in other eco-systems. The lack of interoperable standards present numerous awkward and complicated experiences and in some eco-systems has resulted in countless verification and API issues that segment the NFT community. +Non-Standardised NFT systems have caused concerns and issues across a number of areas in other ecosystems. The lack of interoperable standards present numerous awkward and complicated experiences and in some ecosystems has resulted in countless verification and API issues that segment the NFT community. -Early safeguards are possible to put in place to support a more secure and interoperable eco-system that puts creators and buyer security at the forefront, providing developers and dApp makers the grounds to build a more connected and consistent eco-system. +Early safeguards are possible to put in place to support a more secure and interoperable ecosystem that puts creators and buyer security at the forefront, providing developers and dApp makers the grounds to build a more connected and consistent ecosystem. -With the IOTA Tokenisation Framework in its infancy, the early adoption of an IOTA NFT Standard can support a safer, more secure environment for creators and dApp providers, to allow an easily interoperable experience through-out the IOTA eco-system. +With the IOTA Tokenization Framework in its infancy, the early adoption of an IOTA NFT Standard can support a safer, more secure environment for creators and dApp providers, to allow an easily interoperable experience through-out the IOTA ecosystem. In this document we will present the IOTA NFT Standard - IRC27. - ## Specification -### Policy ID +### Collection ID -The IOTA Tokenisation Framework allows for a unique and robust solution when defining the identity of a collection. The integration of such a system can support verification of the origins of the creation of an NFT. For example, an artist creating a collection of works that will be labelled under a single collection. This allows for ease of verification for buyers and 3rd party application developers to provide an easily observable system of authenticity for users navigating the IOTA NFT space. +The IOTA Tokenization Framework allows for a unique and robust solution when defining the identity of a collection. The integration of such a system can support verification of the origins of the creation of an NFT. For example, an artist creating a collection of works that will be labelled under a single collection. This allows for ease of verification for buyers and 3rd party application developers to provide an easily observable system of authenticity for users navigating the IOTA NFT space. The standard is defined utilising the creation mechanism for NFTs. @@ -66,7 +59,7 @@ Each NFT in the IOTA Tokenization Framework has its own unique address, that all The `nftId` of a collection NFT is defined as the `collectionId`. -The collectionId will act as a unique identifier for the collection and would allow the `collecitonNft` to control the NFTs in a collection. This allows for unprecedented amounts of control where you can lock a collection for some time. It also allows for the ability to transfer the `collectionNft` (parent NFT of all the NFTs minted within a collection) on transfer of which the new holder will be able to add NFTs to the collection, gaining control over ownership of the collection brand, but also with the ability to lock the collection by the destruction of the collection NFT. +The `collectionId` will act as a unique identifier for the collection and would allow the `collectionNft` to control NFT creation in a collection. This allows for unprecedented amounts of control where you can lock NFT creation in a collection for some time. It also allows for the ability to transfer the `collectionNft` (parent NFT of all the NFTs minted within a collection) on transfer of which the new holder will be able to add NFTs to the collection, gaining control over ownership of the collection brand, but also with the ability to lock the collection by the destruction of the collection NFT. A creator should define the UTXO of their collection NFT as the sole minting source of an entire collection that is the `collectionId`. @@ -74,19 +67,20 @@ A creator may choose to burn the collection NFT on completion of minting or reta The UTXO of the collection NFT, `nftId`, acts as the `collectionId` for the collection and can be used in dApps to define the verified origin of an NFT. -To call the defined `collectionId` you should request the `collectionId` UTXO of the collection NFT and resolve to the Policy Registry for human identifiable verification. +To call the defined `collectionId` you should request the `collectionId` UTXO of the collection NFT and resolve to the Collection Registry for human identifiable verification. -To better serve the ecosystem with a single point of record for registered collections a Public Token Registry is defined in [IOTA Public Token Registry - TIP 33](https://github.com/iotaledger/tips/pull/--) where further reading can be found. +To better serve the ecosystem with a single point of record for registered collections one possible Public Token Registry is defined in [IOTA Public Token Registry - TIP 33](https://github.com/iotaledger/tips/pull/72) where further reading can be found. -### Creator Royalties +It is important to note that several token registries may coexist in the future, TIP-27 only defines the data structure of NFT metadata.It is up to the registry to decide what criteria and method to use to verify and accept submissions. -A system to support interoperable royalty payments across dApps. Allowing universal secondary market reward systems to be integrated through-out the eco-system. Integration of such systems is at the choosing of the dApp developer but is encouraged to support creator royalties. +### Creator Royalties -royalty addresses can be defined inside the royalty addresses -```js -// the key inside the royalties object must be a valid iota1 address where royalties will be sent too -// the value must be a numeric decimal representative of the percentage required ie. 0.05=5% +A system to support interoperable royalty payments across dApps. Allowing universal secondary market reward systems to be integrated through-out the ecosystem. Integration of such systems is at the choosing of the dApp developer but is encouraged to support creator royalties. +Royalty addresses may be defined under the `royalties` key within the NFT metadata. + - The key inside the royalties object must be a valid iota1/smr1 address where royalties will be sent to. + - The value must be a numeric decimal representative of the percentage required ie. 0.05=5% +```json { ... "royalties": { @@ -111,14 +105,11 @@ In the event there are further royalty, multiple royalty addresses could be used The total decimal sum of all `royaltyPercentage` must never exceed 1 and is recommended not to exceed 0.5. - -if `royalties` exists, it is iterated over the keys and then all the royalties are paid out till there are no keys left to iterate over. - - +If `royalties` exists, it is iterated over the keys and then all the royalties are paid out till there are no keys left to iterate over. ### NFT Schema -For ease of development and interoperability between applications within the eco-system an extendable schema standard is defined to support ease of integration of NFTs for developers. +For ease of development and interoperability between applications within the ecosystem an extendable schema standard is defined to support ease of integration of NFTs for developers. Each schema is defined by three main keys: @@ -134,7 +125,6 @@ The standard defined is: - `IRC27` - The schema is defined by one of the following: - `image` – ie. jpeg, gif, png, bmp, webp @@ -143,42 +133,37 @@ The schema is defined by one of the following: - `3dAsset` – ie. obj, fbx, glb - `document` – ie. doc, xls, pdf, txt - - The version is defined by the version number used preceded with the letter v, current version: - `v1.0` - +Define the standard, the type, and the version: ```json -// Define the standard, the type, and the version + { - "standard" : "IRC27", + "standard": "IRC27", "type": "image", - "version": "v1.0", + "version": "v1.0" +} ``` Additional keys that must be included in every NFT schema: - `nftId` – UTXO string of the NFT - `tokenURI` – url pointing to the NFT file location - ```json { "standard" : "IRC27", "type": "image", "version": "v1.0", - // define the required utxo identifier for the NFT, - // the utxo identitfier for the issuer and the file location "nftId": "vt7rye8tgvr7e89w", "tokenURI": "https://mywebsite.com/myfile.png", ``` - Optional, but recommended keys, that may be included in NFT schema include: - `tokenName` – alphanumeric text string defining the human identifiable name for the NFT -- `collectionId` – UTXO string of the policy NFT -- `policyName` – alphanumeric text string defining the human identifiable collection name +- `collectionId` – UTXO string of the collection NFT +- `collectionName` – alphanumeric text string defining the human identifiable collection name - `royalties` - Object containing key value pair where payment address mapped to the payout percentage - `issuerName` – alphanumeric text string to define the human identifiable name of the creator - `description` – alphanumeric text string to define a basic description of the NFT @@ -189,15 +174,11 @@ Optional, but recommended keys, that may be included in NFT schema include: "standard" : "IRC27", "type": "image", "version": "v1.0", - // define the required utxo identifier for the NFT, - // the utxo identitfier for the issuer and the file location "nftId": "vt7rye8tgvr7e89w", "tokenURI": "https://mywebsite.com/myfile.png", - - // define the optional keys for the base schema "tokenName": "My NFT #0001", "collectionId": "7f9e0rwf7e90w", - "policyName": "My Collection of Art", + "collectionName": "My Collection of Art", "royalties": { "iota1...a": 0.025, "iota1...b": 0.025 @@ -206,36 +187,26 @@ Optional, but recommended keys, that may be included in NFT schema include: "description": "A little information about my NFT collection", ``` - In addition to the required and recommended schema, the inclusion of `attributes` allows for versatile expansion for NFT metadata. - `attributes` are defined as a unique key and string that can be referenced in dApps to display metadata as required. - ```json { "standard" : "IRC27", "type": "image", "version": "v1.0", - - // define the required utxo identifier for the NFT, - // the utxo identitfier for the issuer and the file location "nftId": "vt7rye8tgvr7e89w", "tokenURI": "https://mywebsite.com/myfile.png", - - // define the optional keys for the base schema "tokenName": "My NFT #0001", "collectionId": "7f9e0rwf7e90w", - "policyName": "My Collection of Art", + "collectionName": "My Collection of Art", "royalties": { "iota1...a": 0.025, "iota1...b": 0.025 }, "issuerName": "My Artist Name", "description": "A little information about my NFT collection", - - // define optional attributes for NFT metadata "attributes": { "Background": "Purple", "Element": "Water", @@ -245,22 +216,18 @@ In addition to the required and recommended schema, the inclusion of `attributes } ``` - ## Rationale - ### Interoperable Standards -For a unified IOTA NFT eco-system the standards have been designed to support ease of integration and cross-compatibility of NFTs throughout the IOTA network. Observations of undefined standards in other eco-systems has illustrated the importance of such developments in the early stages of the technology. Simple defined keys such as `nftId`, instead of `assetId` or `tokenId`, or `tokenURI`, instead of `nftUrl` or `fileLocation`can support a much more interoperable experience for creators and dApp developers with everyone working from the same foundations. - -Supporting creators is also a key element in driving adoption for the technology, royalty integrations vary substantially in other blockchain eco-systems which remains a challenge for both 3rd party applications and creators in sustaining a consistent and reliable eco-system across different applications. +For a unified IOTA NFT ecosystem the standards have been designed to support ease of integration and cross-compatibility of NFTs throughout the IOTA network. Observations of undefined standards in other ecosystems has illustrated the importance of such developments in the early stages of the technology. Simple defined keys such as `nftId`, instead of `assetId` or `tokenId`, or `tokenURI`, instead of `nftUrl` or `fileLocation`can support a much more interoperable experience for creators and dApp developers with everyone working from the same foundations. -This standard also supports expansion, backwards compatibility, and a universal guideline for the eco-system to develop with. Allowing an immediate interoperable environment that can support ease-of-adoption in the early stages of IOTA NFTs, whilst continually supporting feature expansion and future development. +Supporting creators is also a key element in driving adoption for the technology, royalty integrations vary substantially in other blockchain ecosystems which remains a challenge for both 3rd party applications and creators in sustaining a consistent and reliable ecosystem across different applications. +This standard also supports expansion, backwards compatibility, and a universal guideline for the ecosystem to develop with. Allowing an immediate interoperable environment that can support ease-of-adoption in the early stages of IOTA NFTs, whilst continually supporting feature expansion and future development. ## Backwards Compatibility - ### Versioning Expanding use-cases in the NFT space will present multiple requirements for different standards and schemas to be developed and over time alterations and updates will be presented to support an evolving technology and future developments. @@ -273,9 +240,6 @@ Current version `v1.0` A modular structure to the standard has been created to support use case expansion, file type extension, standards catalogue. Allowing creators to utilise minimalist implementations as well as the more advanced expanded standards. - - ## Copyright - Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 41d828dae19effc0768b4c556ec2015f1d01219a Mon Sep 17 00:00:00 2001 From: huhn511 Date: Fri, 17 Jun 2022 18:46:55 +0200 Subject: [PATCH 24/28] use Open Sea standart for attributes --- tips/TIP-0027/irc27.schema.json | 4 ++-- tips/TIP-0027/tip-0027.md | 28 +++++++++++++++++++++------- 2 files changed, 23 insertions(+), 9 deletions(-) diff --git a/tips/TIP-0027/irc27.schema.json b/tips/TIP-0027/irc27.schema.json index f8aa9aab3..391002a56 100644 --- a/tips/TIP-0027/irc27.schema.json +++ b/tips/TIP-0027/irc27.schema.json @@ -51,8 +51,8 @@ "description": "some information abou the NFT project" }, "attributes": { - "type": "object", - "description": "object containing any additional arbitrary key-pairs" + "type": "array", + "description": "array containing any additional data as objects." } }, "required": [ "standard", "type", "version", "nftId", "tokenUri" ] diff --git a/tips/TIP-0027/tip-0027.md b/tips/TIP-0027/tip-0027.md index 2c6db1092..d9411975d 100644 --- a/tips/TIP-0027/tip-0027.md +++ b/tips/TIP-0027/tip-0027.md @@ -189,7 +189,9 @@ Optional, but recommended keys, that may be included in NFT schema include: In addition to the required and recommended schema, the inclusion of `attributes` allows for versatile expansion for NFT metadata. -`attributes` are defined as a unique key and string that can be referenced in dApps to display metadata as required. +`attributes` are the attributes for the item, which will show up on dApps like NFT Marketplaces. + +IRC27 NFT metadata follows the [OpenSea metadata standards](https://docs.opensea.io/docs/metadata-standards). ```json { @@ -207,12 +209,24 @@ In addition to the required and recommended schema, the inclusion of `attributes }, "issuerName": "My Artist Name", "description": "A little information about my NFT collection", - "attributes": { - "Background": "Purple", - "Element": "Water", - "Attack": "150", - "Health": "500" - } + "attributes": [ + { + "trait_type": "Background", + "value": "Purple" + }, + { + "trait_type": "Element", + "value": "Water" + }, + { + "trait_type": "Attack", + "value": "150" + }, + { + "trait_type": "Health", + "value": "500" + }, + ] } ``` From 07510abb2581e3f3d0a0df26e4e92597072c35c4 Mon Sep 17 00:00:00 2001 From: Levente Pap Date: Tue, 21 Jun 2022 19:20:56 +0200 Subject: [PATCH 25/28] Clean up JSON schema --- tips/TIP-0027/irc27.schema.json | 32 +++++++++++++++----------------- 1 file changed, 15 insertions(+), 17 deletions(-) diff --git a/tips/TIP-0027/irc27.schema.json b/tips/TIP-0027/irc27.schema.json index 391002a56..77e80ed4e 100644 --- a/tips/TIP-0027/irc27.schema.json +++ b/tips/TIP-0027/irc27.schema.json @@ -8,35 +8,37 @@ "properties": { "standard": { "type": "string", - "description": "identifier for the metadata standard used" + "description": "identifier for the metadata standard used", + "pattern": "^IRC27$" }, "version": { "type": "string", - "description": "version of the metadata standard used" + "description": "version of the metadata standard used", + "pattern": "^v\\d+.\\d+$" }, - "type": { + "name": { "type": "string", - "description": "MIME type of the asset" + "description": "A descriptive name of the token" }, - "nftId": { + "description": { "type": "string", - "description": "UTXO identifier for the NFT" + "description": "some information about the NFT project" }, - "tokenUri": { + "type": { "type": "string", - "description": "URI pointing to the resource where the file is hosted" + "description": "MIME type of the asset" }, - "tokenName": { + "uri": { "type": "string", - "description": "name of the specific token" + "description": "URI pointing to the resource where the file with `type` MIME type is hosted" }, "collectionId": { "type": "string", - "description": "unique collection ID identifier for the collection" + "description": "A unique collection ID identifier for the collection" }, "collectionName": { "type": "string", - "description": "human readable name for the NFT collection" + "description": "A human readable name for the NFT collection" }, "royalties": { "type": "object", @@ -46,14 +48,10 @@ "type": "string", "description": "name of the artist" }, - "description": { - "type": "string", - "description": "some information abou the NFT project" - }, "attributes": { "type": "array", "description": "array containing any additional data as objects." } }, - "required": [ "standard", "type", "version", "nftId", "tokenUri" ] + "required": [ "standard", "type", "version", "uri", "name" ] } From ac9687f6d8285a508db11520b430b0071c1862d7 Mon Sep 17 00:00:00 2001 From: Levente Pap Date: Tue, 21 Jun 2022 19:21:21 +0200 Subject: [PATCH 26/28] Desscribe NFT Collections, add practical examples --- tips/TIP-0027/tip-0027.md | 172 +++++++++++++++++++++++++++++++------- 1 file changed, 141 insertions(+), 31 deletions(-) diff --git a/tips/TIP-0027/tip-0027.md b/tips/TIP-0027/tip-0027.md index d9411975d..65a07780b 100644 --- a/tips/TIP-0027/tip-0027.md +++ b/tips/TIP-0027/tip-0027.md @@ -125,13 +125,16 @@ The standard defined is: - `IRC27` -The schema is defined by one of the following: +The schema type is defined as a [MIME type](https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types), for example: -- `image` – ie. jpeg, gif, png, bmp, webp -- `video` – ie. avi, mp4, webm -- `audio` – ie. wav, mp3 -- `3dAsset` – ie. obj, fbx, glb -- `document` – ie. doc, xls, pdf, txt +- Image files: `image/jpeg`, `image/png`, `image/gif`, etc. +- Video files: `video/x-msvideo` (avi), `video/mp4`, `video/mpeg`, etc. +- Audio files: `audio/mpeg`, `audio/wav`, etc. +- 3D Assets: `model/obj`, `model/u3d`, etc. +- Documents: `application/pdf`, `text/plain`, etc. + +You may find all common MIME types in [IANA's registry](https://www.iana.org/assignments/media-types/media-types.xhtml). +Custom file types might define their own MIME types. The version is defined by the version number used preceded with the letter v, current version: @@ -142,49 +145,50 @@ Define the standard, the type, and the version: { "standard": "IRC27", - "type": "image", + "type": "image/jpeg", "version": "v1.0" } ``` Additional keys that must be included in every NFT schema: -- `nftId` – UTXO string of the NFT -- `tokenURI` – url pointing to the NFT file location +- `uri` – url pointing to the NFT file location with MIME type defined in `type`. +- `name` - alphanumeric text string defining the human identifiable name for the NFT ```json { - "standard" : "IRC27", - "type": "image", + "standard": "IRC27", "version": "v1.0", - "nftId": "vt7rye8tgvr7e89w", - "tokenURI": "https://mywebsite.com/myfile.png", + "type": "image/jpeg", + "uri": "https://mywebsite.com/my-nft-files-1.jpeg", + "name": "My NFT #0001" +} ``` Optional, but recommended keys, that may be included in NFT schema include: -- `tokenName` – alphanumeric text string defining the human identifiable name for the NFT -- `collectionId` – UTXO string of the collection NFT +- `collectionId` – UTXO string (nftId) of the collection NFT that minted this NFT - `collectionName` – alphanumeric text string defining the human identifiable collection name - `royalties` - Object containing key value pair where payment address mapped to the payout percentage - `issuerName` – alphanumeric text string to define the human identifiable name of the creator - `description` – alphanumeric text string to define a basic description of the NFT +- `attributes` - Array objects defining additional attributes of the NFT ```json { - "standard" : "IRC27", - "type": "image", + "standard": "IRC27", "version": "v1.0", - "nftId": "vt7rye8tgvr7e89w", - "tokenURI": "https://mywebsite.com/myfile.png", - "tokenName": "My NFT #0001", - "collectionId": "7f9e0rwf7e90w", + "type": "image/jpeg", + "uri": "https://mywebsite.com/my-nft-files-1.jpeg", + "name": "My NFT #0001", + "collectionId": "ed48cfb0e4ac4d4e40174505290ce43bef586cd59721b98cecb4cf02aa34e106", "collectionName": "My Collection of Art", "royalties": { "iota1...a": 0.025, "iota1...b": 0.025 }, "issuerName": "My Artist Name", - "description": "A little information about my NFT collection", + "description": "A little information about my NFT collection" +} ``` In addition to the required and recommended schema, the inclusion of `attributes` allows for versatile expansion for NFT metadata. @@ -195,20 +199,19 @@ IRC27 NFT metadata follows the [OpenSea metadata standards](https://docs.opensea ```json { - "standard" : "IRC27", - "type": "image", + "standard": "IRC27", "version": "v1.0", - "nftId": "vt7rye8tgvr7e89w", - "tokenURI": "https://mywebsite.com/myfile.png", - "tokenName": "My NFT #0001", - "collectionId": "7f9e0rwf7e90w", + "type": "image/jpeg", + "uri": "https://mywebsite.com/my-nft-files-1.jpeg", + "name": "My NFT #0001", + "collectionId": "ed48cfb0e4ac4d4e40174505290ce43bef586cd59721b98cecb4cf02aa34e106", "collectionName": "My Collection of Art", "royalties": { "iota1...a": 0.025, "iota1...b": 0.025 }, "issuerName": "My Artist Name", - "description": "A little information about my NFT collection", + "description": "A little information about my NFT collection" "attributes": [ { "trait_type": "Background", @@ -225,16 +228,123 @@ IRC27 NFT metadata follows the [OpenSea metadata standards](https://docs.opensea { "trait_type": "Health", "value": "500" - }, + } ] } ``` +## Practical example + +How does this all work for L1 NFT collections in the IOTA Tangle? Best to explain with an example. + +In Stardust L1 NFTs are represented as outputs in the ledger. Each NFT output has the following properties: + - (mandatory) `nftId`: a unique identifier of the NFT output assigned by the protocol upon minting + - (mandatory) `owner`: address in _Address Unlock Condition_ that is allowed to unlock the NFT output + - (optional) `immutableIssuer`: an address (can be alias/nft address too) that minted the NFT output + - (optional) `immutableMetadata`: binary blob of data defined upon minting by the issuer + - (optional) `sender`: defines an address that transferred the nft to the current owner + - (optional) `mutableMetadata`: binary blob defined by the last sender + +To host metadata about the NFT, the `immutableMetadata` field of the output should be used, as the mutable one may be changed by the current owner. +Storing metadata in an output increases the storage deposit requirement of the output, but then no additional off-chain metadata storage solution is required. + +NFTs may be standalone assets, but often they are part of a collection. In EVM based NFT platforms collections are represented as a single contract that manages the collection and keeps the ownership record of the NFTs within collection. Since L1 NFTs in IOTA are represented as UTXOs in the ledger rather than smart contracts, minting a collection is conceptually different. + +### Minting L1 NFT Collections + +The idea is to tie NFTs (individual UTXOs) within one collection together via the `immutableIssuer` property. +The collection itself is represented by a special NFT output, the `Collection NFT`. It holds information about the properties of the collection and when included in transactions, it can mint the NFTs within the collection where `immutableIssuer` becomes the `nftId` of the `Collection NFT`. + +It is possible to timelock the `Collection NFT` on protocol level to prevent minting of the NFTs for a certain time period. It is also possible send the `Collection NFT` to the zero address, or burn it al together, which essentially means that the collection is locked forever, no more collection items can ever be minted. +It is not possible to define on protocol level how many items can the `Collection NFT` can mint, unless it is deposited into a L2 smart contract that manages issuer rights. + +Let's look at a practical example on how the process looks like. + +### 1. Minting the Collection NFT + +The issuer mints an NFT output on L1 with the following properties: + - `nftId`: a unique identifier of the NFT output assigned by the protocol upon minting. This will become the `collectionId`. + - `immutableIssuer`: L1 address of the minting artist. Can be used to prove authenticity of the collection. + - `immutableMetadata`: binary blob of data defined upon minting by the issuer. This will become the `collectionMetadata`. + +The issuer of the `Collection NFT` defines the collection metadata according to IRC-27 standard. In our example, `collectionMetadata` is a JSON object: +```json +{ + "standard": "IRC27", + "version": "v1.0", + "type": "text/html", + "uri": "https://my-awesome-nft-project.com", + "name": "My Awesome NFT Collection", + "issuerName": "Me" +} +``` + - The binary blob of this JSON object is put in the `immutableMetadata` field of the NFT output. + +### 2. Minting NFTs within the collection + +The issuer includes the `Collection NFT` in a transaction that mints NFTs within the collection. The number of mintable NFTs in one transaction is defined by the protocol as the [Max Outputs Count defined in TIP-22](https://github.com/Wollac/protocol-rfcs/blob/protocol-parameters/tips/TIP-0022/tip-0022.md#detailed-design) - 1 (the `Collection NFT` is also part of the outputs). + +The minted NFTs will have the following properties: + - `nftId`: the unique identifier of the NFT output assigned by the protocol upon minting. + - `immutableIssuer`: is set as `collectionId` of the `Collection NFT`. This unique value identifies which collection the NFT belongs to. + - `immutableMetadata`: metadata for the individual NFT. Binary blob of an IRC-27 compliant JSON object. + +For item 4 for example, the metadata is: +```json +{ + "standard": "IRC27", + "version": "v1.0", + "type": "image/gif", + "uri": "https://my-awesome-nft-project.com/item-4.gif", + "name": "#4 My Awesome NFT", + "issuerName": "Me", + "royalties": { + "smr1q5948....": 0.05 + }, + "collectionId": "ed48cfb0e4ac4d4e40174505290ce43bef586cd59721b98cecb4cf02aa34e106", + "collectionName": "My Awesome NFT Collection", + "attributes": [ + { + "trait_type": "awesomeness", + "value": 60 + } +] +} +``` + + - `collectionId` in the metadata is technically redundant, as the immutable issuer field of the output already contains it, but if it's part of the metadata as well, it can be easily verified whether it matches the actual field in the output. If the metadata is hosted somewhere else (not on-chain in the ledger, but off-chain on a server/ipfs) then it is not needed to fetch the output to figure out which collection is belongs to. + +In case the metadata is not stored in the NFT output but is hosted off-chain, it is still recommended to include information in the `immutableMetadata` field such that clients are able to locate it. The `immutableMetadata` json object would look something like: + +```json +{ +"standard": "IRC27", +"version": "v1.0", +"type": "application/json", +"uri": "https://my-awesome-nft-project.com/{id}.json", +"name": "#4 My Awesome NFT" +} +``` + + - Note the {id} substitution in the `uri` field. Clients should replace `id` with the `nftId` property of the NFT output, without the `0x` prefix. + +### 3. Fetching content of a collection + +Since each NFT within the collection has the `immutableIssuer` set as the `collectionId`, it is possible to query the +UTXO Indexer API ([TIP-26](https://github.com/iotaledger/tips/blob/indexer-api/tips/TIP-0026/tip-0026.md)) to get the outputIds for all +NFTs that belong to the collection. Then the output objects can be fetched via the Core API ([TIP-25](https://github.com/iotaledger/tips/blob/stardust-api/tips/TIP-0025/tip-0025.md)): + - GET `/api/indexer/v1/outputs/nft?issuer=collectionId` returns the outputIds that have `collectionId` in the `issuer` field. + - GET `/api/core/v2/outputs/{outputId}` returns the NFT output itself. + +The Collection NFT can be fetched via: + - GET `/api/indexer/v1/outputs/nfts/{collectionId}` returns the outputId of the Collection NFT (if not burnt). + - GET `/api/core/v2/outputs/{outputId}` returns the Collection NFT output itself. + ## Rationale ### Interoperable Standards -For a unified IOTA NFT ecosystem the standards have been designed to support ease of integration and cross-compatibility of NFTs throughout the IOTA network. Observations of undefined standards in other ecosystems has illustrated the importance of such developments in the early stages of the technology. Simple defined keys such as `nftId`, instead of `assetId` or `tokenId`, or `tokenURI`, instead of `nftUrl` or `fileLocation`can support a much more interoperable experience for creators and dApp developers with everyone working from the same foundations. +For a unified IOTA NFT ecosystem the standards have been designed to support ease of integration and cross-compatibility of NFTs throughout the IOTA network. Observations of undefined standards in other ecosystems has illustrated the importance of such developments in the early stages of the technology. Simple defined keys such as `uri`, instead of `nftUrl` or `fileLocation` can support a much more interoperable experience for creators and dApp developers with everyone working from the same foundations. Supporting creators is also a key element in driving adoption for the technology, royalty integrations vary substantially in other blockchain ecosystems which remains a challenge for both 3rd party applications and creators in sustaining a consistent and reliable ecosystem across different applications. From cfa52f59a53b649509f72989b10809e28ee3fd10 Mon Sep 17 00:00:00 2001 From: Robert Frank Date: Wed, 23 Nov 2022 12:09:53 +0100 Subject: [PATCH 27/28] Removed from immutable metadata --- tips/TIP-0027/irc27.schema.json | 4 ---- tips/TIP-0027/tip-0027.md | 5 ----- 2 files changed, 9 deletions(-) diff --git a/tips/TIP-0027/irc27.schema.json b/tips/TIP-0027/irc27.schema.json index 77e80ed4e..08bf0578a 100644 --- a/tips/TIP-0027/irc27.schema.json +++ b/tips/TIP-0027/irc27.schema.json @@ -32,10 +32,6 @@ "type": "string", "description": "URI pointing to the resource where the file with `type` MIME type is hosted" }, - "collectionId": { - "type": "string", - "description": "A unique collection ID identifier for the collection" - }, "collectionName": { "type": "string", "description": "A human readable name for the NFT collection" diff --git a/tips/TIP-0027/tip-0027.md b/tips/TIP-0027/tip-0027.md index 65a07780b..5e1ff359a 100644 --- a/tips/TIP-0027/tip-0027.md +++ b/tips/TIP-0027/tip-0027.md @@ -165,7 +165,6 @@ Additional keys that must be included in every NFT schema: ``` Optional, but recommended keys, that may be included in NFT schema include: -- `collectionId` – UTXO string (nftId) of the collection NFT that minted this NFT - `collectionName` – alphanumeric text string defining the human identifiable collection name - `royalties` - Object containing key value pair where payment address mapped to the payout percentage - `issuerName` – alphanumeric text string to define the human identifiable name of the creator @@ -180,7 +179,6 @@ Optional, but recommended keys, that may be included in NFT schema include: "type": "image/jpeg", "uri": "https://mywebsite.com/my-nft-files-1.jpeg", "name": "My NFT #0001", - "collectionId": "ed48cfb0e4ac4d4e40174505290ce43bef586cd59721b98cecb4cf02aa34e106", "collectionName": "My Collection of Art", "royalties": { "iota1...a": 0.025, @@ -204,7 +202,6 @@ IRC27 NFT metadata follows the [OpenSea metadata standards](https://docs.opensea "type": "image/jpeg", "uri": "https://mywebsite.com/my-nft-files-1.jpeg", "name": "My NFT #0001", - "collectionId": "ed48cfb0e4ac4d4e40174505290ce43bef586cd59721b98cecb4cf02aa34e106", "collectionName": "My Collection of Art", "royalties": { "iota1...a": 0.025, @@ -301,7 +298,6 @@ For item 4 for example, the metadata is: "royalties": { "smr1q5948....": 0.05 }, - "collectionId": "ed48cfb0e4ac4d4e40174505290ce43bef586cd59721b98cecb4cf02aa34e106", "collectionName": "My Awesome NFT Collection", "attributes": [ { @@ -312,7 +308,6 @@ For item 4 for example, the metadata is: } ``` - - `collectionId` in the metadata is technically redundant, as the immutable issuer field of the output already contains it, but if it's part of the metadata as well, it can be easily verified whether it matches the actual field in the output. If the metadata is hosted somewhere else (not on-chain in the ledger, but off-chain on a server/ipfs) then it is not needed to fetch the output to figure out which collection is belongs to. In case the metadata is not stored in the NFT output but is hosted off-chain, it is still recommended to include information in the `immutableMetadata` field such that clients are able to locate it. The `immutableMetadata` json object would look something like: From 3a964123663cf6e5131aa6e7752cf4d6f772bf57 Mon Sep 17 00:00:00 2001 From: Robert Frank Date: Wed, 23 Nov 2022 15:05:34 +0100 Subject: [PATCH 28/28] Updated header file --- tips/TIP-0027/tip-0027.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tips/TIP-0027/tip-0027.md b/tips/TIP-0027/tip-0027.md index 5e1ff359a..e0c3495fc 100644 --- a/tips/TIP-0027/tip-0027.md +++ b/tips/TIP-0027/tip-0027.md @@ -1,10 +1,10 @@ --- tip: 27 title: IOTA NFT Standard IRC27 -description: Define NFT metadata standard, collection registry and creator royalties +description: Define NFT standard and creator royalties author: Adam Eunson (@AdamCroply) , Merul Dhiman (@coodos) discussions-to: https://github.com/iotaledger/tips/discussions/59 -status: Draft +status: Proposed type: Standards layer: IRC created: 2022-03-04