Tokens Horizon

[gavofyork]

FTs:

• fungible::* traits (#8435).
• Implement fungibles::Unbalanced for Assets pallet (#8435).
• Implement fungible::* for Balances pallet (#8454).
• Deprecate Currency; introduce holds and freezing into fungible traits substrate#12951
• FRAME: Conformance tests for fungible API #225
• FRAME: Make Currency trait an optional feature.
• FRAME: Introduce a default-off Config trait item in System allowing accounts to remain with no provider refs. (Requires [FRAME Core] Default Pallet Config Trait / derive_impl substrate#13454)
• FRAME: Move pallets over to use fungible traits #226
• Assets: Implement Inactive balance tracking in Assets pallet #228
• Introduce AssetsFreezer and AssetsHolder pallets and implement fungibles::hold::* and fungibles::freeze::* (FRAME: Assets Freezer pallet substrate#8476)
• Introduce Provider pallet, which allows valuable assets to be locked in exchange for a provider reference.
• XCM for can_withdraw, can_deposit, balance, reserved_balance.
• Introduce LockableAssets derivative pallet and implement fungibles::freeze::*.

NFTs:

• Uniques pallet (Uniques: An economically-secure basic-featured NFT pallet substrate#8813).
• nonfungible::* traits (Non-fungible token traits substrate#8993).
• Implement nonfungibles::* for Uniques (Non-fungible token traits substrate#8993).
• XCM adaptors for nonfungible::* implementers.
• FRAME: Introduce shelve/restore to nonfungible/nonfungibles #224
• Implement nonfungible::* trait for existing ownership systems that allow some transferable permission (membership of TC/Council, asset class ownership, ...).
• Create new type of pure Proxy with single transferable owner and implement nonfungible::* for it.

Associated paritytech/substrate#8285

[olanod]

Perhaps something for the TODO list and more of a question to hear some ideas, would it make sense to make the Assets pallet instantiable? My motivation is, first that it doesn't harm and second that it makes working with unrelated groups of assets a bit more convenient and conceptually more correct, if I have a pallet depending on some fungibles::* that have something in common and are a subset of the potentially bigger set that the one Assets instance will store I often need some extra config in my pallet to be able to filter out assets from that bigger set. With different instances of Assets I relax more and trust the pallet will be configured with right subset of assets and just rely on the type system to do the "filtering" at compile time instead. I imagine I could also query the asset to see if it comes with some label or something in its T::Extra data but also seems like extra work.

[gavofyork]

I would accept a PR that did it, but the other items on the list are somewhat more pressing.

[olanod]

PR is there in case you feel like giving it a quick look in a coffee/bubble tea break 😉 paritytech/substrate#8483

[chrisdcosta]

Can this new token stuff be optional for chains that don't want or need multi-currency support? It seems to be baked in - unless I'm missing something?

[gavofyork]

All multi-currency stuff will continue to be completely optional.

[danforbes]

I'm curious about the thoughts/plans that exist around non-fungible token standards and would like to offer my contributions if they can be of help. I am the author of a pallet that defines and implements a UniqueAssets trait and have also worked with the ORML NFT pallet. I would like to start by creating some specifications around the key/value pairs that may exist as attributes on an NFT. What are the expectations that exist around the presence of certain attributes, the values they may take, and how those values impact the presence of other attributes and their possible values? I think it would be productive to follow an approach that is similar to/inspired by the OpenAPI (nee Swagger) specification.

[pmensik]

I am actually really interested in this initiative as well since we are about to start the development of a generic auction pallet for different NFT implementations (we have already delivered PoC on top of the orml-nft). So I wonder which NFT implementation is gaining the most traction at the moment and what can we do to help the standardization process within Polkadot/Kusama ecosystem. We have created our own tracking issue inside the project so definitely appreciate any of your thoughts!

[Swader]

I would also like to participate in the NFT specification in some way, given that RMRK (which has picked up considerable steam) is, functionality-wise, far more advanced that typical NFTs are (we have nested NFTs, on-chain emotes as price discovery and signal, reactive NFTs with conditional rendering, equip mechanics, and NFTs being governed as DAOs). If we can help somehow or contribute to the discussions around speccing all this out, we'd love to.

[iorveth]

I spotted a couple of potential issues/areas of improvement for nonfungible(s) traits and uniques pallet.
Let me know if you are interested in further contributions, please
paritytech/substrate#9208,
paritytech/substrate#9207,
paritytech/substrate#9211,
paritytech/substrate#9206

[kinosang]

do we really need a AssetsFreezer pallet? could we just implement fungibles::Hold in assets pallet?

[flipchan]

It would be really nice to get a freeze function that can freeze X amount of a certain asset's. Similar to how it's doable with "T::Currency::freeze(AccountId, Balance)?".
I am currently manually implementing this in the LLM pallet(the freeze X amount of a certain asset, where the use case is that asset's work similar to tokens) at https://github.com/liberland/liberland_substrate . It would be great to have this built into the asset pallet, as this can then be expanded and it will allow implementations such as: Voting using pallet-democracy and the chain holding the on-chain asset's to vote with the onchain asset's instead of what's currently just a T::Currencyfreeze with pallet democracy.

[Polkadot-Forum]

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/statemint-update-roadmap/1200/1