[Assets] Implement fungibles::freeze::Mutate

[pandres95]

Is there an existing issue?

• I have searched the existing issues

Experiencing problems? Have you tried our Stack Exchange first?

• This is not a support question.

Motivation

Locks are currently implemented on Balances due to the needs for existing use cases (e.g. pallet-staking, pallet-conviction-voting, etc.).

However, over time, similar or novel use cases have been arising where locks are needed to be implemented on Assets

One example of that is Multi-governance on pallet-communities, where communities have an OpenGov-like system enabled, for which AssetBalance is a voting option. In this case, the balance of the asset used to vote from a user needs to be locked to prevent an account from voting using such balance, and then sending it over to another member, thus altering the poll results.

Request

Implement fungibles::MutateFreeze for pallet-assets.

Solution

Due to the current design of pallet-assets, there are two options (so, I open this issue to discuss the best course of action):

1. Create a pallet extension (conveniently called pallet-assets-freezer) that implements both FrozenBalance (the trait described in T::Freezer within pallet-assets) and fungibles::freeze::Mutate.
2. Replace T::Freezer with a proper implementation of fungibles::freeze::Mutate within pallet-assets.

Are you willing to help with this request?

Yes! (Of, course, assign it to me).

Tasks

Beta Give feedback

1. Define whether to implement as a pallet extension or within the pallet.
2. Propose pallet-assets-freezer extension.

[pandres95]

According to @gavofyork's response on OpenDev Call, the best course of action is not to implement MutateFreeze directly in pallet-assets in order to maintain the minimal necessary logic of it.

In consequence, it's best proceeding with the first option:

• Create a pallet extension (conveniently called pallet-assets-freezer) that implements both FrozenBalance (the trait described in T::Freezer within pallet-assets) and fungibles::freeze::Mutate.

Since there's a potential for a pallet extension, are there any public calls that might work on it?

[JelliedOwl]

Thank you for raising this - I suspect it's something I would want to use. Sadly, I suspect my other issue with assets needs a separate solution. #3451

Edit to clarify - I think I need to be able to lock part for an asset balance as well as freezing all of an asset on an account (locked or otherwise).

[JelliedOwl]

Is what you're proposing more akin to locking (part of a balance) rather than freezing (all of an asset)? In which case, should it be called pallet-assets-locker instead?

Or I might be misinterpreting the intent of your issue. My use case would probably require multiple (overlapping and/or mutually exclusive) lock categories - like we have now for balances. Perhaps that's not what you're aiming to address?

[pandres95]

It is, makes sense to call it an assets-locker as this is the concept that's historically been used to refer to freezes (consider calling them Freezes instead of Locks is fairly recent).

[JelliedOwl]

Thanks Pablo

I suspect I'll end up with an extension pallet to do the Multi-asset Locking, which will interact with yours - but yours is probably more likely to be widely used so the interfacing and testing / maintaining should probably by my pallet's responsibility. I suspect Parity isn't going to jump at taking on maintaining it for me.

There might be too much cross-interaction for my pallet to be just an extension anyway, so I might end up having to fork pallet-assets, which I'd really like to avoid.

For example, I need account-frozen assets which are frozen by my multi-asset freezer not to be able to call the unlock function on those assets. (That possibly applies to assets frozen from the regular pallet_assets too, so you might need to handle that bit, at least). Hopefully that makes sense...

[liamaharon]

Any update on this @pandres95? It's needed for #3149, happy to provide any help you may need getting it moving.

[liamaharon]

Also want to mention this PR paritytech/substrate#8476 here. The solution for this issue should probably follow it closely.