Some questions that came up during a discussion session on the Direction Channel:

• Once the end to end scenario about once this proposal is complete, what is gained from the developer ecosystem. what can be done by users? Can I launch my own NFT game on this platform? If so will it be through contracts or pallets?

Users will have a platform to deploy applications such as Substrapunks. And Yes, you can launch your own NFT game through contracts.

• So what about this network is better than a generalized smart contract platform?

It includes this pallet

• how will I, as a creator of a collection, add utility to that collection? I am seeing the answer is an additional smart contract that will interface with this pallet?

In the case of Unique Network this is correct. RMRK does not involve a pallet but you as a creator can: publish art, create membership NFTs which can be scanned and even consumed (burned) by applications who adopted your NFT, build games and collectibles. There is no need for smart contracts in RMRK, only standards. If the tools and implementers respect them, you have utility in the same way as you would with a smart contract.

• How do you add value without onchain logic?

There is a utility of tokens with no onchain logic. For example if you have a game where the game logic runs offline. You can check the ownership of tokens, for example this user with that address own "mythical sword". If yes the token is activated on the game. In fact most of game run their logic offchain and use the chain to verify ownership. Token with no smart contract logic are easier to manage and issue and fit different purpose. In the case or RMRK.app (part of the overall strategy) there's no logic on-chain per se, just interpretation of interactions by applications. You can see that as logic, but it's not "enforceable" by the chain

For example in our game Spells of Genesis, there are offchain cards (that you receive easily for free) and there are onchain cards. There is a feature named blockchainization allowing to move a max leveled card to an onchain token. But it requires you to progress a lot trough the levels. We deliver those token as a reward and people are actually farming for those. They do that because their tokenized cards can be sold on markets. So it's a tangible onchain reward we distribute following our rules. In other hand buying strong cards from other players will help you progress faster.

-** In the case of Unique Network: regarding your plan about adding utility to tokens generated on unique network. If I understand correctly, you have a pallet which manages the underlying asset with very low level functions. And then you expect users to create contracts which will add utility and on-chain logic to these NFT tokens. Is that right?**

Yes, more that we implement as rich as possible common logic in NFT pallet and expect users to implement application specific logic in smart contracts simply because we can't know what application specific logic is at the time we make NFT pallet.

Unique will be a parachain, with functionality needed by major NFT use cases. NFT pallet, smart contract module (we currently can not use outside chains for that and that capability is 6-12 months away), and many smaller components. So if a game producer wants to make a game with NFTs he can use smart contracts for gaming action and make NFT collection in several ways. Or if we go ahead in the roadmap a Unity game producer can use the API to connect their game to a collection of NFTs on Unique. Or Ethereum game can port everything they made and create a Polkadot and Ethereum game in a day, perhaps switch over. Games on Unique can be freemium, can appeal to gamers who do not have any blockchain knowledge. We can take all our code and make a Plasm-based chain for the high scalability games. These are just a few major ideas for the gaming use cases, which is only one of many. Anyone can make a collection anyway they want, or build a game, or use NFTs anyway they want, with smart contracts being the main tool to do it. Ink, then others.

• Who will be allowed to create new collections on Unique?

Anyone can create collections or make a solution to make collections.

• What are the major advantages to having the NFT pallet versus having the asset also controlled by the smart contract? It seems that free transfers of NFT assets may be one upside, but are there others you have in mind?

I can name a few:

1. Redundancy. Smart contracts often implement extra functionality that is App specific on top of ERC-721. That will make developers want to instantiate their own version of NFT contract every time.
2. Having one single interface for all NFTs vs. a standard will be more error prone
3. NFT Pallet will eventually consume less resources because there is less code needed to create a collection and manage tokens
4. In case if collection owner sponsors transactions, it is easier to protect collections from spam than smart contracts

• How does the PolkadotAssetJS team plan to develop their platform on top of UniqueNetwork when that itself is still under development?

The portion of NFT pallet that PolkadotAssetJS is going to integrate with is already in place and working in the TestNet.

• when PolkadotAssetJS it is done, what will Kusama get?

Kusama strategy is to push NFT, in order to get NFT we need content producer developers and users.
PolkadotAssetJS allows:

1. Developers :

• Engage a smooth transition from a previous chain to Kusama
• Easily issue, tokenized asset, send, read the chain
• Have a consistent flow of managing NFT's across multiple Kusama parachains and palets. (No need to relearn and modify the workflow of a dapp when a pallet logic changes)

2. Users and artist

• Have a web application allowing to tokenize their creations on Kusama NFT enabled chains without technical knowledge
• To summarize we beleive users and developers tools who are creating content are key for Kusama adoption. More convinience more content, more users

Of course the project is called "Polkadot" Asset JS because historically we've been discussing this with Web3f for Polkadot but as Kusama has a NFT oriented strategy and we want to move fast. It make more sense to start collectibles and games dapps on Kusama.

Kusama is more suited/intended for creative usecases like art and gaming, the primary way those ecosystems interact with blockchain tech is using NFTs - how do we encourage creators to build on top of/using Kusama without giving them a tech stack they are familiar with? Hence, building a platform layer solution for "NFT support" makes sense to me - be it "use RMRK or Unique directly" or "don't think about it, let the Asset js libs handle the complexity for me". There are so many NFT solutions already, that is a barrier to entry if there aren't tools around it

---

For further clarification, the steps of the overall strategy, on which this project is included, are:

1. Development and implementation of RMRK.app and PolkadotAssetJS application

2. Development of Unique Network and PolkadotAssetJS compatibility to be used by Unique as well as RMRK.app

3. Deployment of Unique network on Kusama

4. Deployment of NFT Marketplaces on Unique and/or other Parachains.

From all of these projects coming together to frame an NFT strategy for Kusama, PolkadotAssetJS (proposal on the above post) seeks to submit a treasury proposal to the council. The strategy sees RMRK App as a good candidate for an "early NFT implementation" until the full strategy development takes place, and can after stick around to complement the functionality.

Milestone 1 update



There are two important parts of the delivery, a web application designed to display NFT collections, transactions, and address the balance of Kusama collectibles. With the first implementation of RMRK based NFTs.

The gallery is available for preview here :



Go to the Gallery

The gallery front end is set to use polkadotAssetJS library, which we renamed to CSCanonizer, a library allowing the abstraction NFT structure to allow management of completely different pallets and NFT standards but keeping a consistent workflow.
The CSCanonizer objective is to describe NFTs and blockchain transactions in a canonical form allowing to define of token assets and interactions compatible will present and future NFT pallets. A small adapter for each pallet is required in order to express the NFT in its canonical form.
The CSCanonizer canonical form allows developers to easily integrate NFT ownership management without the need to adapt to each pallet format and standard saving development overhead when moving to a new pallet or chain/sidechain.
This approach facilitate also game developers who want to move from Ethereum to Substrate solution.

We developed a module called RMRK jetski scanning the Kusama blockchain and reporting RMRK NFT events and convert these into a canonical structure.

The source code can be found on GitHub here: https://github.com/Millord1/Ksm_rmrk

Additionally, due to RMRK constraints, we had to develop additional important features outside of the initial scope of this proposal.
In fact, RMRK doesn’t allow to directly query the blockchain from important information such as an address balance, or verify if a send transaction is actually valid (enough balance, correct supply…)

The only way to get accurate information is to parse the whole blockchain to understand the current state of an address or a token.
Thus we had to work on a server-side solution to store the state of and address or an NFT. With server-side validation and balance computation.

We integrated RMRK workflow on our existing work in progress CSCannon library.
CSCannon library is an open-source PHP/MySQL solution allowing to index NFT data also canonical form. This way we are able to store NFT and blockchain states server-side while exposing data through and API.


CSCannon GitHub : https://github.com/everdreamsoft/CrystalSpark-Cannon



We developed a protocol called Gossip allowing us to dispatch data from CSCanonizer to CSCannon and the other way around. CSCannon can just listen to gossip sent by CSCanonizer and reported by Jetski to update the blockchain state. The CSCannon can validate all RMRK and build address balance and define the state.
Anyone can set up his CSCannon instance to index blockchain and feed data either with the PHP code or feed it with the CSCanonizer as all part are open source (yet not documented)

For RMRK NFT we run our own instance of CSCannon and expose an open API that can be queried by anyone to get Kusama NFT balance, for example, wallet provider or front end galleries. The API is expressed in the canonical form so it will return consistent data structure whether the NFT is an RMRK or an ERC-721 for example

The API example can be found here

:

http://ksmjetski.everdreamsoft.com/api/v1/events


We will provide full API documentation next.


Today the ksmgallery is heavily using the CSCanonizer -> The API -> CSCannon

The heavy lifting of the project has been done. Our final step toward the delivery of Milestone 1 is to polish the gallery UI, from the comment we received, and write some code and API documentation and class diagram.