Create xcNFT.md

[dudo50]

Project Abstract

xcNFT is a common good pallet/substrate module meant to enhance the cross-chain experience and bring real adoption to cross-chain non-fungible asset sharing in Polkadot and Kusama ecosystems.

Grant level

• Level 1: Up to $10,000, 2 approvals
• Level 2: Up to $30,000, 3 approvals
• Level 3: Unlimited, 5 approvals (for >$100k: Web3 Foundation Council approval)

Application Checklist

• The application template has been copied and aptly renamed (project_name.md).
• I have read the application guidelines.
• Payment details have been provided (Polkadot AssetHub (DOT, USDC & USDT) address in the application and bank details via email, if applicable).
• I understand that an agreed upon percentage of each milestone will be paid in vested DOT, to the Polkadot address listed in the application.
• I am aware that, in order to receive a grant, I (and the entity I represent) have to successfully complete a KYC/KYB check.
• The software delivered for this grant will be released under an open-source license specified in the application.
• The initial PR contains only one commit (squash and force-push if needed).
• The grant will only be announced once the first milestone has been accepted (see the announcement guidelines).
• I prefer the discussion of this application to take place in a private Element/Matrix channel. My username is: @_______:matrix.org (change the homeserver if you use a different one)

[semuelle]

Hi @dudo50. Thanks for the application. I like it and I'll happily share it with the rest of the committee. That being said, have you talked to Unique about their pallet and plans beyond? Based on the timeline in their treasury proposal, they are still working on XCM NFT, so it might make sense to align. They even published a plan to create an NFT Collective to align work across ecosystem players.

EDIT: One thing: can you clarify who the benefactor of the grant will be? The team name at the top is Paraspell, but the legal details give a different name with no address.

[dudo50]

Hey @semuelle ,
Thanks for your feedback.

We haven't been in contact with the Unique team. While we believe, that the NFT Collective is a good initiative, we still believe, that more solid XCM NFT pallet options are viable for the ecosystem. Our solution adds many UX improvements and useful features on top of what xNFT currently offers extending the possibilities further. We also wish for our solution to be fully curated by the community once it is ready and we also had an idea of creating a collective where Parachains could vote on what should and shouldn't be added to the pallet. After the pallet is fully developed, this project could also become part of NFT Collective where Parachain teams will directly curate the next features as we originally planned, making the process simpler for us and the community. We will get in touch with the Unique team about this matter later on once the major part of work is done.

As for the benefactor/legal entity/business that is stated in the application:
The benefactor of the proposal is the ParaSpell Foundation team receiving funds to a business called Michael Absolon with a Business address in Postajok 270/5, 085 01 Bardejov. The Business is registered in Slovakia. I will update the application to reflect this.

[semuelle]

Thanks for the clarification, @dudo50. Happy to proceed.

While we wait for the rest of the committee to review, could you fill out the KYB form?

[dudo50]

Thanks for your approval @semuelle .

We will fill out this form as soon as possible.

I will ping you about the completion of KYB afterwards.

[dudo50]

Hey @semuelle ,

The KYB form has been filled out.

[Noc2]

I'm happy to go ahead with it.

[mrshiposha]

Hello there, I'm a core dev from the Unique Network team.

As I can see, your proposal mainly highlights two issues: 1) the lack of adoption of cross-chain NFTs in the Polkadot ecosystem
and 2) the related UX problems.

I want to leave my comments on both of the matters.

Adoption

First, there's nothing really to adopt if we speak about Substrate-based tools.
The PoC we made in cooperation with Karura isn't a general solution. And other tools have their limitations.

We did make a generalized version of the PoC pallet.
However, eventually, we deemed it too concrete to be a universal solution and not aligned with the spirit of the Polkadot SDK (where we want to include all the XCM NFT-related Substrate tools).
This is the reason why our XNFT pallet hasn't received any updates. We were implementing an abstract and granular solution
that requires less effort to integrate with any existing NFT engine. In some cases, it even doesn't require an additional pallet to support NFT derivatives.

Our current Substrate solution is in the review stage.
We are in contact with the Parity team, so not all discussions happen in the PR at the moment.
This solution includes rich doc-comments, but we will also separately release the detailed documentation and guidelines as they are already covered by the Treasury grant.
It might seem intimidating if you look at the implementation size, but it is relevant only to SDK maintainers, not the users.
The parachain teams will use only the parts they need according to the guidelines we release.

We are developing a general solution so that everyone can benefit from cross-chain NFTs regardless of the particular NFT implementation they have on their chain.
We believe it is important because NFTs have much greater potential than just artwork. For example, they can be various capability tokens, on-chain shared variables, in-game characters and objects, etc.
Because of this potential, it is natural to expect many different NFT engines with unique capabilities to exist on various chains.
We believe all of them should have a clear way of integrating with XCM (including the EVM+Substrate engines).

This is the reason why XCM functionality is separated from NFT engines.

Moreover, our solution aligns with the existing XCM framework from theoretical and practical perspectives.

• Theoretical: Our current work is based on the reserve-based transfer model. The teleports are outside the scope of the current grant but are planned for the future.
• Practical: Our solution provides tools to easily build an XCM Asset Transactor compatible with the XCM executor.

Your proposal doesn't fit into the existing XCM framework. I see you're using Transact to perform the transfers. Essentially, you're modeling the teleports as follows: you destroy an entity on the sender chain and create another on the receiver chain. So, you are attempting to make a custom mechanism without utilizing the transfer model provided by the XCM¹.

Even if you were using the teleports, you'd still need to provide a custom data communication system (again, using the Transact). However, it is inherently not universal. For the XCM data communication problem, we proposed the RFC Draft "XCM Asset Metadata", which we will finalize after the primary XCM NFT efforts.

At this moment, we focused on the reserve-based model since it is the most general way of transferring entities between chains without inducing trust between the communicating parties. There are use cases for NFT reserve-based transfers even without metadata operations. For details, see my Sub0 presentation.

UX

Once enough Parachain teams implement cross-chain NFT support - ecosystem/dapp developers might want to create JS/TS packages that provide simple wrappers lifting developers from implementation complexity further.

There is no need to wait since the XCM interface already supports NFTs. How to implement this interface on-chain is an implementation detail.

We are in the final stages of developing our "Simple XCM" TypeScript library. It supports every XCM version transparently to users, estimates total fees on all communicating chains (thanks to the XcmPaymentApi by Unique Network and the XCM DryRunApi by Parity), reports descriptive errors if found, and provides a registry of XCM locations and currencies (+ the registry can be modified dynamically).

Thanks to the provided registry, the library user can use descriptive names for locations (accounts, chains, asset IDs, etc.) instead of relying on XCM Locations directly.

Moreover, the library supports both pallet-xcm and pallet-xtokens.

Hovewer, there is an extra issue regrding Asset Trapping: we want to have a clear way to rescue NFT assets if they are trapped regardless of fee estimation. Our accepted XCM RFC "Custom Asset Claimer" solves this.

Conclusion

I believe you can use the tools we are developing and build something on top of it. Our abstract Substrate solution takes into account that a collection can be viewed as an asset, for example. So, you can implement your vision of transferring whole collections across chains.

I would like to propose that we collaborate to maintain and improve the upcoming "Simple XCM" library. Our goal is for this library to be maintained by the community, rather than just by us. It would be fantastic if we could work on this together as members of the NFT Collective.

Another thing we can work on together is developing and refining educational materials around the XCM NFT stack.

The Treasury covers these activities as part of our grant.

Footnotes

1. When I started my research, I thought I would do the same. I described something similar to your solution (and some other variants) on the Polkadot Forum but eventually realized this path wasn't correct. ↩

[dudo50]

@mrshiposha , thanks for finding time to respond to this Grant proposal PR. We appreciate it as it adds to the discussion.

We agree with you about the following:

We believe it is important because NFTs have much greater potential than just artwork. For example, they can be various capability tokens, on-chain shared variables, in-game characters and objects, etc.
Because of this potential, it is natural to expect many different NFT engines with unique capabilities to exist on various chains.

Our vision towards the future is to enhance and support such unique use cases - as that is where the power of NFTs shines and unlocks the ability to introduce unique niche projects to the ecosystem.

We believe, that this isn't correctly understood from your side:

Your proposal doesn't fit into the existing XCM framework. I see you're using Transact to perform the transfers. Essentially, you're modelling the teleports as follows: you destroy an entity on the sender chain and create another on the receiver chain. So, you are attempting to make a custom mechanism without utilizing the transfer model provided by the XCM1.

The solution you were looking at is our PoC solution - Demo. Think of it as the PoC your team delivered to the Karura. This solution will look completely different after refactoring and feature implementation. While it isn't meant to be directly implemented into SDK like the solution you propose it brings another perspective (Like the one you proposed in your PoC, but better in abstraction of complex details. Eg. PolkadotXCM (SDK) vs xTokens (3rd party implementation)). While we agree with you, that it isn't fully universal, it off-lifts maintenance requirements on SDK proposed by your Substrate solution. This allows our/other teams to release/implement updates/bug fixes faster without having to rely on a third party (Some updates in SDK can take a while to be merged as the amount of code is insane and maintenance needed to keep everything up requires lots of effort from multiple people within Parity team (For which we think they are heroes in many ways).

We are in the final stages of developing our "Simple XCM" TypeScript library. It supports every XCM version transparently to users, estimates total fees on all communicating chains (thanks to the XcmPaymentApi by Unique Network and the XCM DryRunApi by Parity), reports descriptive errors if found, and provides a registry of XCM locations and currencies (+ the registry can be modified dynamically).

Thanks to the provided registry, the library user can use descriptive names for locations (accounts, chains, asset IDs, etc.) instead of relying on XCM Locations directly.

Moreover, the library supports both pallet-xcm and pallet-xtokens.

This isn't new. We already offer everything you mentioned at ParaSpell for quite a while now in both XCM SDK & XCM API.

I believe you can use the tools we are developing and build something on top of it. Our abstract Substrate solution takes into account that a collection can be viewed as an asset, for example. So, you can implement your vision of transferring whole collections across chains.

Could you explain what the benefits of having collections viewed as an asset are?

I would like to propose that we collaborate to maintain and improve the upcoming "Simple XCM" library. Our goal is for this library to be maintained by the community, rather than just by us. It would be fantastic if we could work on this together as members of the NFT Collective.

We would suggest you to check what ParaSpell XCM libraries currently offer. We believe we offer the best UX abstraction from XCM for developers on the market. Perhaps forces could rather be joined to perfect already existing fully open-source XCM Tools at ParaSpell and further increase XCM adoption in the ecosystem.

Let us know what you think.
Once again thanks for taking your time responding to this proposal. This is much appreciated!

[mrshiposha]

@dudo50 Thanks for the clarification.

This isn't new. We already offer everything you mentioned at ParaSpell for quite a while now in both XCM SDK & XCM API.

We aim to create something simple to maintain and use with solid fee estimation mechanisms (using the new Runtime APIs). The XCM SDK you mentioned looks similar in idea, but it is more comprehensive than the simple library we want to create.
However, we could collaborate on fee estimation. Maybe we can split our library into several packages so you can re-use the fee estimation based on Runtime APIs without introducing the dependency on our whole library—just a tiny package. (I see you have fee estimation, but it seems it is scenario-based, not xcm-dry-running-based. Please correct me if I'm wrong.)

Could you explain what the benefits of having collections viewed as an asset are?

Looking at your PoC, I noticed that you've added support for cross-chain transfers of collections (collection_xtransfer).
It's possible to use the existing XCM interface (pallet-xcm / xtokens) to support this use case if a collection is viewed as an asset. This way, it is possible to teleport the collection like other assets (assuming data communication is implemented).
In short, the benefit is the client interface consistency.

[dudo50]

@dudo50 Thanks for the clarification.

@mrshiposha No worries!

However, we could collaborate on fee estimation. Maybe we can split our library into several packages so you can re-use the fee estimation based on Runtime APIs without introducing the dependency on our whole library—just a tiny package. (I see you have fee estimation, but it seems it is scenario-based, not xcm-dry-running-based. Please correct me if I'm wrong.)

That would be brilliant and we are more than open to it! We have been looking to improve the fee mechanism for a while now. Having more precise fee calculation would be a great benefit for all three of our XCM tools (XCM SDK, XCM API & mainly XCM Router). Here is my telegram handle - Dudo50 feel free to contact me and we can establish a ParaSpell<>Unique telegram group where we can cooperate on this matter.

Looking at your PoC, I noticed that you've added support for cross-chain transfers of collections (collection_xtransfer).
It's possible to use the existing XCM interface (pallet-xcm / xtokens) to support this use case if a collection is viewed as an asset. This way, it is possible to teleport the collection like other assets (assuming data communication is implemented).
In short, the benefit is the client interface consistency.

Thanks for clear explanation. We agree, that this could be beneficial for the user. However as the functionality is not yet present(merged) we will try to implement it our way first to see, if we can come up with another solution that makes sense and is user friendly (Because we have something in mind for this). However, in the future, once your solution is merged, we are more than happy to replace the mechanism if it will outperform what we designed.

Looking forward to hearing from you on telegram in regards to the fee estimation package.
Take care!

[dudo50]

cc @takahser ,

Any news regarding the status of the review?
Many thanks for your response.

With kind regards,
Dudo

[takahser]

@dudo50 thx for pinging and sorry for the delay. I'm planning to give you feedback by tomorrow EOD.

[takahser]

@dudo50 thanks for the updates and the patience. Also big thx to @mrshiposha for your contribution and the offer to collab regarding a optimized fee estimation library. Happy to add my approval here as well.

@keeganquigley could you confirm if kyc/b has been successfully completed before we merge this?

[keeganquigley]

Hi @dudo50 what name did you submit for KYB under? I'm not finding anything under ParaSpell Research Foundation?

[dudo50]

Hey @keeganquigley ,

Under business name mentioned in the proposal: Michael Absolon

[github-actions]

Congratulations and welcome to the Web3 Foundation Grants Program! Please refer to our Milestone Delivery repository for instructions on how to submit milestones and invoices, our FAQ for frequently asked questions and the support section of our README for more ways to find answers to your questions.

Before you start, take a moment to read through our announcement guidelines for all communications related to the grant or make them known to the right person in your organisation. In particular, please don't announce the grant publicly before at least the first milestone of your project has been approved. At that point or shortly before, you can get in touch with us at grantsPR@web3.foundation and we'll be happy to collaborate on an announcement about the work you’re doing.

Also, if you haven't yet, consider signing up for the Polkadot Alpha Program. The program offers plenty of resources for people building on Polkadot. Lastly, please remember to let us know in case you run into any delays or deviate from the deliverables in your application. You can either leave a comment here or directly request to amend your application via PR. We wish you luck with your project! 🚀