Asset registry pallet

[0x8f701]

what I saw from many parachain teams is that every parachain team build/is building an asset registry pallet for foreign assets, this is not good for polkadot because we are re-inventing the wheel multiple times, altough there maybe gaps to build an asset registry for all but still want to throw my thoughts here

[xlc]

The one used by Acala includes a lot of Acala specific features so not suitable as a generic reusable pallet. However it should be possible to extract some of the features into a new pallet to put here.

However I would like to gather more inputs from various teams first.

[samelamin]

@GopherJ thank you so much for raising this. Coincidently I asked this very same question on the builder's call yesterday

Totally agree!

More and more chains will want to implement each other's assets and we need a best practice defined to avoid rework

I suggest we define a clear goal for a pallet that can be imported to your runtime and give you an easy way to import assets from other chains

In addition, we need a guide to ensure future teams implement it in the same way

Essentially something like https://github.com/substrate-developer-hub/substrate-node-template/ but for importing assets. I see a guide has already started which includes a pallet example of an exchange

That helps but as a new chain, my first question would be "how do I allow users on my chain to use $aUSD/$IMBU/$BNC"

Ideally, I would want a clear guide on how to do that

The teams using ORML can each contribute to it meaning anyone implementing it can easily import all the assets of chains using this pallet

In an ideal world you can just import the pallet, add/comment out a few lines of code and you now have that asset usable on your chain

I am more than happy contributing to this guide too

[sander2]

We are looking to add an asset registry to Kintsugi in the near future as well, so we're certainly interested in this. I had a quick look at Acala's pallet and it seems like a simplified version of that would be a good starting point indeed

[0x8f701]

Refs:

• https://github.com/PureStake/moonbeam/tree/master/pallets/asset-manager
• https://github.com/AcalaNetwork/Acala/tree/master/modules/asset-registry
• https://github.com/parallel-finance/parallel/tree/master/pallets/asset-manager

[enthusiastmartin]

Hi,

We in HydraDX / Basilisk also use our own asset-registry pallet.

https://github.com/galacticcouncil/warehouse/tree/main/asset-registry

Our Asset registry pallet requirements would be as follows. This is basically what our asset-registy does.

• adding new assets dynamically
• auto assign ids to new newly added asset - we use sequential ids ( this might be challenging to do as general approach as other projects might need to explicitly specify asset id )
• different type of assets
• existential deposit / min balance.
• location of an asset - used for foreign assets where it is required to specify MultiLocation and it is used to resolve location to asset in xcm.
• custom metadata

[sander2]

Hi,

We in HydraDX / Basilisk also use our own asset-registry pallet.

https://github.com/galacticcouncil/warehouse/tree/main/asset-registry

Our Asset registry pallet requirements would be as follows. This is basically what our asset-registy does.

* adding new assets dynamically

* auto assign ids to new newly added asset - we use sequential ids ( this might be challenging to do as general approach as other projects might need to explicitly specify asset id )

* different type of assets

* existential deposit / min balance.

* location of an asset - used for foreign assets where it is required to specify MultiLocation and it is used to resolve location to asset in xcm.

* custom metadata

I guess the tricky bit will be to determine what part to make customizable, and what part to provide by default. One valid approach is to go the extreme, and make all data customizable, i.e. to have some associated type AssetMetadata, and have the pallet only be responsible for providing getters/setters for this AssetMetadata, and for associating AssetMetadata with some ID.

Another approach is to provide some data by the default, and have only the non-standard part be customizable. So to have this by default:

• existential deposit
• multilocation
• number of digits
• name
• symbol

And have a CustomMetadata associated type, where chains could put e.g.

• fee per second (some chains might not use a static value for this)
• type of asset (some chains may only have one type of foreign asset)

[samelamin]

Hi,
We in HydraDX / Basilisk also use our own asset-registry pallet.
https://github.com/galacticcouncil/warehouse/tree/main/asset-registry
Our Asset registry pallet requirements would be as follows. This is basically what our asset-registy does.

* adding new assets dynamically

* auto assign ids to new newly added asset - we use sequential ids ( this might be challenging to do as general approach as other projects might need to explicitly specify asset id )

* different type of assets

* existential deposit / min balance.

* location of an asset - used for foreign assets where it is required to specify MultiLocation and it is used to resolve location to asset in xcm.

* custom metadata

I guess the tricky bit will be to determine what part to make customizable, and what part to provide by default. One valid approach is to go the extreme, and make all data customizable, i.e. to have some associated type AssetMetadata, and have the pallet only be responsible for providing getters/setters for this AssetMetadata, and for associating AssetMetadata with some ID.

Another approach is to provide some data by the default, and have only the non-standard part be customizable. So to have this by default:

• existential deposit
• multilocation
• number of digits
• name
• symbol

And have a CustomMetadata associated type, where chains could put e.g.

• fee per second (some chains might not use a static value for this)
• type of asset (some chains may only have one type of foreign asset)

I think your second approach makes more sense to me to be honest. IMHO the whole point of the registry is to add consistency and guide people on where to start, you want a few things defined.

Teams that want a completely customisable experience can just do what virtually everyone is doing now, i.e. writing their own

But I think most teams would be happy to reuse the existing definitions.

Happy to be corrected here though, but the engineer in me thinks we keep it as simple as possible and adding default values achieves that

[sander2]

I made a PoC in #728 - please comment there with feedback

[shaunxw]

Implemented in #728