Look into adding `pallet-assets` about canvas HOT 10 CLOSED

That's a good point about recycling asset IDs. I'm not sure the best solution. I wonder if we could set up Statemine to have a handler on destroying an asset class that would check if other chains have reserve accounts, and send a message to them.

This raises a larger question of cleaning up state across multiple chains when some storage item is reaped.

from canvas.

We've decided to go with both.

However, in order to close this issue we should only integrate (1). There are some things to think about though:

• Should we allow our local pallet-assets to support minting?
• What cross-chain mechanism should we support (Teleport, Reserve Assets)

cc @apopiak

from canvas.

On minting:
You will have to have two separate instances of pallet-assets if you allow minting in your local version and want to allow the movement of assets from Statemine (so that they don't collide).

An issue we will need to address for cross-chain interactions:
How to sync metadata (e.g. token symbol and decimals)?

from canvas.

So my idea of pallet_asset integration which I will try to pursue is the following:

The single source of truth for asset classes is statemine. While Canvas will have a pallet_asset it will have minting and creating new asset classes disabled. So in order to to create a new asset class or mint new tokens you will need to go to statemine (or send an xcm message there). To use a specific asset class on Canvas it needs to be send from statemine. If the class does not exist on Canvas it is created on demand by the transfer message.

This should be enough to prevent collisions. It will only fall apart when asset ids are allowed to be recycled on pallet_asset. Did not check that, yet. @joepetrowski

from canvas.

So I just checked the code of pallet_asset and recycling ids is totally possible and likely because the id is chosen by the user rather than incremented.

I wonder if we could set up Statemine to have a handler on destroying an asset class that would check if other chains have reserve accounts, and send a message to them.

This could work. Any sane change would then trust this message if it comes from statemine and always execute this message and never fail it (because of weight for example). Otherwise it could go out of sync.

from canvas.

Yeah, I'm somewhat worried about it going out of sync.
I'm also unsure how we would create the asset class on-demand on Canvas as that requires details we don't necessarily have.

from canvas.

So it wouldn't be created by a transfer but rather a subscription that Canvas has on Statemine to get notified about creation and removal of asset classes. Maybe we don't even need a synchronisation because MultiAsset allows specifying the asset id without collision? Just thinking out loud here. Didn't have time to look into it, yet.

from canvas.

So we'd have some on_create_asset and on_remove_asset handlers that send an XCM::Transact to Kanvas?

from canvas.

I think so. We would have filters in place on Kanvas that only allow asset class creation and removal from the Statemine multi location.

from canvas.

We decided that for the Canvas launch this is a too big of an issue to tackle. We will concentrate on providing XCM support in order to allow interoperability between chains. This means we are launching without a pallet_asset and are OK with people creating ERC20 contracts for the time being. We are curious how the XCM support will be used for asset interoprability.

from canvas.