Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Locks Logic To Lock Listed NFTs #75

Closed
HashWarlock opened this issue Mar 1, 2022 · 4 comments
Closed

Add Locks Logic To Lock Listed NFTs #75

HashWarlock opened this issue Mar 1, 2022 · 4 comments

Comments

@HashWarlock
Copy link
Contributor

Currently there is a limitation that doesn't allow for NFTs to be locked after they have been listed in the Market. Originally there was the idea to implement in the RMRK core pallet, but this leads to problems upstream in the Uniques pallet where Uniques will not have any knowledge of the locks mechanism defined in the RMRK core pallet. A current proposal would be to utilize a dependency injection trait defined in the Uniques pallet that would allow the RMRK core pallet to be able to enforce the locks logic by implementing the new trait.

A psuedo-code example can be found here by @h4x3rotab https://gist.github.com/h4x3rotab/152d05c9b5a18462e8dfe2b299b58db8

The plan would be to introduce the Uniques pallet code back into the RMRK repo temporarily until the code is ready to be submitted for review to be added to the Substrate Uniques pallet repository.

@bmacer
Copy link
Contributor

bmacer commented Mar 2, 2022

i fear this same issue will come up in other ways. i think about equipping, and i implemented an "equipped" property on the NFT at the core level, to prevent equipping an item into both hands (for example).

pub equipped: bool,
. it didn't occur to me that the uniques pallet might cause conflict, though i see that now. i've wondered what need we have for the uniques pallet at all, but i think i'm missing some big-picture stuff.

i tried implementing some of the pseudo-code, but ran into a lot of grief...where the T's go, and where to use ClassId vs CollectionId. Do you know of an example of a pallet implementing this kind of dependency injection?

@HashWarlock
Copy link
Contributor Author

I agree there seems to be some troubles being tightly coupled to uniques pallet. This was a big reason for the Lazy Ownership implementation to avoid having to track ownership in rmrk pallet, but this does make me wonder about the future if the uniques changes in the upstream to enable a capability that could cause unforeseen problems for rmrk pallet.

I have an example from the polkadot repo for parachains to lease an auction slot. Here is that implementation. @h4x3rotab let me know if I missed any other code to reference the example.

Define the Trait to be impl in traits.rs:
https://github.com/paritytech/polkadot/blob/2a3fca3c880bc42966c7133b3b5a0f08f7e93cb7/runtime/common/src/traits.rs#L102-L156

Define Trait in Pallet Config called Leaser
https://github.com/paritytech/polkadot/blob/468a75ed56852afd7d5c161407b3b70d342da64d/runtime/common/src/auctions.rs#L97-L101

Impl the Leaser Trait for Polkadot & I believe parachains impl this when leasing a slot for an auction
https://github.com/paritytech/polkadot/blob/d96d3bea85a650f48e9011aaec7d2ab9c9e7b2c0/runtime/common/src/slots.rs#L333-L493

@bmacer
Copy link
Contributor

bmacer commented May 3, 2022

Being addressed in #76

@ilionic
Copy link
Contributor

ilionic commented May 19, 2022

#76 merged.

@ilionic ilionic closed this as completed May 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants