[Treasury proposal] PolkadotAssetJS an NFT interface for developers and artists
Hi everyone !
As part of the NFT strategy presented here Everdreamsoft aims to submit a proposal to the council to build a library for asset tokenization features (NFTs) on the top of Kusama network.
PolkadotAssetJS wants to simplify creation, management and transfer of tokenized items, commonly known as NFTs, in order to allow game developers, artists and designers (and by extension all content providers) to experiment with NFTs and to be able to leverage the full potential of blockchain, without extensive knowledge of the technology.
Our project makes an abstraction from the blockchain technical specificities and provides its users with a user-friendly interface.
We provide developers with simplified tools allowing them to deploy a token contract, mint a token, assign metadata (the asset) and transfer it In less than 10 lines of code. PolkadotAssetJS helps to flatten the learning curve and saves their time.
End users will be able view and transfer blockchain collectibles across all compatible Kusama sidechains by using a web interface.
Being in the field of blockchain gaming since 2015, we see the NFT strategy as the best way to exploit the blockchain diversity and to democratize the usage of NFTs.
Read the full proposal here
Comments (6)
Some questions that came up during a discussion session on the Direction Channel:
Users will have a platform to deploy applications such as Substrapunks. And Yes, you can launch your own NFT game through contracts.
It includes 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.
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.
Anyone can create collections or make a solution to make collections.
I can name a few:
The portion of NFT pallet that PolkadotAssetJS is going to integrate with is already in place and working in the TestNet.
Kusama strategy is to push NFT, in order to get NFT we need content producer developers and users.
PolkadotAssetJS allows:
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:
Development and implementation of RMRK.app and PolkadotAssetJS application
Development of Unique Network and PolkadotAssetJS compatibility to be used by Unique as well as RMRK.app
Deployment of Unique network on Kusama
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.