Liquidated collateral with multi-collateral

[sander2]

Problem
Before multicollateral, we had a single collateral and a single wrapped token. In liquidation_redeem we could simply reward the user with a fraction of the collateral stored in the liquidation vault, based on the amount of tokens that are being burned. With multicollateral, however, it becomes unclear how much collateral to award the user for the burning the tokens.

Similarly, we need to change how we deal with liquidated vaults in e.g. redeem_tokens. We used to release an amount of vault.data.liquidated_collateral * tokens / to_be_redeemed_tokens, but with the introduction of multiple collaterals this is wrong.

Solution
(effectively) use multiple liquidation vaults, one for each currency. This means that each collateral has their own issued_tokens bookkeeping.

Considered alternative

Reward based on the current exchange rate. Say that the liquidation vault contains 50 DOT, 100 KSM, and has 1000 issued tokens. If the current exchange rate DOT:KSM is 2:1, then the 50 DOT is worth 25% of the KSM. In other words, the ratio of the value of the DOT compared to the KSM is 1:4, so users can burn 200 interBTC for 50 DOT, or 800 interbtc for 100 KSM. This requires iteration and it's not clear that there is a big advantage.

[nud3l]

Agree with the solution to effectively use multiple liquidation vaults where users specify which liquidation vault they want to use for a burn operation. Note that users can batch transactions on the JS level together to burn against multiple liquidation vaults atomically if they want to.

Thought process

1. In the current setup, the effective exchange rate that determines how much collateral is being given to a user calling liquidation redeem ("burn") is determined by the ratio of issued_tokens/liquidated_collateral. That ensures that on liquidation, users should have an immediate arbitrage opportunity as the value of liquidated collateral should always be greater than the liquidated interBTC as determined by the liquidation threshold.
2. Each collateral currency will have its individual liquidation threshold. The goal (and that should be added to the multi-collateral specification) is that collateral currencies are risk-equivalent. This means that based on the volatility and liquidity of a currency, we must find a liquidation threshold such that any currency is equivalent. For example, a more risky asset like KSM should have a higher liquidation threshold than DOT as a less risky asset. In the future, we need to develop a methodology to determine the exact thresholds similar to this: https://medium.com/gauntlet-networks/karura-parameter-recommendation-methodology-6ce7fe06cb77 and this https://arxiv.org/abs/2002.08099
3. Using the current exchange rate must not be allowed as that might run into the risk of early depletion of the liquidation vault. For example, if no immediate burn happens but the price of the collateral asset in relation to Bitocin keeps crashing, users would deplete the liquidation vault such that there were 0 collateral tokens left while there still might be issued_tokens in the liquidation vault.
4. Given that asset should be risk-equivalent, theoretically, it should not make a difference to users which asset to burn against. However, if there is a "confidence crisis" in a collateral asset, i.e., the expected value of the asset is assumed to go to 0 (e.g., due to a major bug in the implementation of the asset like a stablecoin losing it's peg), users will not burn with that asset. However, this problem is independent from the multi-collateral asset issue but rather related to the selection of suitable collateral assets in the first place.
5. Users will choose the most favorable assets to burn interBTC for. Likely, automatic arbitrage bots can be written and we as Interlay can even run our own. If the price crashes of the collateral asset are below secure_liquidation_threshold - 1 - slippage - tx_fees , these arbitrage bots should make a profit. As a next step, we should take that into consideration and model the thresholds based on that.