Description
The system already provides a way to amalgamate the same tokens from different chains - e.g., USDC from Ethereum and USDC from Base can be instantly swapped into localUSDC. Issuers can use localUsdc as their pool currency, opening the pool for both variants. We want to extend this behavior. Creating more localXXX versions, allows issuers to accept a more diverse set of tokens - e.g. a localUsdcDai token would allow the use of both Dai and all USDC variants for a pool.
This means that localUsdcDai tokens could be swapped into both Dai and Usdc tokens, while localUsdc tokens could only be swapped into Usdc tokens.
Research/based on
- Needs of issuers to not swap
USDC <> DAI or other tokens
How will this affect the code base
- Increase complexity on the
pallet-token-mux side due to decimal differences
What are foreseen obstacles or hurdles to overcome?
- Prevent creation of dust due to rounding
Description
The system already provides a way to amalgamate the same tokens from different chains - e.g.,
USDCfrom Ethereum andUSDCfrom Base can be instantly swapped intolocalUSDC. Issuers can uselocalUsdcas their pool currency, opening the pool for both variants. We want to extend this behavior. Creating morelocalXXXversions, allows issuers to accept a more diverse set of tokens - e.g. alocalUsdcDaitoken would allow the use of bothDaiand allUSDCvariants for a pool.This means that
localUsdcDaitokens could be swapped into bothDaiandUsdctokens, whilelocalUsdctokens could only be swapped intoUsdctokens.Research/based on
USDC<>DAIor other tokensHow will this affect the code base
pallet-token-muxside due to decimal differencesWhat are foreseen obstacles or hurdles to overcome?