The Future of NFTs on Kusama: A Discussion on the Importance *or not* of RMRK 2.0 Integration into KodaDot

Hello everyone,

As members of the Kusama and Polkadot communities, we’re all invested in the vibrant ecosystem of Non-Fungible Tokens (NFTs). Today, I wanted to start a discussion around a topic that has potential implications for the future of NFTs on Kusama.

With the RMRK team’s potential shift towards Ethereum Virtual Machine (EVM) support, the relevance of NFTs on the Kusama network could be at stake. The KodaDot team has put forth a proposal to integrate RMRK 2.0 into their platform, aiming to ensure Kusama users continue to have a robust and inclusive platform for NFT engagement. We are still and will be supporting RMRK1 on KodaDot if it keeps bringing value to community.

  1. What are your thoughts on the future of NFTs on Kusama given these recent developments?
  2. How do you think the integration of RMRK 2.0 into KodaDot could impact this future?

A last chance?

Many believe that this proposal could be the ‘last chance’ to maintain the relevance of Kusama NFTs. This belief stems from the significant volume, interest, and activity that Kusama NFTs, particularly with RMRK 2.0, have historically attracted.

  1. Do you agree or disagree with this viewpoint?
  2. What are the potential implications for the Kusama community and the broader NFT ecosystem if this proposal is not supported?

How about data longevity? Do we just let it die?

NFTs represent more than just immediate transactions; they embody value that can grow and be maintained over time, a concept known as data longevity.

  1. How do you see the integration of RMRK 2.0 into KodaDot contributing to the long-term preservation and appreciation of value in the Kusama NFT space?
  2. Considering the historical volume, interest, and activity that Kusama NFTs have garnered, especially with RMRK 2.0, how crucial is it to ensure the data longevity of these assets?

Closing remarks

Lastly, while we are implementing Statemine, the notion that RMRK 2.0 should just “die” seems counterproductive.

  1. What are your thoughts on this matter?

I look forward to reading your thoughts and engaging in a productive discussion about these important issues.

With regards
Damsky, COO of KodaDot

We have also published a thought-provoking article. Feel free to have a read:

Shall we consider the migration of RMRK2 NFT to Statemine onchain NFTs by using the new pallet?

Currently, the main missing piece I see in the pallet-nfts is handling the nested items. Though I’m planning to start working on this pretty soon.
On the other hand, the majority of rmrk nfts are not nested, so we could migrate around 80% of nfts straight away.

The new pallet would allow us to continue the experimentation with the nfts tech like creating evolvable nfts or utilising the xcm.


I agree with Jegor here. If we can find an effective solution for the nesting logic and add this feature to the new NFTs (Uniques v2) pallet then we have the basic building blocks for RMRK 2.0 core functionality.

Another thought I’ve been wondering about was enabling ink! Smart contracts to make calls to the NFTs Pallet through chain extension then create the equippable logic as a PSP standard & that can help remove the complex logic out of the pallet implementation. I haven’t thought too much into this idea though.

Yes, that would be doable!
Statemine support is ongoing and I believe it will be available on KodaDot end of May.

This would be amazing. I’m pro!
I sense the number is even lower, which is using the nesting function… :slight_smile:

Can you briefly draft what would be use case? Like offset logic to SC layer to grow it in an opinionated way per-use-case?

I’m speaking from our use case on Phala Network with PhalaWorld using the RMRK 2.0 substrate pallet (tightly coupled to Uniques v1 pallet).

With our experience helping with RMRK pallets, the complexity of the equippable logic can have many opinionated designs based on various use cases. A simple example would be 3D models vs 2D models and the many different file format standards within each category. I can imagine that pragmatic developers would like to contribute/use different SC standards for building equippable logic based on specific file formats & then devs can extend from these standards with their opinionated designs for their use cases.

Another example would be if the equippable logic were pages within a book. This use case needs to generate a book that is in chronological order & readable as a whole. The similarities of the book vs 2D models vs 3D models stop at the nesting logic, and this is where I see offsetting the logic to SC layer as best way to allow for multiple equippable standards to be proposed/maintained by the community.

I someone would take the effort, we are happy to support this effort

Checking back on this thread, we meanwhile support Statemine nft-pallet in

We will make it available through our KodaDot API and happy chat further make NFTs on Polkadot sustainable and available.