[RFC] Partial Liquidations

Protocol Development
9

Thanks to the community for the deep and productive discussion on the topic of partial liquidation. And thanks to the Platonia team for the deep feedback on the solution and comparative modeling.

We incorporated all the feedback into the final variant of the solution, with several framing thoughts serving as its foundation. We aim to build this post as a framing piece for the solution discussion, incorporating:

  • The review of Platonia’s feedback
  • Extended final thoughts on the motivation of this innovation and raised questions
  • High-level description of the final technical scope.

Platonia feedback

Thanks to the Platonia team for the extended thoughts on a problem, insightful comparison of the partial liquidation model, and valuable thinking process around the solution. We are here to find the innovation best suitable for the Compound ecosystem, and so - every contribution matters and impacts the final solution. We carefully studied the whole feedback and incorporated it into our view of the solution.

Terminology

Terminology standardization is quite a substandard process that clashes with the conventions of each protocol and different researchers. The goal of the initial post was to establish entities and the main parameters of the liquidation process, while keeping the connection with the established code notation.

For example, that’s why the initial post sets definitions of health factor in terms of LTV and in terms of factors used by Compound - as it keeps a clear view on CF (colalteral factor) and LF (liquidation collateral factor) as parameters <100%, so it just makes sense having HF in the same terms. Thus, both work in LTV space (debt-to-value ratio, HF < 1) or in value coverage (value-to-debt, HF > 1) are equivalent, but just in different notations. We are glad to see that both approaches in math align together in a target HF formula calculation, which we work in LTV and delta value terms, compared to the value-to-debt and close factor terms presented in the post.

Though it’s great to see the notion accepted in the community, united in a single post, so we will take the adopted approach for this notation as well.

Virtual swap

A brief note in the “Motivation Feedback” section - we completely agree on the fact that liquidations lead to net reserve growth; there is no doubt about that. The goal was to highlight the fact that liquidations have several connected factors, which contaminate the growth, thus pouring into unrealized profit. A good example is “virtual swap” performed during the base asset purchase: a massive amount of collateral can be purchased from Comet with no slippage (this the “virtual swap”) for the user, thus giving the user additional bonus besides the discount, as the same collateral amount will be later dropped into the exchange with the price decreasing effect. It is especially noticeable on massive liquidations and purchases via flashloan with an immediate drop into the market. While the proposal has no goal of solving this problem (and further risks of cascade liquidations), the partial liquidation partially (no pun intended) solves this problem by limiting the amount of collateral seized immediately and sold in the “virtual swap”.

Motivation

We completely agree with this statement. Although it refers to the partially out-of-context segment of the initial post, where we described the benefits of partial liquidations for each ecosystem participant, including liquidators (as the least risk-bearing users). So, indeed, it is a win-win-win situation:

  • Users pay less in terms of lost positions;
  • Protocol receives more in terms of profit from the interest on positions with longer lifetimes;
  • Liquidators pay less literally.

So, this thought was already included as a subcontext of the discussion, though thanks to Platonia for bringing it explicitly.

Breaking changes

That is the feedback we orient to! Indeed, we aim to deliver a positive impact, and (as we later see in the math and comparison section of the Platonia feedback), partial liquidation is a positive impact. Though we also have a goal of careful code and process changes, as breaking changes should not break the protocol, and should be secured. However, after a deep analysis of the Platonia feedback, previous feedback, and the liquidation process in general, we indeed agree that some breaking changes are required. As we later discuss in the framing thoughts section, partial liquidation will be implemented as a default behavior, and so full liquidation will become a natural extension of the math behind it. And so, breaking changes will be delivered, but without actually breaking anything in logic and flow.

Additionally, after a careful review of the solution feedback, we agree with the Platonia team that if partial liquidation becomes a default behavior, we will not require a new PLF parameter, thereby maintaining LF usage as intended. So, by default, it avoids changes in the absorb() and buyCollateral() functions. Although we discuss it further in the framing thoughts section, along with the stale liquidity issue and the close factor discussion.

Liquidators incentivization

The additional liquidators’ incentivization (e.g., via the bonding curve with the liquidation penalty or discount, or via the lp points) was an open question we left for the community discussion. Great to see valuable thoughts on this matter:

  • We agree that liquidation points were implemented for another purpose and so are less suitable for an incentivization accumulation;
  • We also agree that liquidators are here to maximize profit, thus they are incentivized by default, and so with the choice of partial liquidation as a default approach, no to other means are necessary

Analysis section

Thanks to the Platonia team for the great analysis and comparison with other models, as it explicitly shows our internal thinking process and several modeling tasks included in the development scope. Great to see the math, which aligns with our understanding of the process and our analysis as well. Thanks for the valuable visualizations showing why indeed the protocol requires partial liquidations to be implemented in the first place.

Also, this section gave us a couple more thoughts on the modeling and retro-analysis tasks to be added into the scope of the solution development. We will be happy to share the results once the development starts ,with the Platonia team invited into the discussion and feedback sessions on the intermediate results.

Summary

  • No need to raise collateralization - same parameters, same meaning
  • No need to raise the audit surface - even with breaking changes no changes in the interface or process required
  • No need in additional incentives or tricky solutions to have partial liquidation working by default - if we have them working by default.
  • Full liquidation is still a necessity - but as an extension of the general liquidation logic, when no other option is available (when target HF is unreachable in terms of the chosen solution).

All these points are included in the final solution.

Framing thoughts based on the received feedback

In general, the solution discussion was built around several possibilities of the implementation:

  • Target health factor as the characteristic of the user’s account to aim
  • Close factor as a characteristic of a certain collateral, fixed % of the value to be liquidated
  • Intermediate factor (characteristic of the asset) as a measure to start the partial liquidation process
  • An arbitrary % of the debt to be closed and covered
  • In general relation between processes of debt closing (absorb) and liquidated debt repayment (collateral purchase process)
  • Relation with the full liquidation - keeping 2 separate processes, or partially uniting them into one

As a result of the discussion, the conclusions are:

  • In general, the goal is to minimize the introduced complexities, thus minimizing the number of new parameters introduced for the system.
  • During the discussion, we compared several views on partial liquidation - including the view of it as a process independent from the full liquidation process (thus assuming them as alternatives) and the view on a single liquidation process but with a changed underlying model. The discussion, further modeling, and solution development showed that the existence of both full and partial liquidation processes makes no sense from the economic and game theory perspective; thus, one model should be a natural extension of the other model. Also, the discussion showed that the community and the protocol are already even for breaking changes (though we still aim to keep the existing flow undisrupted)
  • Therefore, we lean towards enhancing the existing absorb model, so that the partial liquidation becomes the default behavior with full liquidation following naturally from the underlying math as an edge-case of a single liquidation process.
  • Initially, we reviewed the possibility of adding the PLF (partial liquidation factor) as an intermediate parameter signaling the start of the partial liquidation process. Though, based on the discussion and the next decision to make the partial liquidation default behavior, the new parameter is no longer necessary and is fully covered by the existing LF.
  • Between the close factor model and the target health model, we lean towards the target health model (described in the initial post).

Relation between partial and full liquidation

The first main question we raised before the implementation of the partial liquidation was how to incentivize liquidators to use it prior to the full liquidation model. While our initial thoughts were based on different incentivization mechanisms, after a thoughtful community discussion, the question was resolved by adopting partial liquidation as the default mechanism. And such an approach solves both problems:

  • Problem of over-liquidation: partial liquidation ensures that the protocol closes the only part of the user’s position required to support the health status of the position;
  • Problem of incentivization: since partial liquidation is a default behavior, there is no need to create an artificial “competition” point and search for an artificial equilibrium point. Full liquidation will be a natural extension of the partial liquidation logic: if no position part will be enough to return it to the health state, the full liquidation will be performed.
  • Additionally, the problem of “dust” accounts will be solved as well, as the check against the minimal debt position will be enforced, thus the liquidation cannot end with an unhealthy position or with a dust position, full liquidation will be enforced otherwise

Additionally, no changes to the absorb() / buyCollateral() interface are required now.

Close factor vs Target health

Another question was connected to the implementation model: target HF vs close factor. While both approaches are valid and adopted (on the examples of Euler with the target HF and Aave with the close factor), Compound needs only one of them.

  • Limit from below: If you have a close factor, it will always be used for the liquidations, as it enforces a minimal boundary. However, it will still keep a problem of over-liquidation, as such a limit can still be high enough for positions that have just entered an unhealthy stage. So, it becomes natural to have a calculated lower boundary for each account based on the state the protocol wants it to achieve - thus, we naturally come to the target HF;
  • Healthy state as a target: while the close factor can be calculated as a recommended % of the position to close, it still can leave it in the unhealthy state. And again, we naturally come to the target HF as a required account characteristic during the liquidation, as you need to close a precise amount to avoid over-liquidation and to leave the position in a healthy state.
  • Artificial competitions: there was another approach discussed within the community - flexible close factor or custom % for each liquidation. However, it is a precise situation of a forced artificial competition, where the only dominant strategy is to liquidate the full position. Since the community agrees that there is no need to bind liquidation to the discount or penalty size, it creates no incentives to follow the partial liquidation flow, and so it will make the solution unusable. So, again, we naturally come to the target HF as a characteristic of the debt position in the moment of liquidation. Since it is calculated individually for each position, it will create no additional competition for liquidators, thus it will work in the same way for each user, and as a default behavior, will always be executed.

So, the main thought received after the discussion: the solution should not create artificial competitions with a single dominated strategy (as it will remove any sense from a solution implementation), limits (if any implemented) should make sense to avoid leaning towards one of the sides (as a result of a dominant strategy), and the solution should avoid having alternative/competing routes.

Therefore, we naturally concluded that the target HF model would be the most suitable for the Compound.

Breaking changes

While the community and the protocol are ready for breaking changes, we aim to keep a minimal amount of such changes in a single protocol upgrade. Thus, the partial liquidation with the target HF model will become a default behavior of the protocol (with full liquidation as an edge-case of this model), but with no breaking changes in the absorb() / buyCollateral() flow.

Collaterals order

As the discussion has shown, the collateral ordering matters. Initially, we reviewed the idea of having liquidators choose the collateral to seize, but it was an open question. So, after the feedback session and review of the connected risks, we see no need in such functionality. However, such a risk still exists even now (on a high level), thus we included additional modeling into the scope to see if the markets with partial liquidations will need to have a change in the order of collaterals. As even now the liquidation goes through collaterals one by one, in an order set during the market deployment. So, additional modeling will show which markets may have a form of collateral imbalance risk after the partial liquidation implementation.

Solution implementation key points

The section includes references to the required changes in the codebase and to the additional tasks that must be executed during development.

1. Target HF
The solution introduces a new market parameter - target HF. The Platonia feedback advises a reasonable constant, though it cannot be assumed to be the same for each market. And since the Compound Comet parameters upgrade flow includes immutable variables changed during the implementation upgrade, we see that target HF fits this process.

Sense of the parameter is the same as it was described in the initial post: it is a HF of the account to be after the liquidation process. Thus either the position will be partially liquidated (once liquidation criteria is met) to be forcely moved to the target HF, or it will be fully liquidated.

2. LF
No additional intermediate parameters introduced. LF (liquidation factor) will play the same role with no change, and partial liquidation (with full liquidation as its edge-case) will not change the sense of the parameter

3. absorb() interface
No changes to the absorb() interface required

4. buyCollateral() process
No changes in the buyCollatera() method (and process) required.

5. absorb() implementation changes

  • The function will calculate the required collateral to be seized to close the part of the debt required for the position to correspond to the target HF (based on the calculation approach from the initial post (formulas (13), (14), (10));
  • The function will enforce the check that after the liquidation, the position will correspond to the target HF or liquidated fully, otherwise;
  • The function will enforce a check against the minimal debt left after the liquidation (baseBorrowMin) or enforce full liquidation otherwise;

6. Additional viewers, internal functions, and optimizations

  • List of additional changes (based on the initial post): minimalDebt() and collateralForMinimalDebt() viewers to fetch the numeric info on the partial liquidation process. Note: isLiquidatable() remains as the main function to signalize on the unhealthy positions with no changes in the logic.
  • Interal optimizations for isLiquidatable() + absorb() functions ot avoid extra calls and to introduce the prices caching during the transaction

7. Modeling
Based on the received feedback, the scope was extended with several modeling and analysis tasks.

  • Behavior modeling: modeling based on several behavioral user models to explore the state of the market with partial liquidations implemented. That includes exploring the behavior of users with different risk profiles, thus with a different approaches to keeping the account healthy (in different % from the liquidation threshold), with different position sizes, and with variable prices on collaterals. That will allow us to explore how the implementation will change the risk profile of users based on the market in which the innovation is implemented, the change in the liquidators’ behavior (if any), the impact of “virtual swap” and unaccounted slippage, and other raised risks;
  • Collateral order investigation: the task was formulated based in the discussion of the collateral imbalance based on the order of collaterals seized. As a natural extension of a previous analysis, it will allow research of possible approaches to the collateral order change, the necessity of it, and the choice of markets where such risk may be met
  • Market behavior modeling: a study of markets to develop an upgrade order, in which markets should be updated with innovation. It will help to mark the most suitable (strong, stable markets) and the ones that require additional analysis
  • Change impact analysis: the simulation of post-upgrade market behavior. That will include the optimistic assumptions on liquidators’ behaviors (and their optimal strategies) and price volatilities. The result will be used to define the order of markets to be upgraded.
  • In general, such an analysis will enable the visualization of the impact on reserves of the protocol and the increase in its profitability, and to decide on which markets require a custom target health factor or a change in the order of collaterals (decided in synchronization with security and risk management providers in the ecosystem)

8. Retroanalysis
Another sphere of potential insights - retro-analysis of existing markets with the application of the partial liquidation model to analyze the risk profile of users and the protocol behavior retrospectively.

  • Collection of market events for the 1-1.5 year (supplies, borrows, liquidations, reserves growths, reserves withdrawals, etc) to explore the cumulative effect of liquidations on reserves and capital on markets;
  • That will allow us to analyze the modern risk profile of users and on how close to liquidation users prefer to have their positions;
  • However, this data is primarily required to analyze the dynamics of collateral purchases (via flashloans, via bulkers or in another bundlers, or in separate txs) and following swaps on DEXes (to see the price impact);
  • Thus, it will show the dynamics of what amounts can be considered lost for users (from over-liquidations), how reserves are balanced between base assets and collaterals;
  • It will allow the application of the historical price changes of assets to have historical data on the protocol’s reserves value volatility and the protocol’s profit;
  • The collected data will be used to apply the newly developed partial liquidation solution to analyze the unrealized profit by the protocol and the lost positions by users.
  • And that is the goal of the analysis - to get the retrospective picture with the applied solution compared with the modeling results from the previous section to see the impact of the solution and its potential for the ecosystem. Plus, the collected data will be shared with other teams working on the ecosystem growth for the analysis of other innovations.

9. Deployment preparation
The ecosystem update plan based on the analysis: list of markets in order of the recommended upgrade, markets with highlighted risks, and additional propositions on the order of collaterals or target health factor parameter (if needed)

4 Likes