[RFC] Partial Liquidations

[victator]

First I want to thank the @woof team for their work scoping out partial liquidations and presenting this RFC. They have been patient, receptive to feedback and easy to work with and I believe this initiative they’ve put forth could be a nice step forward towards increasing Compound’s collateral factors. I also want to thank @torrey for providing helpful suggestions, context and clarifications and @jbass-oz and the OpenZeppelin team for their comments as well.

The remainder of this response will be structured as follows

1. Liquidation review and tradeoffs of partial liquidations
2. Feedback for the proposed design
3. Analysis of potential designs and their parameterizations

Before diving into this wanted to bring up a quick note on terminology

DeFi Lending Terminology

The RFC’s terminology clashes with established DeFi conventions. Consistent terminology prevents ambiguity and ensures everyone shares the same understanding

Two prominent examples

@woof

LF (liquidation factor) is a ratio between the user’s debt and the collateral value, factored by the collateral liquidation factor:

2. LF = \frac{ (\text{principal} + \text{interest}) \times \text{base asset price} }{ \sum_{i}^{n} \left( \text{collateral balance}_i \times \text{collateral price}_i \times \text{collateral liquidation factor}_i \right) }

The liquidation factor (LF) should refer to the collateral asset risk parameter that determines percentage of collateral value that can be borrowed (including interest) before an account becomes liquidatable. This is the term used on Compound’s website

and also used in prior analysis on liquidations by Gauntlet here and in all of their risk parameter recommendations.

I understand that it’s confusing since this is referred to as the liquidateCollateralFactor in the Comet code here but this becomes even more messy since there is another term called liquidationFactor a line below which actually corresponds to 1 - liquidation penalty (LP). With the definition proposed here, the term liquidation factor is now overloaded in 3 different ways with

1. Being the LF as is shown on the front end
2. Being 1 - LP as defined within asset info in Comet
3. Being the account level collateralization threshold for liquidation as defined in this RFC

Let’s use the front end as the source of truth since it probably has the most eyes and agreed upon definition. I would redefine (3) to a term like “account liquidation ratio” where if it exceeds 1 the account is eligible for liquidation.

@woof

HF (Health Factor) is a ratio between debt and collateral value, factored by the collateral factor:

The health factor has been defined for as long as I can remember as the ratio of the collateral value and the debt value, factored by the LF, not the CF.

A definition is given by Aave here and this is the same convention that Euler used for the original target health factor partial liquidation implementation here. The intuition here is that higher health factor means more account health so if an account’s health factor drops below 1 then it is eligible for liquidation. I would redefine the reciprocal here to a term like “borrow utilization ratio” so if it exceeds 1 then the account can be liquidated.

For the remainder of this post will use the following terms with their definitions linked

HF = health factor
CF = collateral factor
LF = liquidation factor
LP = liquidation penalty
SFPF = store front price factor
c = close factor
IB = insolvency buffer

Liquidation Review

When considering this new functionality for the protocol, would be good to review some context and tradeoffs.

Why liquidations matter

The primary function of liquidations is to protect the protocol against insolvencies. In particular, the insolvency buffer as defined by Gauntlet here is increasing with liquidation penalty. On their own, liquidations aren’t necessarily harmful to the protocol since they serve as a core mechanism for decentralized risk management. Another way to view them is as a systemic risk cost. Initially this cost is placed on the borrower but shifts to the protocol if the loan goes insolvent. In that sense, protocols having liquidations is similar to a liquidity provider hedging against risk.

An important point about the liquidation penalty is that it constrains the maximum collateral factor for an asset. If the protocol can reduce the cost of liquidations while maintaining the same level of risk reduction, it can safely raise collateral factors. This would improve Compound’s competitiveness and likely attract more users and capital. For a more detailed explanation, I previously posted about this topic here.

A reasonable critique of liquidations is that they can be inefficient. In many cases, the cost is too high relative to the actual risk, which results in worse UX for borrowers in both higher penalties and lower capital efficiency due to lower collateral factors. Partial liquidations are one potential improvement.

Tradeoffs of partial liquidations

Partial liquidations limit how much of an account can be liquidated in a single transaction.

There are several common implementations within DeFi such as

1. Applying a fixed percentage known as a close factor, used by protocols like Aave and Compound V2
2. Targeting a specific health factor after liquidation such as in Euler V1
3. Using a dynamic AMM for liquidation, such as LLAMMA in Curve’s crvUSD system, explained here

Whether partial liquidations are preferable to full liquidations can be dependent on price trajectory and market context. In the case of a scam wick partial liquidations clearly better in protecting borrower collateral. If full liquidations are like hedging all at once then partial liquidations are like hedging through TWAPing. The tradeoff becomes a question of how aggressively the protocol should de-risk. If the price drop is driven by fake news it’s better to avoid overpaying liquidators to fire sale assets. But if the bad news is real and collateral prices are falling block after block then the protocol needs hedge aggressively and in full to prevent worse outcomes from happening.

Partial liquidations tend to be better on average since most of the time the situation isn’t urgent enough to justify the cost of the full liquidation penalty, but full liquidations are safer in worst-case scenarios. The key is in how much risk is introduced by the delay from liquidating partially over multiple blocks instead of doing it all at once.

Feedback for proposed design

Before diving into the analysis, I wanted to give some inline feedback on the proposal.

Intro Feedback

@woof

Liquidations are bad for both protocol and users

There’s some nuance here. Insolvencies are bad for the protocol. Most liquidations are not insolvencies. Liquidations that are not insolvencies generate revenue for the protocol through the portion of the LP not paid to liquidators via the SFPF. Frequent liquidations can be bad UX for borrowers and may lead to lower user retention or reduced TVL. Still, it’s not obvious that liquidations are inherently bad for the protocol, though they are clearly negative for borrowers and slightly negative for lenders due to reduced interest income, as noted in the RFC.

In theory, all liquidations and insolvencies could be eliminated by setting collateral factors near zero and liquidation penalties near one. But that would also guarantee near-zero TVL. As a rule of thumb, very few liquidations may be a sign that the protocol is being too conservative in its product offering, while the absence of large insolvencies is usually a sign of strong risk management.

Motivation Feedback

@torrey

@woof

Thus, the user gets a “virtual swap” of collaterals to the base asset, which (after the withdrawal) will decrease the overall supply - and so it acts as a factor that contaminates the growth of the reserves.

I’m not sure I agree with this statement. In the past we’ve seen liquidations actually contribute to massive growth of reserves of a market because of the corresponding sale of the collateral back to users who wish to purchase it at a discount. The sale of the collateral absorbed from the liquidation is what contributes to reserve growth as well.

Agree with @torrey’s clarification here. This should lead to some net reserve growth, upper bounded by LP \cdot (1-SFPF) of the collateral value in expectation. Some of that will be offset by costs like liquidation delays and oracle deviations, but in general liquidations are locally profitable for the protocol. Similar dynamics can be seen on perpetuals exchanges as well.

@torrey

@woof

Liquidators should cover the whole debt position.

This section is not quite true either. The protocol actually is what assumes the whole debt position (in the form of reducing reserves). The protocol then recovers its reserves by selling the seized collateral at a discount to anyone who wants to buy it. The selling of the seized collateral is what then contributes to reserves once more to fill in the gap made by taking ownership of the absorbed debt. No liquidator needs to cover the whole of anything, rather buyers of the seized collateral only need to worry about how much of whatever seized collateral they want to purchase from the protocol collateral reserves. It is for this case that reserves are even allowed to go negative during an absorb while the seized collateral is waiting to be bought.

Agree with @torrey’s clarifications. Some numerical examples of how this works can be found in some of Gauntlet’s previous analysis here.

@woof

The main motivation under the partial liquidation is:

• To decrease the average amount of base assets, the liquidators should have to participate in the liquidation process;
• Decrease the number of cases when the user loses the whole position and increase the lifetime of the position, maximizing the amount of potential interest.

The main motivation of partial liquidations should be to pay less than full liquidations for each unit of risk reduction. Lowering this cost unlocks higher collateral factors and makes the protocol more competitive from a capital efficiency perspective.

@woof

And vice versa, the partial liquidation itself brings additional motivation for the ecosystem participants:

• It gives a mechanism that will help users keep the account’s health for a longer period.
• It encourages liquidators with low- and medium-sized portfolios to participate in liquidations;

Liquidators with any capital base can already participate in liquidations. While the absorb currently is for the full account, the subsequent collateral does not need to be repurchased all at once. Flash swaps allow liquidations to done atomically with very little capital so portfolio size is rarely the bottleneck.

Basis Feedback

@woof

The solution should not disrupt an existing mechanism for liquidators.

As stated in previous analysis, the existing mechanism makes Compound III uncompetitive. Disrupt it

@woof

The solution should, at maximum scale, re-use the existing liquidation mechanics. We need to avoid building a new infrastructure or implementing breaking changes into the existing liquidation process.

The goal should be to deliver impact. Sometimes this may require breaking changes.

@woof

The solution should not discourage liquidators from full liquidation if they want such; however, partial liquidation should become a preferable option.

The reason to do this is to execute risk reduction more cheaply for borrowers and the protocol. This should lead to liquidators getting paid less. That is the desired outcome. Giving liquidators a choice in this matter takes away a lot of the impact of this change.

@woof

The solution should keep minimal changes in the protocol’s codebase, ideally, with no modifications in existing functions, but only with the implementation of new ones.

Unclear if this is true. Reducing the audit surface seems good. New code may not be better than small modifications to existing code.

---

I follow the spirit of the constraints as listed but the main goal to do this should be improving the protocol. How much improvement the changes provide should be quantified relative to their respective costs so the community can make a decision. In that sense, none of these seem like they should be hard constraints to me.

Solutions Feedback

@woof

However, having LF as a target is inconvenient, as once we bring it back to 1, the accrued interest will exceed the LF again. Instead, we’ll use the fact that when LF = 1 it corresponds to a certain value of the health factor, which we can name LHF (liquidation health factor).

I’m not sure I follow the need to introduce this new parameter. The bound seems to be that the target HF > 1 otherwise the loan is immediately liquidatable again. How much above 1 becomes a parameter that needs to be set, regardless of whether transforming the computation to using LFs or CFs.

@woof

• (requires new parameter for assets): Increase the discount on sold collateral during the partial liquidation operation compared with the full liquidation (liquidators get more collateral cumulatively);
• (requires new parameter for assets): Increase the penalty on seized collateral compared with the full liquidation (so more collateral is seized in general compared with full liquidation);

@woof

Add a bonding curve or a linear decrease in the discount for the liquidation, from minimal to the full (so that immediate partial liquidation will bring more cumulative profit than the full liquidation of the same amount).

Paying more for partial liquidations than full liquidations defeats the purpose of this feature. Returning to the TWAP analogy breaking a larger trade into smaller ones which incur less slippage should lead to cheaper execution overall. TWAPs help users reduce execution costs when there’s less trade urgency which means market makers earn less. Similarly partial liquidations should allow the protocol to manage risk more gradually and cheaply so liquidators should be less profitable.

@woof

Introduce a new threshold for assets - PLF, partial liquidation factor (collateral factor <= PLF <= liquidation factor). It will define a respective PLHF (partial liquidation health factor). Thus, HF <= PLHF <= LHF <= bad debt health factor

Introducing a new risk parameter is a significant change, and it’s not yet clear whether it is necessary or would provide meaningful benefits.

Miscellaneous Feedback

@torrey

What if we instead start with adjusting the absorb() function to some percentage of a user’s position? (This was tough to identify in v2 what this percentage level should be depending on various states of prices in the market).

This is a great simplifying suggestion. This can provide a lot of the benefits while minimizing the audit surface. Will provide some analysis as to what this percentage should be below.

@torrey

Allowing liquidators to choose which collateral they want is likely pretty bad for borrowers as only the highest collateral factor assets are likely to be taken first meaning the borrower will lose those assets first in a falling market environment.

Nitpicking here but both the LP and LF matter in determining the liquidator’s overall profit (along with other factors such as volatility, liquidity etc) so it’s not always the case that the highest CF assets will be liquidated first.

@torrey

Additionally, for v3 we made the decision to absorb an entire debt position during a liquidation vs reading a Close Factor that existed in v2 because we noticed that there were lots of positions in v2 that could never be closed resulting in just stale assets that will likely just sit there forever.

@Midvel

to avoid stale liquidity, an additional maturity factor can be introduced, after which only full liquidations are allowed, though again - it seems not to be a problem, as position will be closed anyway after a certain threshold/number of partial liquidations

To elaborate on @torrey’s point about dust accounts, with any close factor c < 1 an account can never really be fully liquidated in practice.

The collateral remaining in each step is 1-c of the previous step so the proportion of total collateral liquidated can be expressed as

c + (1-c)c + (1-c)^2c + (1-c)^3 c + \ldots = c (1 + (1-c) + (1-c)^2 + \ldots)
= c \cdot \displaystyle\frac{1}{1 - (1-c)} = 1

as the infinite geometric series converges. Eventually the liquidation proceeds won’t be enough to cover base costs e.g. gas so will just remain in the protocol.

Would imagine it’s not worth introducing a new protocol parameter just to handle this.

@torrey

There should be discussion however on Liquidator Points, as that is what is accrued to users who liquidate by calling absorb() which absorbs bad debt positions into the protocol. Currently Liquidator Points are tracked but nothing is currently done with those points.

@Midvel

as for liquidator points - that is a good incentive mechanism which is currently unused. We can offer e.g. a reversed bonding curve to connect liquidator points to a percentage of debt closed. Though in that case, an additional rewards mechanism should be developed - e.g., a higher discount during a collateral purchase based on liquidator’s points accumulated (thus it will trigger slow burning of liquidator points without the need to unite operations of absorption and purchase)

While making use of liquidator points is a novel idea, ideally the points would reflect how much a liquidation actually benefits the protocol. That is tricky to measure accurately since it depends on external factors such as market conditions. For example, atomic liquidations should receive almost no points because liquidators are already fiercely competing to capture easy arbitrage profits. This competition suggests the protocol is already overpaying, so no further incentive is needed, which is some of the motivation behind the OEV initiative. In contrast, non-atomic liquidations that involve completing the arbitrage loop on a CEX are more valuable the faster they occur since they provide a clearer service to the protocol difficult to obtain otherwise. The most beneficial are altruistic backstop liquidations where the liquidator takes on risk without immediate arbitrage or even accepts a loss. In this context, a retroactive points program may be more effective than trying to fit a metric based on the absorption counts and base fees tracked in the protocol logic here.

Summary

Directionally, this is a good change. Some key points to keep in mind

1. The main reason to implement this is to improve capital efficiency. Raising collateral factors is only possible if the protocol can reduce overall liquidation costs for the same level of risk management. Paying more for partial liquidations just to make them more attractive to liquidators than full liquidations defeats the purpose.
2. As a result of this change liquidators should earn less. This outcome was highlighted by Euler here. It’s fair to assume liquidators are here to maximize PnL not protocol health. Giving them the option to fully liquidate when a partial liquidation that is better for the protocol is available also defeats the purpose. One way to support both paths is to allow full liquidations below a certain health factor. Aave uses 0.95 as that threshold here.
3. Before the impact of the change is established, it’s prudent to err on the side of less complexity in the implementation to reduce the audit surface.