In the multi-currency margin mode, when have borrowing currency or the unrealized loss of the positions causes liabilities in the account equity of the currency, the borrowing currency or liability of the currency may trigger forced repayment, and the system will automatically buy back the liability currency and reduce the liability value.
1. When an auto token conversion is executed, the system will sell the positive asset in USDT( USDT has robust liquidity with a relatively less slippage loss), then use this USDT to buy back the liability currency.
2. How does the system decide the order of the sold currency?
(1) The system will sell the currency whose conversion rate is at tier 1 first (the lower the conversion rate, the less its impact on the general equity of the account), which means the currency has a lower conversion rate. Currencies with 0 conversion rates are not included in the ordered list.
(2) If two candidate currencies’ conversion rates are both at tier 1, the one with better liquidity will be chosen(currencies with good liquidity performance usually cause minor slippage loss).
Assume that a user’s liability is in BTC and the positive assets in his account are ETH, DOT, BSV, and CVC, whose tier 1 conversion rates are respectively 1, 0.9, 0.9, and 0.
1. Since currencies with 0 conversion rates are not included in the ordered list, CVC is out.
2. Among the tokens with non-zero conversion rates, the rate of DOT and BSV is lower. If DOT has a better liquidity performance, the system will sell DOT to buy back BTC when auto token conversion is triggered.
When the liability of the currency exceeds the interest-free limit, the system will trigger forced repayment and restore it within the interest-free limit. The system's forced repayment will sell the positive assets into USDT first, and then USDT will be used to pay off the liability.
Example: There are 1BTC and 10000ETH in the user account, and the BTC interest-free limit is set as 1BTC
1. The user opens 10 BTC long positions of BTCUSD perpetual swap with 10X leverage, 1 BTC is required for initial margin;
2. The price of BTC drops dramatically and the loss of this position reaches 2BTC. Because there are enough ETH assets, the user's account is still safe at this time;
3. The user's 1BTC deposit has been lost, and 1BTC liabilities will be passively generated. The interest-free limit of BTC is 1BTC, so no interest will be generated with this 1BTC liability.
4. When the price continues to fall and the user's loss of BTC exceeds 2 BTC, that is, when the liability exceeds 1 BTC, the system will trigger forced repayment;
5. The system will sell the ETH of equivalent value of 0.5 BTC (half of the interest-free limit) to USDT, then the purchased USDT will be used to buy the liability currency BTC, and the BTC liability will be restored within the interest-free limit.
In the auto-borrow mode, when have borrowing currency or the liabilities caused by the unrealized loss of positions exceed the interest-free limit, interest will automatically begin to accrue; under normal circumstances, the system will not trigger forced repayment;
But when the platform’s total liability reaches the liability limit, the system will trigger forced repayment; at this time, the positions of derivatives will be divided into tiers（different interest-free ranges for different tiers） according to the borrowing currency or the liability value caused by the unrealized loss, positions with the largest liability will be forced to repay the liability first;
After executing the system repayment, the corresponding repayment fees and bills will be generated.
Examples: Assume that the interest-free range for BTC is 1 BTC, and the platform risk-control limit is 100 BTC. There are 5 users having liabilities in Auto Borrow mode:
2. User B has a liability of 9.5 BTC and a negative unrealized PnL of 9.5 BTC, which means the liability totally results from the negative unrealized PnL of contract positions. Hence, the liability generated from the unrealized PnL of contract positions is 9.5 BTC. As mentioned, the interest-free range is 1 BTC, so the user’s liability is at tier 10.
3. User C’s account balance is 1 BTC and has a liability of 10.5 BTC and a negative unrealized PnL of 11.5 BTC. The liability results from the negative unrealized PnL of contract positions is 10.5 BTC. As mentioned, the interest-free range is 1 BTC, so the user’s liability is at tier 11.
4. User D’s account balance is -1 BTC and has a liability of 11.8 BTC and a negative unrealized PnL of 10.8 BTC. The liability results from the negative unrealized PnL of contract positions is 10.8 BTC. As mentioned, the interest-free range is 1 BTC, so the user’s liability is at tier 11.
5. User E’s account balance is 10 BTC and has a liability of 0 BTC and a negative unrealized PnL of 5 BTC, then the user’s account equity is 5 BTC. As user E has no liability generated from negative unrealized PnL of contract positions, the auto token conversion will not be triggered.
6. If the platform’s total liability reaches 100 BTC, it will trigger the platform’s liability risk-control measures. Since E have no liability generated from unrealized PnL of contract positions, the auto token conversion will not happen. The user C and D’s liabilities are both at the highest tier 11, so the system will execute an auto token conversion to reduce the tier to tier 10. That is, user C buys back around 0.5 BTC, and user D buys back about 0.8 BTC via auto token conversion.
7. If user C and D’s liabilities still exceed the risk-control limit after being reduced by 1 tier, the system will sort the remaining users: if the liability of user A, B, C, D are all at tier 10 (the highest tier), then all of their liability tiers will be reduced to tier 9. That means, user A, B, C, D buy back roughly 1 BTC via auto token conversion.