Thanks to OpenZeppelin for valuable feedback and the support of the partial liquidation initiative. It is highly appreciated when the security provider supports the ecosystem enhancement initiatives and engages in active discussions.
First of all, we agree that liquidations are a natural mechanism designed to maintain the health of the protocol and to serve as an extension of the ecosystem, introducing independent participants. The thoughts in RFC are targeted at the full over-liquidation, which creates a set of risks already described in the RFC and with some key points which were noted by OpenZeppelin during the audit of the Compound (as an over-liquidation and as a point of additional monitoring).
As for the points raised in the report.
1. Partial Liquidations and Target Reserves
The role of the targetReserves in the Comet was already discussed during the Compound III audit, as it was noticed that the chosen strategy of holding reserves may not be optimal. However, the role of target reserves is not discussed within this particular RFC, as it has no intention of changing that logic and has no impact on the fulfillment of targetReserves:
- The RFC aims to keep the invariant of closing off collateral purchases after the targetReserves are reached;
- Operations unification (absorb+purchase) does not mean the violation of the target reserves, as it is a matter of implementation. Thus, the RFC poses no intent on changing this logic, but working around the user interface only.
- Additionally, based on the received feedback, the unification is not mandatory, but rather optional, solely for the convenience of the liquidator.
Thus, thank you for highlighting the point, but the concern is primarily related to the specific implementation rather than the solution itself. The team will keep this in mind and add it as an additional invariant to be maintained during solution testing.
2. Selective Collateral Seizure
The point describes the possibility of meeting the grief risk, connected with the seizure of a particular “strong” collateral. First of all we need to notice, that the current implementation of the liquidation possesses a part of such a risk: the order of collaterals in the Comet is mostly arbitrary, thus there are situations when the “strong” collateral is placed first, and during the full liquidation it is the first to be seized. Thus, even now, there exist situations when the user will end up with a “weaker” portfolio and will not be able to enter the debt position again. And vice versa - based on the order of collaterals, the Comet may end up with higher reserves of “weaker” collaterals seized during the liquidations. Thus, in general, such a risk (while having low likelihood) is present even now.
However, the feedback contains a valuable point that indeed, the allowance of collateral choice may impact the behavior of liquidators. Though during the RFC preparation, this risk was analyzed, and the solution is based on certain points:
- From the Comet point of view, all collaterals are equal, as there is no ordering and ranking of collaterals to point to particular ones.
- All collaterals are limited by their respective caps; thus, even if some collateral is seized more frequently, it will create a natural flow of its supply back, as other collaterals are limited in their caps.
- Even if a “stronger” collateral is seized first, it is by default added to the Comet reserves (as this logic will not be violated), thus the Comet in general will end up in a “stronger” position;
- Also, such allowance of collateral choice serves as an additional incentive for liquidators to participate in partial liquidations.
- A higher rate of collateral seizure will create a natural flow of its sale into the market by liquidators, purchase by users, and re-supply for new positions (or to strengthen existing ones), ultimately reaching an equilibrium point.
However, a good point is to have a regulation of this process. We have to think about two approaches:
- Setting the max % of a particular collateral to be seized during the partial liquidation - that will have a ranking of collaterals from “stronger” (with lower % available to seize) to “weaker” (with higher available % for seizure). It will force liquidators to choose several collaterals instead of a single “stronger” one and will limit the impact on the users’ positions.
- (our preference) to have an order of collateral seizure, having collaterals forcibly ranged from “stronger” to “weaker”. It will eliminate the need to select collateral for seizure and present an order for partial liquidation based on the asset’s risk profile.
3. Partial Liquidation Factor
Introduction of a partial liquidation factor is connected with several points:
- The full liquidation factor cannot be increased or decreased, as it is chosen based on a certain risk profile assigned to a Comet.
- Though there is a need to have a window for partial liquidation, avoiding full liquidation.
- There is a need to create an incentive for liquidators to participate in partial liquidation.
Thus, the new parameter was introduced and tested to fit the existing liquidation criteria.
As for raised concerns.
During the full liquidation, no additional interest will be earned at all (as the debt will be closed). Together with the loss of position and collateral for the user, they thus have even less chance of entering a new position. Lose-lose situation for both the protocol and the user. Partial liquidation prolongs the position lifetime, keeping interest for the protocol (compared with 0 interest after full liquidation) and collateral for the user.
Even now, the lower the price drops, the greater portion of the net position is lost for the user. Partial liquidation introduces no changes in this logic. Additionally, in the event of a continuous price decline, partial liquidation mitigates its impact, whereas now it serves as a catalyst for cascade liquidations, which causes further harm to the protocol.
The introduction of a gap for partial liquidation softens the risk profile of a borrower. Currently, the majority of the liquidity is kept within 1-2% range from the liquidation threshold. Thus, any significant or prolonged price decline will introduce massive or cascade liquidations. While the additional inflation of the liquidation threshold softens the effect of price declines and allows the ecosystem to react to it earlier. Also, the system does not prohibit setting the partial liquidation factor differently from the liquidation threshold itself, so no additional collateralization inflation may be introduced e.g. for “strong collaterals” - it is an option for certain “weak” collaterals.
This is the sense of partial liquidation - to bring the account back to a healthy state as early as necessary, thus prolonging its timeline. Though RFC explicitly states that the position should result in HF higher than eligible for partial liquidation, to avoid the “chain reaction”.
Additionally, the primary effect of partial liquidation is to mitigate the risks the protocol faces during extreme or prolonged price declines. Based on the introduced researches of the liquidation process (here and here) the over-liquidation creates certain risks to the ecosystem (liquidation of large positions, cascade liquidation after price fall on 2-5%, a lot of liquidity within 1% from the liquidation threshold, unaccounted slippage, etc), which can be softened by the partial liqudiation. While it will encourage users to keep a higher percentage of collateral unutilized, it will help mitigate most of the risks.
Though the RFC, firstly, does not prohibit setting a partial liquidation factor the same as a full liquidation factor, and secondly, it provides an additional incentive mechanism connected to the discount for liquidators. Thus, it can be supported without the “additional forced collateralization”. So, while the introduction of the additional parameter should be considered during risk modeling for the Comet, the parameter itself does not impact the balancing process due to its complexity itself. As a result, the risk profile of a user is softened, helping the protocol to avoid listed risks.
4. Insufficient Modelling
Modeling conducted during the solution development was targeted at proving the solution’s integrity and demonstrating the concepts used within it. While the historical data was analyzed (including research pointed out in the feedback itself), it was used for the ideation of the solution and the analysis of the risk profile of typical users. It makes more sense to show the applicability of the solution and the work of the approach in general, while the more selective modeling will be used for the exact parameter choice at later stages.
However, it is a great point, and additional modeling is already included in the development pipeline: modeling will be performed on existing markets to choose the first ones to implement the partial liquidation extension, modeling will be performed to find the and choose initial parameters, and modeling will be performed to analyze the change in the behavior of users after the partial liquidation implementation. We see it as modeling connected to the implementation itself and to the particular parameters for chosen markets, thus it is planned for later stages. Of course, the results will be shared with OpenZeppelin during the future audit of the implementation of the RFC.
5. Liquidator Portfolio Size as a Participation Barrier
While the point on flashloans is valid, we just cannot exclude different participants from the liquidation ecosystem. We observe that a class of users is willing to participate in the liquidation process. Thus, while the portfolio size is not a restriction or key factor, it remains a valuable point to be considered in the analysis. Also, flashloans remain a valuable instrument right now, but we cannot wrap the whole ecosystem around them - thus the extension of participant types will work for the protocol.
6. Mandatory Opt-In for Borrowers
Based on the history of the Compound protocol upgrade - each protocol upgrade was mandatory for each user with no custom opt-in. However, that is why the upgrade process includes enough steps for users to prepare their positions: community discussion, snapshot voting, development timeline, audit, proposal processing, upgrade procedure, upgrade enabling. That gives enough transition time.
Though to avoid too much stress on the ecosystem, the upgrade plan may be introduced during the development. Thus, markets will be upgraded in a certain order with a certain timeline, preparing the community for the upgrade. Additionally, the development already includes another pause flag (available to the DAO, like all other flags) to pause the partial liquidation on the entire Comet.
Thanks again to @jbass-oz for the support of the initiative, for your involvement into the discussion, and for highlighting the points to pay attention to. All points are analyzed and either already included in the RFC, or planned for the development pipeline and for the period of the implementation preparation for the audit.