feat: add asset conversion pallet

[Moliholy]

Closes #281

[Moliholy]

@stiiifff in order to migrate to 1.3.0 pallet-dex is causing problems, since we'd also have to migrate that pallet. We could save us some time in this regard once this pallet is out of scope when merging this PR.

[stiiifff]

@stiiifff in order to migrate to 1.3.0 pallet-dex is causing problems, since we'd also have to migrate that pallet. We could save us some time in this regard once this pallet is out of scope when merging this PR.

Given my comments above, I think we might need to upgrade the DEX pallet to v1.3.0 to proceed with the v1.3.0 upgrade so that we can take more time to think about all the impacts of the integration of the Asset Conversion pallet, and bring all the necessary changes in a proper way. Let's not rush it.

[Moliholy]

@stiiifff in order to migrate to 1.3.0 pallet-dex is causing problems, since we'd also have to migrate that pallet. We could save us some time in this regard once this pallet is out of scope when merging this PR.

Given my comments above, I think we might need to upgrade the DEX pallet to v1.3.0 to proceed with the v1.3.0 upgrade so that we can take more time to think about all the impacts of the integration of the Asset Conversion pallet, and bring all the necessary changes in a proper way. Let's not rush it.

I already upgraded the dex pallet to 1.3.0. Still, it was causing compilation problems that were very hard to debug.

[metricaez]

hi! I'd like to jump in the discussion with some thoughts.

TL:DR I would implement asset conversion without adding the second pallet-assets instance for foreign assets and delete pallet-dex.

I fully understand the reason behind moving into a more standard way of managing assets MultiLocation like foreign assets approach that store this type as part of the AssetId, however I do consider that asset registry does a good job doing so in pretty straightforward way.

I think that implementing a second instance of pallet-assets (and its associated difficulties like Traders) like foreign's makes sense if further logic will be applied to these type of assets, for example in the case of AH only Sibling parachains can create them, different fee's and so. The main reason I see behind foreign assets is to become a reserve but this is just a personal opinion.

Since I think that is not Trappist purpose, I would promote a protectionist approach to assets and implement asset conversion only to local assets, and for outsiders tokens applications keep on limiting ourselves to accept tokens from other chains only as reserve asset transfers with a local derivative created and registered through asset registry that requires sudo, therefore we would be managing only tokens that were willingly approved by sudo/governance.

Overall I think is best to push as much asset related functionality to AH to lower the chances of scams (with scam versions of the same asset) and the creation of multiple exchange rates (one on Trappist, one on AH) that eventually would be arbitraged but that is not always a good experiences for users.

To wrap up, I see the use case for asset management for Trappist to be as follow:

• Asset conversion is implemented for converting local assets in/out HOP. For example, we create different games that rewards users with different tokens for each game, to cash them out they should convert them to HOP. That is a case in where asset conversion makes sense.
• HOP as our gate to the world via AH, both teleports into the reserve and reserve transfer to sibling chains. This is good for local exchange fees and AH (or any other parachain with exchange functionalities ) wouldn't need to worry to manage and register all the assets inside Trappist ecosystem.
• If you want to do business with use, use AH and HOP. This minimize Trader and asset rates issues.
• However, on certain particular cases that we want to manage foreign currencies, we do so by creating their derivative in our pallet-asset and registering them on asset-registry, we would only accept reserve transfer of these assets.

Wdyt ?

[stiiifff]

@metricaez Great feedback, very insightful. I agree with the approach, and this also has the benefit of showcasing the integration of the FRAME asset conversion pallet (i.e. a DEX based on the Uniswap v2 protocol) in a different way than on the Asset Hub (which is heavily focused on the use case of foreign assets for which the AH is acting as a reserve, as you rightly mentioned). So, we keep the asset registry, with its simple sudo / governance -based approach of allow-listing (local) derivative assets, instead of an additional instance of the Assets pallet for managing foreign assets. And the asset conversion pallet is to be configured to allow the creation of liquidity pool for swaps between local assets on Trappist (whether arbitrary fungible assets, or derivative assets). /cc @Moliholy

[Moliholy]

@stiiifff @metricaez I just pushed 4346a71 that removes the foreign asset instance and only allows pallet-asset-conversion to trade locally.

[Moliholy]

Updated to latest main branch.