IOTA NFT Standards Proposal

[AdamEunson]

IOTA NFT Standards

Standardised resources for a more secure and thriving IOTA NFT community.

A collection of proposed NFT Standards for Authenticity, Ease of Adoption, and Creator Support to unite the creators and community in the iNFT space.

Introduction

The potential for the IOTA NFT (iNFT) space to become a powerful force in the global NFT eco-system is huge. There are however certain aspects that could be addressed and streamlined to support easy early adoption from NFT projects and creators, to encourage early growth utilising “IRC1” protocols to support artists as they enter into the iNFT space.

From our research into other NFT eco-systems certain safeguards and creator features that prove to be essential in the growth of NFT eco-systems are currently not standardised in the iNFT space and implementing them in these early stages could provide increased value and adoption in the early stages of the release.

Primary concerns and feature requests in most NFT spaces include the validation of authenticity of collections, the support of creators through commission-based systems, and a simple and accessible metadata schema that supports these elements.

This proposal outlines key areas that we feel could really increase the adoption of the proposed iNFT standard to build a strong and resilient NFT eco-system from day one.

The proposal includes:
- A Standardised Policy ID system to support easy verification of collections.
- A community-maintained Policy Registry to support open-source transparency for Policy IDs.
- A Standardised Creator Royalty System to support creators with residual income.
- A Simplified Standard Schema for NFT meta-data to provide accessible and easy-to-integrate NFTs for web3 and dApps

Our work on standardisation proposals will be guided by Levente Pap and supported as a fully open source community engaged project.
 

---

Standardised Policy ID system

Verification of authenticity in NFT collections is a big area of importance. Counterfeit NFT creation is common in every NFT eco-system and establishing a solid foundation to put in place precautions from the early stages should be a priority.

The Standardised Policy ID system includes a native tool that supports independent creation of secure Policy IDs that can be associated with a creator or collection that can be integrated into NFT schema to provide authenticity of tokens on the open market.
Further to the creation of the Policy IDs a global registry will be created for creators to register their collections allowing for individual collections to be recorded and to prevent duplication of collections from impersonators.

The secondary approach on the new native Tokenisation protocols will allow the use of an individual “collection” NFT, that in turn mints all the other NFTs within its respective collection. This approach is only possible through the IOTA tokenisation framework and will support only native assets. The ability for a creator to add their unique issuerID is a standard in the system, all NFTs display the ID of their creator, furthermore with the use of a collection NFT, subsequently, every individual NFT in the collection that is minted directly by the Collection NFT, will then contain not only the ID of the creator (issuerID) but also the unique ID of the collection from the collection NFT.

A collection NFT also has versatility and can be locked in fixed supply drops or stay unlocked to mint more NFTs for more of rolling mints that are an ongoing project. It also allows for the potential ownership of collection creation rights (minting copyright) to be distributed by sale of the collection creation NFT.

Official Policy Registry

The official policy registry is an open-source collection of policy ID registrations that can be easily implemented into any NFT Dapp, Marketplace, or Exchange. The system supports an easy onboarding for users to create and register their policy IDs and will be maintained by the community in an open GitHub repository to offer full transparency and accessibility to the information.

The open-source nature of the system supports a secure eco-system for creators and buyers to ensure official collections are clearly maintained as verified through the iNFT registry system. This level of authenticity allows for Marketplaces and Dapps to easily keep their systems up to date with verification and provide trust in verified collections on their systems through simple API integrations.

Standardised Creator Royalties System

When writing Marketplace or sales smart contracts, NFT metadata is inserted to support creator royalties as defined in the Standardised Creator Royalties and Standardised NFT Schema Basics. This system supports extracting an IOTA wallet address where royalties should be sent to during every trade. The royaltyAddress will be added to the smart contract as a seller address from which a percentage of funds, determined by the royaltyPercentage field, shall be sent to upon completion of the transaction, with the remaining balance of the sale to go to the seller (minus any additional percentages removed by third parties such as marketplace fees).

By including a Creator Royalty system in the creation of decentralized marketplaces and NFT swaps, this provides early support for creators that some other networks still don’t support. This “Creator First” approach will encourage more creators to adopt using IRC1 as their NFT creation protocol of choice and bring an increased number of artists over to the IOTA network.

Standardised NFT Schema Basics

The proposal is to support a simplified standard for metadata json to make it easier for projects to deploy NFTs and for marketplaces to manage metadata in a simplified manner. Through the creation of an easy-to-use standard for NFT metadata it will provide a lower barrier of entry for creators looking to move over to the IOTA NFT space and make use of the IRC1 protocols.

The key elements included in the metadata would also support key features specific to NFTs and encourage early adoption through a supporting number of features such as Policy ID for collection verification, Artist Commission for residual income from NFT creation, and standardised NFT data, such as name, collection, artist, etc.

A basic example is presented below, although extensive research for the optional and required data to be included to cover all use cases will require a lot of further exploration.

// fields marked with ? at the end are optional and can be ignored
{
  "IRC1": {
    "assedId": {
      "assetName": "Asset Name",
      "issuerId": "1234567890",
      "collectionId": "1234567890",
      "collectionName": "my collection",
      "image": "ipfs://myaddress",
      "video?": "ipfs://myaddress",
      "audio?": "ipfs://myaddress",
      "file?": "ipfs://myaddress",
      "royaltyPercentage?": "4.5",
      "royaltyAddress?": "iota1234567890",
      "description": "A really cool NFT",
      "creatorName": "John Doe",
      "traits": [
        // optional characterstics go here
        { "trait_key": "rarity", "trait_value": "1 of 100" },
        { "trait_key": "color", "trait_value": "green" }
      ]
    }
  }
}

Expanding Standards

With such a versatile technology as tokenization, the varied use cases can provide an overwhelming array of different schema requirements. Within the early discussion, it is apparent that one standard will not suite all practical uses for NFTs. So, to further extend the functionality of the standards a generic base standard should be defined first to provide a bedrock for the most common use cases in the space, to later be expanded to define edge and case specific standards that can be utilised across a number of different areas.

The primary use case would focus on NFT standards for digital files, primarily images and video, to extend further into audio, documents, IP, and then to later look at more advanced use cases such as digital twins, and other edge uses.

A proposed suggestion towards schema based standards that define specific schema to individual use cases has been presented which would allow the additional expansion of the standards to evolve as the technology further expands into other territories. Reference to a possible high level implementation of a schema based standard can be read about here

Versioning

As with any technology, standards also change. An early implementation of versioning can support the longevity of the standards for developers and dApp creators over updated standards changes. With NFTs being a persistent technology, for applications and users to maintain support for new updates, as well as older versions, introducing versioning from the start will enable projects to build in confidence that they can continually support older and newer versions of the standards within their applications. An overall outlook of versioning needs to be further researched and added as we progress.

An example of how this versioning may look is placed below:
{ inft_version: 1.0, filetype: AUDIO, uri: “ipfs://myaddress” }

Adoption Challenges

The main challenges that we face in implementing a standardised system is the universal adoption by providers. The use of commission and policy identification are reliant upon service providers, Dapp creators, and NFT Marketplace providers integrating these systems into their applications.

The use of such systems would provide greater benefits to any application developer in the long run with universal, interoperable support for artists and a foundation of trust through verification which, when provided from the start, can encourage NFT creators and NFT buyers to trust and engage with their applications over alternatives that don’t support these levels of verification and support.

Contact:

Discord – adamski#0458 / merul#0001

[r-sw-eet]

I am not sure if we can cover every possible application/usecase with one standard (json / scheme). After all, it gets bigger and bigger and in the end, you only have empty attributes. It is certainly nice to have a general standard for a "new kind of nft", where it is not clear yet, how much adoption of it will take place. But for some very well known kinds of NFTS (especially in "digitizable" arts) maybe we could have "sub"-standards for music (songs), movies, pictures, game (character) items, etc...

It also could well be covered with a sub array, like the traits you suggested. But they still would have to be defined in an own standard (with a version number, possibly with back compatibility).
For example, if an album would be a collection NFT, for a song's individual NFT, i could imagine having following not yet mentioned properties: lyrics (with timestamps, translations, ...) general artwork, album cover (front/back), tabs, tracks, official lyric/music videos, proposed genre. Or maybe some of those would be their own nfts...

Then we should also collect all possible (already occasionly mentioned) use cases, which are still in their infancy. For example, having offline/hardware as individual or collection NFT, such as properties, cars, paintings...

[AdamEunson]

I completely agree. When it comes to standardising an exceptionally versatile technology, one glove will not fit all. We can always start in the popularly adopted realms of digital files, such as images, video, audio, etc. and define broad standards for these. The versatility of traits in the schema provides a number of customisable and versatile options for creators over the majority of current popular use cases in this domain. But as you have mentioned there are a number of edge and newly emerging use cases that have yet to be really exposed and the basic standard format would not be applicable in some of these areas.

I agree that sub-categorized standards should be built out in time, as new use cases are defined and other contributors engage in the eco-system to put forward new standard suggestions. Leading off with a general digital file NFT standard and expanding to specific audio, video, image, IP, document, written word, etc... as well as in time to more wilder physical use cases such as digital twins, etc.

Really awesome inputs already, I'm excited to see how this progresses.

[ChristopherWalz]

Why not gear towards https://schema.org/docs/schemas.html ? Define different types and add new ones when they come up.

[AdamEunson]

This is very similar to what we are envisioning, a schema definition for each use case would make a lot of sense, especially to support expansion into new areas of the tech. This will also allow 3rd party dApp providers to integrate the specific schema they require for their application whether it be image, audio, video, document, access, digitalTwin, etc. This is perfect. Thank you!

[x-Tokenize]

@AdamCroply Love the proposal! We are currently working on a proposal for NFT metadata standards on the XRPL network which makes use of schema definitions. Feel free to check it out here XLS-24d:Metadata for XLS20d NFTs. I'd love to connect and further discuss NFT metadata standardization utilizing this approach.

[smuser90]

Really like the proposal! For early versions I think the most important thing is that the schema provides mechanisms for growth to support unanticipated use cases. Let’s face it - we still don’t have NFT killer apps in any ecosystem yet.
To accommodate extensions and multiple file types / use cases backing the token, we could parameterize the file types.

{ inft_version: 1.0, filetype: AUDIO, uri: “ipfs://myaddress” }

That mechanism passively enforces having a single file backing the token. It also makes it a bit easier on client parsers since they can just check the schema version and default to some generic representation for file types they don’t know.

Super excited to see how iNFT evolves over the medium term!

[coodos]

This sounds really good and I like the idea on this. We will look into this further for sure :)

[AdamEunson]

Versioning is definitely something we should integrate from the start. Primary standards development is definitely going to be a work-in-progress, and allowing developers the ability to support older versions and newer versions of the standard will really help in maintaining longevity of support of NFTs in their applications as the standards develop. Backwards compatibility of early stage NFTs and the more recent ones will really allow long-term stability in the eco-system.

[Sibb0x5e]

I think one point to consider is how far we go with the tradeoff between code readability and compression of the metadata, taking the future dust protection for native assets into account.
Imo we should compress as much as possible cause those costs / byte will add up.

I'll assume 1000i /vByte for simplicity.Here is an example of what i mean:

"commissionPercentage": "","commissionAddress": ""

Is about 50Byte large

whereas something like this

royalty:{0:"",1:""}

would be 19Byte, resulting in 21kIOTA cost savings for end users

I also thought a bit about how you could structure metadata in a logical way. (I dont know much about how other ecosystems define their nft metadata so this might a "naiv" pov)
I think its difficult to build a standard which expects alot of mandatory data.
Maybe we should think about something more flexable which also supports future developments, since every project has its own requirements

So maybe we could define the payload of a nft in the structure of

head : {}
lib: {}

Inside the head container you could store single parameter or define a set of expected(but still optional) keywords.
The lib (call it lib cause i think it shows the concept well) container is for more complex structures. So one approach could be that marketplaces and such would tell what modules they require to execute certain functionalities. Here we could define modules like a royalty module, image module or wrap entire existing tokenstandards.
If one is not satisfied with existing modules or need own more complex structures you could use a custom section for head and lib.
So this would basicly a standardized way to access configs of a nft while beeing flexible.
Also every module could have a optional custom section which would allow to implement own logic, but is not guaranteed to be read

Acces to those props would be like

nft.head.issuerId
nft.lib.royalty
nft.lib.1155
nft.lib.custom.example

With this approach you would only need to agree on cetrain modules and enhance them.
Versioning could be implement in different ways for example:

• a global version like nft.lib.v1
• make require field in head, give every module a ID -> head.req = {1,1155}
• define version in module

Thats it, would be glad to hear your thoughts :)

[alexlehnert]

GREAT ideas in here! love the idea, we had similar approaches when it comes to sending data from sensors - and you want it to be as cheap and lightweight as possible. GREAT 🚀

[Sibb0x5e]

@coodos Sure i'll contact you on discord :D

Really cool that you like the idea!

[briansztamfater]

I really like the vision of having a basic schema, and modules to extend it to fit every possible use case. +1 to that approach.

Regarding on-chain vs. off-chain: IMO that should not be part of this (metadata) discussion, because we would be talking about implementation and we should talk about interfaces, not implementations. For example, ERC-721 and ERC-1155 are widely adopted, so we should define metadata standards that could be implemented into both standards, either if they are stored off-chain or on-chain. Native Assets should also follow defined standards.

Said that, I agree we should pursue an as minimal approach as possible to allow developers decide between cheap off-chain and on-chain storage solutions.

Also royalties in NFTs deserve a separate discussion. There's a standard in Ethereum but I didn't notice too much adoption.

[AdamEunson]

I think the varying degree of functionality between on-chain and off-chain warrants the need for different standards, metadata off-chain can result in large files that are extensive in traits and further file information, whereas on-chain will really need to be compressed, minimal data. Trying to ensure an NFT payload remains under 1kb is going to be a challenge in many cases, but this a recommended 'top-end' estimate for size, due to network payload requirements, smart contract operations, etc.

With off chain predominantly being more versatile in it's uses, with higher payload, more extensive data allowance, then this standard can allow us a bit more flexibility in the payload size, and could present the opportunity for a more accessible format of schema, with on-chain being a more condensed and minimalist form of standard.

[Sibb0x5e]

Throwing some more ideas in :D

I think this approach could also include the suggestions from @smuser90 and @xPathin

It could be done by either defining a media module or if it makes sense do it more precise with for example a image module (or audio, etc.)

The payload type mentioned could be for example a trait module or ofc your own custom module

The head could also have a property which stores the information where the metadata is stored

So you would only have to read the head data from a nft to know where to look for the metadata and also if the used setup is compatible with your system by reading which modules are required for the nft

Example external erc721:

nft.head.location
nft.head.require

Example onchain erc721:

nft.head.location
nft.head.require

nft.lib.721

-> read from wherever you stored the info depending on the config inside head.location

[jmcanterafonseca-iota]

it would be good that the metadata could be represented using JSON-LD and looking for alignment with schema.org including reuse of properties from schema.org

[xPathin]

Instead of traits I would really love to see a payload and payloadType field in the NFT standard.
A payload type can be "traits" and the payload then for example would then be the traits array.
Some NFT can have traits, while others might be just pure serialized data.

[coodos]

Ser, this sounds like a really good idea and I would love to remove the dependence NFTs have on IPFS currently, IPFS is a very unreliable service and it is kinda weird in the sense that if my node goes down and other nodes have not copied my file and pinned it then it will all get rekt.

Having it on chain is amazing and seems like the next logical step, love this :)

[AdamEunson]

I think in many cases on-chain and off-chain will be used in various different ways, and payload is really important here as a focal topic. Minimal code to reduce and simplify the payload size would be ideal in on-chain scenarios, whereas a more engaging structure that is easy to work with can be supported as an off-chain standard. I think it's important that we cover both in the standards

[dumdave]

Apologies if I missed this in the above, but have you made any plans for fractionalised NFTs as per the Arben Kane article below which seems a pretty good explanation of how # might in time be set by the market.
https://medium.com/@arbenk/fractionalized-nft-f-nfts-all-that-you-need-to-know-46bc06ea486d

[dumdave]

Agreed that a simple standard for now is better!

I think in future you will see fractional ownership far wider than the cases you suggest though. We will see.

[anistark]

Counting on it.

[r-sw-eet]

But are fractionalized NFTs not a solution to the problem of high minting / reselling / swapping cost due to protocoll fees. If we have a collection NFT and make it own so many NFTs as fractions as we want, wouldn't that have the same effect? (Because we are feeless and dont care)

[AdamEunson]

Fractionalized NFTs are a very interesting topic and one that the IOTA tokenization framework is highly suited for. With NFTs being able to mint other NFTs this allows owners to mint a fractionalized collection (much in the same way the collection system might be standardized) that can support part ownership of the main NFT. This could not only be applicable to things like real estate and business, but also in areas such as music contracts, publishing rights, copyright ownership, etc. Anything where shared ownership is predominant.

[anistark]

Of course there can be many use-cases for it.
But we won't need to add everything in a single standard. Better to keep it iterative?

[AdamEunson]

There are so many amazing inputs and use case suggestions that could really expand from the initial standard. It would be interesting to maybe put together a working group to discuss everything in detail with a focus on an initial main standard that can then be expanded upon to cater across the different iterations and use cases to support multiple standards for each separate required utility.

[Ox24]

Thats sound great. Its really hard to keep up with these different ideas in this discussion thread. Maybe a first step would be to put these ideas into different models and discuss them together. Doin a hands on session would be great too!

[dumdave]

As a slightly mad aside, or maybe commonplace and I have never heard of it ...

Would it be possible for a straightforward image type NFT to have a tiny (say 100x100 pixel square) area that is not displayed in the marketing of the NFT but contains a signature, or a number, or just artwork. That small square is encrypted within the ownership of the NFT. Only the first buyer gets the key.

Now tell me why I am an idiot!

[AdamEunson]

I think this lays out of scope to the NFT Standards, but is definitely something that could be implemented in a number of different use cases.

[stereoIII6]

Hi guys ...
Lets talk about DIAS
We are planning to implement the D.I.A.S "Decentral Interactive Asset Standard" for the next generation of NFTs. Please share your thoughts on DIAS and the slides we have prepared for you.

Get informed on =>
https://www.canva.com/design/DAE4XzwIxzc/MD9wBD5cqaFwTEcaAVhgOg/view?utm_content=DAE4XzwIxzc&utm_campaign=designshare&utm_medium=link&utm_source=sharebutton

Greetings & blessings from Berlin

stereoIII6

[stereoIII6]

A bit of context in terms of interactive NFTs and what im building to get everyone on the same page !

https://www.youtube.com/watch?v=2kpdOoW8in4

[stereoIII6]

https://twitter.com/7YP3stereo/status/1493952646448824328?s=20&t=njnmlfLzN6sKSCgdAc-zSw

[hassping]

Hi Guys,
Regarding the Standardized Creator Royalties System, can we call it Standardized Royalty system? The multiple addresses and rates concept is perfect, but clarifying that the feature is not limited to creators only. In case someone wants to use the royalties to not only reward creators. For example first buyer, or winning gamer.

[sdellava]

I think this proposal is very well done. I just have a question that can possibly be later converted into a suggestion. Why not link to the OMG DIDO Standard?

The generalitization of NFTs has already been studied extensively by OMG who presented the DIDO standard, Distributed Immutable Data Objects. Here some details: https://www.omg.org/hot-topics/distributed-immutable-data-object.htm#:~:text=DIDO-,Distributed%20Immutable%20Data%20Object%20(DIDO)%2C%20v1.,and%20consistency%20across%20the%20network

https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.2_views:2_tech_views:2-nodenet:3_nodearch:2_ido

I don't know arguing that we should simply refer to the DIDO standard, but I think if our standard was DIDO compliance we would have an advantage.

[sascha1337]

Hey guys, i'm reaching out here as a member of Gravity Bridge's ICS721 Workgroup.
We are collaborating together across ecosystems, with nearly all cosmos based NFT marketplaces, on RFC drafts and implementations, to allow the NFTs minted by different Marketplaces being interoperable for all cosmos SDK chains via IBC (inter blockchain communication) and maybe XCM(polkadot)

Why do i mention this here? Gravity Bridge started workin on some NFT bridge allowing ERC721/OpenSea metadata type of 'EVM NFTs' to be straight bidirectional bridged between Cosmos IBC chains and ETH / EVM based blockchains -

IOTA seems to accumulate quite some momentum at the NFT ecosystem meta-/'soonaverse'.
Due to the nature of the DAG based 'nakamoto consensus' IOTA Smart Contract Protocol and its ability to spawn on-demand, new, in parallel executing Ethereum virtual machine (EVM) blockchains with full ETH JSON-RPC // MetaMask // Solidity compatibility

I have a strong feeling that some collab // a few skilled ppl from IOTA's NFT scene would be some great addition to that workgroup, we have the same goal there, literally discussing the same/similar thematic, IOTA is known for being very strong in that standardisation thematic in general,

Erc2981 aka royalties, who and how should they be enforced, where, and in what format to save that metadata ... Would w3c DID maybe play some role in here ? How would we handle mutable / dynamic NFTs, and how to ensure the (meta)data integrity, information / Token Origin, across the relayers
... and so much more.

... finding some common ground and consensus for a solid standard, early enough, would be a huge milestone and benefit for all participants of the today's multi-cross-inter-chain world.

This is some pretty complex topic actually, but also extremely interesting to work on. and i love the fact, that this ICS721 Workgroup has been spawned from the crypto community itself, partnered up with gravity-bridge as some independent 'umbrella', and having so many different ecosystems and chains work together suddenly.

It is truly something, that me personally have not yet seen before.
I think, by now, most people understand and agree, that this DLT/Chain XYZ must win, all others are crap competition mindset is simply obsolete, the future IS the internet of blockchains and DAG's ;)

---

Cleartext: let me know who is interested in having those bi-weekly meetings with us, and joining the conversation // chat // writing specs, giving feedback or critics.

DM me on twitter // telegram and i'll vouch for you to get the fast pass ticket in.

Let me know ur thoughts.
Best regards and success for everyone out there.

[stereoIII6]

Hi ... how's it going ? Thanks a lot for the Feedback and sorry for the late reply. I will def take a close look at the DIDO and try to make it as compatible as i can ... This is some very valuable info to me and i would like to talk to you about this if you are interested ? Feel free to book a meeting with me. Here's my calendar link... https://meetings-eu1.hubspot.com/meetings/stereo-type Greetings from Berlin Aron 'stereoIII6' Ayuk @stereoIII6 // stereoIII6.meta ***@***.***

…

------- Original Message -------

On Tuesday, July 19th, 2022 at 16:45, Stefano Della Valle ***@***.***> wrote: I think this proposal is very well done. I just have a question that can possibly be later converted into a suggestion. The generalitization of NFTs has already been studied extensively by OMG who presented the DIDO standard, Distributed Immutable Data Objects. Here some details: https://www.omg.org/hot-topics/distributed-immutable-data-object.htm#:~:text=DIDO-,Distributed%20Immutable%20Data%20Object%20(DIDO)%2C%20v1.,and%20consistency%20across%20the%20network I don't know arguing that we should simply refer to the DIDO standard, but I think if our standard was DIDO compliance we would have an advantage. — Reply to this email directly, [view it on GitHub](#59 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AIEO2XJ73A3Y3LUWAL65DE3VU25QBANCNFSM5NCSY2MA). You are receiving this because you commented.Message ID: ***@***.***>