TIP-27 IOTA NFT standards

tips/TIP-0027/tip-0027.md

@@ -0,0 +1,320 @@
+---
+tip: 27
+title: IOTA NFT Standard IRC27
+description: Define NFT metadata standard, policy registry and creator royalties 
+author: Adam Eunson (@AdamCroply) <[email protected]>, Merul Dhiman (@coodos) <[email protected]>
+discussions-to: https://github.com/iotaledger/tips/discussions/59
+status: Draft
+type: Standards
+layer: IRC
+created: 2022-03-04
+---
+
+
+# iNFT 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.
+
+
+### 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.
+
+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 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.
+- **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 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
+
+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.
+
+`issuerId` 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`.
+
+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.
+
+- `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"
+  }
+}
+```
+
+### 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.
+
+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%
+
+{
+  ...
+  "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.
+
+```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 `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:
+
+- `IRC27`
+
+
+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
+{
+  "standard" : "IRC27",
+  "type": "image",
+  "version": "v1.0",
+  "object": {
+```
+
+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
+{
+  "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",
+    "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
+{
+  "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",
+    "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
+{
+  "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",
+    "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"
+    }
+  }
+}
+```
+
+
+## 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.
+
+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.
+
+
+## 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.
+
+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`
+
+### 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/).