XCM asset registry

Hello teams, in my search to establish an XCM asset registry, I wanted to ask you for suggestions.

We’re looking to separate the asset details from the front end code of the XCM bridge.

I also want to highlight the fact that Acala has built something similar and it also drives their own XCM bridge icon resources. Take a look here: GitHub - AcalaNetwork/token-resources: resources include token and network

Here is a sample of metadata I would like to store for each token that Astar supports for our XCM bridge:

{
  symbol: 'ACA',
  name: 'Acala',
  isNativeToken: true,
  assetId: '18446744073709551616',
  originAssetId: 'ACA',
  logo: 'https://assets.coingecko.com/coins/images/20634/small/upOKBONH_400x400.jpg?1647420536',
  isXcmCompatible: true,
  originChain: Chain.ACALA,
  minBridgeAmount: '0.4',
},
  • Should we extend what they’ve done?
  • Look at other implementations?

I’m interested to know what @xlc thinks about this. :wink:

I’ve forked Acala/token-resources to GitHub - open-web3-stack/token-resources: resources include token and network

I would also like to make this a collectively maintained repo to reduce duplicated work across the ecosystem.

3 Likes

Suggesting more (meta)information to add to assets in this registry:

  • asset location in XCM format; I see there is originChain: Chain.ACALA now, but at the very least this should be enhanced with some GlobalConsensus identifier, so bridged assets can be correctly represented
  • trusted reserve locations - local ecosystem reserve chains; right now, for most assets it will be just the originChain, but hopefully in the near future, most assets will also have reserve on local AssetHub. Bridged assets also need a local reserve, either AssetHub or the parachain that bridged them in.
  • teleport locations - local chains that support teleporting asset between them; this list will be identical to the “trusted reserve locations” list above, so we might skip it, but we could also explicitly add it.

Having this would be very useful to the ecosystem, and significantly reduce complexity in figuring out how to transfer these assets between chains. Right now, information on asset reserve locations or teleport locations is very hard to come by.

We can then create tooling for automated building of asset transfer XCMs, based on the information in this registry.

2 Likes

I also found xcm-global-registry/assets/polkadot at action · colorfulnotion/xcm-global-registry · GitHub which does something similar, IIUC.

I believe the asset-transfer-ap-registry is providing a good base, although it’s still missing the trusted reserve and teleport locations.

We can start by fleshing out a JSON schema that includes that useful metadata and how to retrieve them. There will be also other data needed (e.g. what assets are accepted for fees on each chain).

Not sure if the maintenance can be fully automated, but don’t think it is critical.

What do you think?

1 Like

I think maintenance can be automated by inspecting IsTeleporter filter (runtime configuration item) of asset origin chain. All teleport locations can also act as reserves.

But as you say, automated maintenance is not critical - we get 99% of the benefit by just having this information centralized/accessible somewhere to start with.

how do you automatically inspect IsTeleporter filter?

With Make Trusted Teleporters Available in Runtime Metadata or Storage · Issue #97 · paritytech/polkadot-sdk · GitHub

1 Like