Cross-Chain Router
The Cross-Chain Router: Enables any assets to be transferred between multiple chains, no matter if they are native or created with Multichain's Bridge.
The Multichain allows assets to be transferred between two or more blockchains. There are three categories of Routing transfer that we can consider: -
(a) Native Assets
When a token already exists on a chain, we refer to it as a native asset. An example is USDC. In this instance, Multichain cannot mint the asset, so instead we use liquidity pools. A number of tokens are added by Multichain, a project team, or individuals to the pool on each chain. These tokens are then available for a user when they move cross chains. Ideally there are enough on each chain so that no matter how many tokens are transferred, there are enough in the pool for them. When a user moves say N XYZ tokens from chain A to chain B, those N tokens are available for another user who is transferring XYX from chain B (or chains C, D, E etc.) to chain A. They enter the liquidity pool on chain A. The total number of XYZ in the liquidity pools on all chains remains the same (unless extra XYZ are specifically added or removed by someone to the pools).
This would work well except that it is necessary to cope with the case where a user sends XYZ to a chain, but there is not enough XYZ in the pool for them to withdraw. This is why there are anyXYZ tokens created. These CAN be minted by Multichain on each chain and they represent the number of XYZ that the user SHOULD receive on that chain. If there are enough XYZ on the chain, then the anyXYZ are automatically swapped for those XYZ and the anyXYZ are burned. If there are not enough XYZ on the chain, then the user is left with their anyXYZ (called 'Your Pool Share') and they have to manually 'Remove' them, converting anyXYZ to XYZ when sufficient XYZ become available again. Remember - the number of XYZ in the pool on a chain increases when someone Routes XYZ away from that chain to another chain, or when someone specifically adds XYZ to the pool on that chain.
The sequence that is followed when a user transfers XYZ from chain A to chain B is: -
(i) The XYZ is added to the pool on chain A.
(ii) The same number of anyXYZ are minted on chain A.
(iii) The SMPC node network detects this and causes anyXYZ to be minted on chain B, burning those on chain A.
(iv) If the number of XYZ on chain B is greater than the anyXYZ created, then the XYZ are sent to the user's wallet on chain B and the anyXYZ are burned on chain B. If the number of XYZ is less than anyXYZ, then the user is left with their anyXYZ and this represents their pool share to be redeemed later by them for XYZ when there are enough again (by 'Removing' them).
(b) Bridged Assets
When the Router uses assets which are created using AnyswapV5ERC20.sol, or a modified version of it, (Bridged assets), there is no need for a liquidity pool for the asset, since Multichain controls the supply of the asset on the chain where the contract resides. In this case the pool size is 'Unlimited'. For a Routed asset whose cross-chain minting is entirely controlled by AnyswapV5ERC20, all that is required, is that a supply of that asset is added to the pool on the chain where the token was originally minted. A good example of this is MIM, which is created on Ethereum as a collateralized asset and which has a series of bridges to other chains (using AnyswapV5ERC20). These bridges are incorporated into the Router.
The use of exclusively Bridged assets in the Router leads to the best user experience, since they do not need to be concerned about the liquidity supply on the target chain.
(c) Hybrid Native/Bridged Assets
Sometimes it is necessary to combine native assets on some chains with assets controlled by Multichain's Bridges (AnyswapV5ERC20.sol). This often happens when a project minted a supply of that token, or already had a third-party bridge for an asset on another chain, but after joining the Router, wished to add tokens on extra chains. In this instance, the pre-existing tokens are 'native', but the tokens on new chains are 'Bridged'. It is the responsibility of the project team to ensure that there is sufficient liquidity in the pool for assets which are native on a chain, but the liquidity on chains for which Bridges exist is 'Unlimited'. Here is an example of a Router hybrid asset.
For FTM, The Router uses native FTM on Ethereum, Binance Smart Chain and Fantom Opera, but is Bridged to Cronos, Telos, Boba, Celo and Harmony.
Notes:
In order to promote the efficiency of liquidity and reduce users' cross-chain cost, for some tokens, liquidity is shared between Router and Bridge on some famous and reliable chains by a share liquidity tool powered by SMPC network.
However, it does not run very often and generally only provides a small part of initial liquidity. Whose security has been carefully evaluated and verified, all possible risks can be afforded, security measures including but not limited to Chain TVL Limited, Security Fund, Suspension, Watch Dog, ...
Last updated
