Liquidation Protection Mechanism

This proposal will outline a mechanism to protect loans from liquidations via an auto-deleveraging mechanic on loans.

As the Solana price dropped over 50% in 10 days, liquidations became, for the first time, a reality to a large number of Hubble users. Since launch, 314 liquidations have occurred on the platform, 244 of which occurred in May. From 2 to 12 May, a total of $1.7M worth of debt was liquidated.

For a deeper look at liquidation statistics over this period, read the Hubble Stress Test article by @DudeBro

It has been repeatedly suggested/discussed that a liquidation protection mechanism would be a valuable addition to the platform, though the form of this remained undecided.

Partial Liquidations

We propose that the liquidation protection should be in the form of an auto-unwind mechanic on user loans. When a loan reaches the maximum LTV (which will soon be increased from 75% to 80%), a portion of a user’s collateral is sold on the market, converted to USDH, and used to unwind the loan. You could also call this a partial liquidation.

The user pays a “fee”, in the form of their collateral, while their LTV is decreased via a portion of USDH debt being repaid.

At present, we propose that 20% of collateral be sold to unwind if it incurs less than 1% slippage

Example:

The SOL price drops from $110 to $100. A user had a debt of 80 USDH, with $110 of SOL deposited. The LTV of the increases from 72.7% to 80%, and the loan can be liquidated.

Via the liquidation protection mechanism, $20 (20%) of SOL is sold, swapped to USDH, and repaid.

After the unwind, the loan stats would be:

Collateral: $80 SOL

Debt: 60 USDH

LTV 75%

Pros:

  • Partial liquidations happen natively on loans, and there is no requirement other than having a loan and opting into partial liquidations.

  • Gives you a time buffer to readjust your loan before next liquidation happens

  • No limit on how many partial liquidations can occur, provided there is enough collateral to fund it

Cons:

  • Partial liquidations remain liquidations, so with each liquidations you lose a portion of your collateral

  • Have to sell a large % of collateral to make a big buffer between next liquidation

Stability Pool Protection

It has also been suggested that liquidation protection could happen via the stability pool, whereby a user’s staked USDH can be unstaked and used to repay a portion of debt on the at-risk loan.

Via this mechanic, a user’s Stability Pool (USDH Vault) balance will decrease according to a specified amount, and their USDH debt will be repaid in the exact same amount.

Pro:

  • You do not lose your collateral assets when stability pool protection activates

Cons:

  • Only users with USDH deposited in Stability Pool can have access to this feature

  • Stability Pool can get drained if collateral price keeps dropping; so you can end up without your USDH deposit, and without your collateral.

Feedback

The parameters and exact implementation of either system is not set in stone, and we welcome any suggestions as to how we could implement liquidation protection in the most effective way possible. The goal is to build a mechanic that provides the best UX, and feedback is of great importance to enable us doing so.

5 Likes

Great, but I would suggest first approach of partial liquidation because in any bear market, cutting losses is 1st thing to do. Using user stability pool USDH can result in the whole of user assets being liquidated.
Or if it can be possible that both is implemented and each user get to choose themselves which one they want.

I am strongly in favour of the stability pool protection option.

For me to hold 20% of my USDH loan in the stability as a repayment buffer is a much better proposition than having the same amount my collateral sold for a couple of reasons.

  1. If my collateral which I intend to HODL for the long term is sold as it’s value is falling it kind of defeats the purpose of why I deposited it into Hubble in the first place which was to have extra liquidity without having to sell the asset.

  2. Because of the inherent volatility of the assets held as collateral there is an associated uncertainty of how much of the collateral asset would have to be sold to repay the 1 USDH equivalent in debt. Whereas if the repayment occurs in USDH via a stability pool position I can know for certain that X amount of USDH will be repaid in the event of a liquidation.

  3. Liquidation rewards and HBB emission (currently I know these are set to fall or stop all together) and eventually possible stability fees which I it has been mentioned will get paid to stability pool stakers.

From my point of view the stability option pays me (liquidation rewards,HBB, possible stability fees) to protect myself and provide protection for the protocol in general whilst keeping hold of the assets I value the most. Whereas partial liquidations give me nothing other than the potential to loose some of collateral at a lower price than when I deposited it into the protocol. This will be different for traders who want to have a stop loss in place, but as a long term investor I would rather keep hold of the collateral.

As to the cons that @DudeBro mentioned with the stability pool option I think that these can be overcome.

As for the first con of only users that have funds in the stability pool having access to the feature, this in itself could end up being of benefit to the entire protocol as it encourages people to contribute to providing insolvency protection to Hubble. Although some users would maybe find this a bit inconvenient or a pain I feel the vast majority would be happy to have this in place for their own protection and that of other Hubble users. This then also raises the question of how to properly incentivise the stability pool so ensure sufficient liquidation cover (if user self interest proves inadequate).

As to the second point of the stability pool position being drained either by other liquidations or a users own loan lowering their deposits to liquidation points. I think this could be solved with the use of a 3rd party message service such as Notifi or Dialect. The theory here is that the user receives a notification that part of their loan has been repaid prompting them to repay the loan further of add more collateral. In effect this makes the stability pool protection a time buffer until full liquidation occurs which is what most users need.

2 Likes

Both options sound viable but my perception is option 2 (SP protection) would be the first line of defense before option 1 kicks in.

Option 1 feels like an opt-in redemption mechanism. Option 2 feels like a savings account.

Option 2 also rewards users for keeping their funds in the SP, creating a sort of closed loop that improves the health of the whole protocol. I could see it going even further where maybe users could specify “lock my LTV around N%”, and the system auto borrows or repays around that percentage. Again, sort of like a savings account.

1 Like

I think this is a great first line defense mechanism. As we saw in the discord and Twitter, while people deposit into the stability pool they don’t necessarily want to swap large amount of their USDH for others bad loans. This creates preventative measures that benefits the borrower from full liquidation, and simultaneously protects the stability pool from being drained. Which I’m sure many thought the stability pool not being enough was a possibility with that massive SRM deposit.

1 Like

Piggy backing somewhat off of what has already been said, I don’t think these two options are mutually exclusive. Using stability pool funds first and then moving on to partial liquidations would be my ideal way to approach the issue.

An alternative consideration, albeit one that would require some more dev time, would be to create a separate USDH Vault to draw from in the event of a market downturn. Investors could deposit USDH into the vault; the Hubble team would direct this USDH around the Solana defi ecosystem to provide liquidity as they saw fit and, in return, Hubble would draw on these funds to provide liquidation protection. The investor would get a return that roughly approximated the average return of all the USDH defi options and a little bit of peace of mind.

1 Like

These are not either/or scenarios, and both should be implemented. Option 1 is how liquidations should work in the first place; 100% liquidations are somewhat antiquated in DeFi. Partial liquidations are expected at this point. I think we should move on this one quickly.

Option 2 is the only of the 2 options that I would actually call “liquidation protection,” and I think this would be a great feature to encourage borrowing on Hubble. I don’t really see any downside to it. One argument against it may be that it will result in fewer liquidations and therefore lower liquidation rewards, therefore disincentivizing participation in the Stability Pool. But if more people are borrowing higher LTV and depositing USDH in the pool for their own loan’s protection, will that not offset and potentially result in even higher Stability Pool participation? Difficult to predict/model, but I’m leaning towards “yes.”

2 Likes

I agree that these are both positive ideas and not mutually exclusive. There are obviously dev issues involved in how it’s implemented but allowing the protocol users a choice in risk mitigation is a very attractive idea. In other words, is there a way to allow the borrower to choose? Maybe add a small borrow fee to access these options. I would personally consider allocating more funds to leverage with either of these options.

第一种选项,保护了项目的资金池,为用户保留了法币资产,避免了集中清算的大额清算费,对于大幅度的暴跌行情可以有效保护用户,相当于20%止损线;但遇到插针行情会遭受损失。
第二种选项,可以避免因突发插针行情而失去用户的抵押资产,但如果遇到大幅暴跌行情,用户法币本位将遭受较大损失。
两种方式各有利弊,建议应该给用户充分的选择权,提供多种选项让用户根据其意愿自由选择,按照重要性排序为:
1-第一个选项,部分清算;
2-第一个选项,用户自定义部分清算的阈值,比如用户设定当LTV到50%、60%、70%而非80%时,即开始清算,避免遇到极端行情,平台抵押资产集中清算导致市场缺乏流动性。
3-第二个选项。

The first option protects the fund pool of the project, preserves legal currency assets for users, and avoids large liquidation fees for centralized liquidation. It can effectively protect users in the case of a large plunge in the market, which is equivalent to a 20% stop loss line; To the pin market will suffer losses.

The second option can avoid losing the user’s mortgage assets due to the sudden pin-in market, but if there is a sharp drop in the market, the user’s legal currency standard will suffer a greater loss.

Both methods have their own advantages and disadvantages. It is suggested that users should be given sufficient choice, and a variety of options should be provided for users to choose freely according to their wishes. The order of importance is as follows:

1 - the first option, partial liquidation;

2- The first option, the user defines the threshold for partial liquidation. For example, the user sets the liquidation to start when the LTV reaches 50%, 60%, 70% instead of 80%, so as to avoid extreme market conditions and the concentration of platform mortgage assets Liquidations lead to illiquid markets.

3- The second option.

1 Like

It is necessary to give the user the opportunity to decide whether to use his funds from the stable pool for collateral. Or create a separate pool. To protect the pool from emptying, it may be worth bringing a percentage of trades to the open market.

1 Like

We are agreed on this point. All liquidations will likely become partial, which will be further supplemented with the notification system by Notifi (cc @Vosper )

The stability pool option is also viable, though this will require a fair bit more dev work than the partial liquidations.