Open sander2 opened 3 years ago
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
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.
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 ofvault.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.