Minimal AssetHub integration

[stiiifff]

Provide an out-of-the-box configuration of the chain’s runtime to integrate with the AssetHub common-good parachain.

This entails:

• Implement a Fungible adapter for foreign assets (on the AH) in the XCM configuration.
• Implement logic to map a foreign asset to a local (derivative) one.
• Allow reserve-based transfer operations for foreign assets.

Note: this logic could be put in a distinct asset_hub.rs file to cleanly separate it from the rest of the runtime logic.

[evilrobot-01]

Just a thought, but would wrapping this in a feature be worthwhile, so template users can easily opt out of such functionality if they wish?

I get that the template is opionated and that they can manually remove it, but just imagining how this template might be in the future with a somewhat complex default implementation and no easy way for builders to know how to safely remove things they may not want.

[Daanvdplas]

I would like to get my hands dirty with xcm!

[metricaez]

Hey! Quick question,
"Implement logic to map a foreign asset to a local (derivative) one."
Pallet asset-registry does this super nice but it's not FRAME's so should we just use it's approach?

[Daanvdplas]

Hi! I have to say I agree with @metricaez. Pallet asset-registry is nice and as minimal as you can get. Another solution would be to hardcode an implementation with asset-hub's multi-location but this can be different in local dev setups. Personally I prefer the pallet-asset-registry implementation, can I get a thumbs up if I can go for this approach?

While on the subject, I'd say pallet-asset-registry is a very good candidate for FRAME!

[evilrobot-01]

Saw this as well, dunno how suitable though: https://github.com/open-web3-stack/open-runtime-module-library/tree/master/asset-registry

[Daanvdplas]

Yes that would work as well! Feature wise it is a bit more extensive.

[evilrobot-01]

I suspect that the Trappist one was a fork at some point in the fast and has not evolved as much as the ORML one but that's just a wild guess.

[Daanvdplas]

When searching for orml's asset-registry I find some parachains: https://github.com/search?q=orml_asset_registry&type=code

Is this a reason to go with orml so forks of the template (parachain teams) will use the same pallet as other teams in the ecosystem?

[Daanvdplas]

On the other hand, we might have to update the pallet due to new releases (if necessary). Maybe better if we can focus on FRAME and in-house pallets.

Nevertheless, people from the ecosystem seem to actively do these upgrades as well. And perhaps there is also something to say about the fact that it is good if we help maintain orml together with the ecosystem.

[Daanvdplas]

I found another solution which is to create 2 instances of pallet-assets. The problem I found with orml-asset-registry is that it is not up to date and honestly the code was not convincing me either.

Asset-Hub uses the same approach. Moreover, we'll leverage the thorough tested pallet-assets. This is reason for me to try it out!