When we first added XCM to our runtimes (first Altair and later Centrifuge), the first token we supported was Acala’s AUSD and for that we just added AUSD as a hardcoded variant of our CurrencyId enum type; That type enumerates all the currency ids that the Centrifuge chain knows about or is able to handle.
Later, improving our XCM setup, we introduced the ORML asset registry for two purposes:
so that we could support new tokens through XCM by simply registering them in the asset registry instead of hardcoding them in the CurrencyId type and thus not require runtime upgrades to support new tokens;
so that we had a standardised way of querying metadata for all tokens that Centrifuge handles, i.e, both native tokens like CFG and Tranche tokens, as well as “foreign” tokens like AUSD, USDC, etc.
This motion is now a step into cleaning up that first legacy, “hardcoding”-based approach; we do that by dropping those hardcoded currency variants (AUSD and KSM (the latter only applicable on Altair)) and have them registered as Currency::ForeignAsset(<asset_id>) in the asset registry instead; The next step will be to migrate all balances that are now under CurrencyId::AUSD and CurrencyId::KSM to CurrencyId::ForeignAsset(<aUSD_asset_id>) and CurrencyId::ForeignAsset(<ksm_asset_id>) , respectively.
Set CurrencyId::AUSD ’s location to X2(OnlyChild, GeneralIndex(200081) This is an “invalid” multilocation. This structure was chosen because it’s quite symbolic, i.e, “relative to Altair, it’s a child (asset) left alone and with the index 200081 which is the original parachain id (2000) + the original asset general key (0x0081). Again, this means nothing really, but it’s a value that will serve the purpose of flagging this asset as abandoned and will allow us to register the new entry for AUSD with the correct multilocation.
Register CurrencyId::ForeignAsset(2) (new AUSD id)