Overview

Liquity’s new whitepaper is available here.

Since the release of our original whitepaper in May 2020, the team has been working to refine and improve the Liquity protocol in various ways. While the main system mechanics remain largely unchanged, we have introduced a number of protocol improvements, which we will explain in this post.

The most important enhancement for borrowers is that the net loss incurred in case of a liquidation is now always capped at 10% of the debt, even if the system is in Recovery Mode. Further changes include:

• Out-of-order and batch liquidations
• Redesign of Recovery Mode
• Gas Compensation and Liquidation Reserve
• Mitigation of loss evasion by Stability Providers
• Redemptions
• Fee slippage protection

Out-of-order and batch liquidations

Originally we wanted to enforce a strict order on liquidations: a Trove should only be liquidated if there are no liquidatable Troves with a lower collateralization ratio. This was intended to be an elegant way of providing fairness to the borrowers and to remove any source of arbitrariness.

Unfortunately, the limitations of the Ethereum network make this goal practically unattainable unless we were to introduce a very high minimum size requirement on Troves. Otherwise, an attacker could create many small, low collateral troves and clog the system by slowing down the liquidation sequence. Even though Liquity allows for liquidating up to 90–95 Troves in one transaction (with the current block gas limit of 12.5m) — starting with the least collateralized one — the sheer number of low collateral Troves could significantly delay the liquidation of larger Troves higher up the sorted list.

Given that our system heavily relies on quick and efficient liquidation of debt, we need to offer an easy way to specifically liquidate large Troves, making sure that a substantial portion of the debt can be cleared quickly. To that end, we decided to allow liquidations of arbitrary batches of Troves, expecting that liquidation bots will prioritize the larger ones thanks to the higher gas compensation (see below). The system can tolerate smaller Troves remaining unliquidated for a longer time, as it is not the number, but the total pending debt that matters in the end.

Redesign of Recovery Mode

Liquidations

While liquidations in Liquity primarily happen by offsetting a Trove’s debt against the Stability Pool, the system reverts to a redistribution of debt and collateral if the Stability Pool is empty or fully used up during liquidation. As a second line of defense, all Troves in aggregate thus contribute to system solvency.

To make sure that the system as a whole remains sufficiently collateralized for absorbing liquidations, Liquity incorporates a Recovery Mode. This special mode of operation is triggered if the total collateralization ratio (TCR) drops below 150%, and extends the conditions for liquidating Troves. In Recovery Mode, Troves can be liquidated if their collateral ratio is below the TCR. In Normal Mode, only troves below 110% are subject to liquidation.

In the initial version of Recovery Mode, liquidation would have been possible up to a collateralization of 150%. However, we changed the threshold to the TCR (which per definition is below 150%) since liquidating Troves with a collateralization ratio between TCR and 150% would actually deteriorate the total collateralization of the system. It does not make sense to liquidate a Trove whose individual collateralization ratio is above the system’s average.

Another, more substantial, change we made relates to the amount of collateral taken away from the liquidated borrower in Recovery Mode. In the initial version of the whitepaper, the Trove’s entire collateral would have been liquidated and sent to the Stability Pool. This was due to the fact that liquidations would only happen in ascending order of collateral ratio. Which means the system would likely switch back to Normal Mode long before reaching troves with collateralization ratios close to 150% — mitigating expected losses.

After relaxing the strict liquidation order, any Trove with a collateralization ratio below TCR can now be liquidated as the system enters Recovery Mode. A liquidation loss accounting for up to 50% of the Trove’s debt would be harsh for borrowers. It also turns out that such an excessive liquidation penalty is not necessary to incentivize Stability Providers: as long as LUSD is trading below its hard upper bound of $1.10, liquidations should be profitable provided that the liquidated collateral is worth 110% of the liquidated debt.

Therefore, we decided to cap the liquidation loss at 110% of the collateral during Recovery Mode. Any remainder, i.e. the collateral above 110% (and below the TCR), can be reclaimed by the liquidated borrower using the standard web interface.

This means that a borrower will face the same liquidation “penalty” (10%) in Recovery Mode as in Normal Mode if their Trove gets liquidated. Liquidation of Troves above 110% is only done against the Stability Pool (i.e. they are exempt from redistribution), and requires that the entire debt can be liquidated at once.

Given the profitability enhancements for the Stability Pool during Recovery Mode, we expect Stability Providers to swiftly replenish the pool so that it would eventually cover the entire debt of the liquidatable Trove. Thus, we can avoid the complexity of partial liquidations which, due to the 10% cap, would actually result in a lower TCR of the system.

Liquidation under Recovery Mode can be summarized by the following rules:

Restrictions on Trove operations and no borrowing fees

We‘ve also overhauled the restrictions on Trove operations during and at the cusp of Recovery Mode in order to eliminate inconsistencies and to make borrowing operations path-independent. In terms of restrictions, it shouldn’t matter in which order a borrower sends their transactions.

All Trove operations that would deteriorate the TCR are temporarily disabled if the system is in Recovery Mode or if the operation would trigger Recovery Mode by pushing the TCR below 150%. In such a case, it is not possible to:

• increase the debt of existing Troves
• retrieve collateral from Troves
• reduce the collateralization ratio by adjusting both the debt and collateral

until the TCR of the system improves.

Furthermore, new Troves can only be opened during Recovery Mode if their collateral ratio is at least 150%. This allows the generation of fresh liquidity in difficult times, while preventing users from inadvertently creating Troves that may immediately fall victim to a liquidation.

Permitted Trove operations resulting in an issuance of fresh LUSD (opening of new Troves >150%, increase of collateral and debt of existing Troves) are explicitly encouraged during Recovery Mode. Such Trove operations are thus exempt from the borrowing fees — making the loan free of charge (minus gas costs).

Gas Compensation and Liquidation Reserve

We spent dozens, if not hundreds, of hours on gas-optimizing liquidations to make them viable even in times of crazy high Ethereum gas prices.

The gas costs of liquidating Troves mainly depends on the number of Troves liquidated in a given transaction. The more Troves that are liquidated in the same transaction, the lower the gas costs per Trove. This bulk discount is possible due to a net metering of the storage gas costs in the Instanbul update (EIP-2200). While liquidating a single Trove costs about 215K-450K gas, the costs per Trove go down to 75K-85K for 10 Troves and to 65–70K for 65 Troves. We are not aware of any DeFi project that offers similar gas savings through batch liquidation.

Nevertheless, we realized that people may still need an explicit incentive to trigger liquidations other than the fact that liquidations are generally beneficial to the Stability Pool. That’s why we introduced a gas compensation for liquidators (senders of the liquidate transaction) given by the following formula:

gas compensation = 50 LUSD + 0.5% of trove’s collateral (ETH)

The intentions behind this formula are:

• To ensure that smaller Troves are liquidated promptly in normal times, at least
• To ensure that larger Troves are liquidated promptly even in extreme high gas price periods. The larger the Trove, the stronger the incentive to liquidate it.

The 50 LUSD is funded by a Liquidation Reserve: when a borrower opens a new Trove, an amount of 50 LUSD is held back by the protocol as a compensation for the gas costs if the Trove needs to be liquidated. The 50 LUSD is added to the Trove’s debt, leading to a minimum collateral requirement of 55 USD worth of ETH. For comparison: MakerDAO’s minimum debt size is ~36x larger at 2,000 DAI.

Note: The 50 LUSD Liquidation Reserve is subject to change and pending further analysis. It may increase before launch.

The variable 0.5% part (in ETH) comes from the liquidated collateral, slightly reducing the liquidation gain for Stability Providers.

Mitigation of loss evasion by Stability Providers

While we are committed to allowing Stability Providers to withdraw their deposits anytime, there is one case where we made an exception. Whenever there are liquidatable Troves with a collateralization ratio below 110% in the system, Stability Pool withdrawals are temporarily disabled until all of those Troves are liquidated.

Suspending withdrawals mitigates the issue of loss-evasion by depositors if a brisk price drop leads to Troves with a collateralization lower than 100%. We are aware that this does not fully solve the additional issue of oracle front-running where Stability Providers would withdraw their deposits before the oracle price is updated. However, we think that this is an unrealistic strategy for most Stability Providers since front-running requires constant monitoring just to potentially avoid a very rare situation.

The Stability Pool offers a convenient and passive way to benefit from the liquidation gains and the LQTY rewards without requiring special technical skills or active user interaction. For the same reason, we are not worried about users staying outside the Stability Pool that would only deposit LUSD on the spot when juicy Troves become liquidatable. Such a strategy (facilitated by combining the deposit and liquidate calls in one transaction) improves the system’s solvency just as regular liquidations do. Remember: If necessary, the system is also secured by the redistribution mechanism as a fallback.

Redemptions

Redemptions disabled when TCR < 110%

The redemption facility is our main mechanism to keep a minimum LUSD price floor of $1 (minus redemption fee). While this is a crucial building block of the protocol, it must take second place to system solvency (total LUSD supply is always backed by debt) in case of an absolute emergency. If the system’s total collateralization ratio (TCR) drops below 110%, the protocol therefore suspends redemptions.

This protects the system from a further TCR decrease, given that liquidatable Troves with collateralization ratios below 110% are skipped in case of a redemption. In practice, the redemption sequence will start at the Trove with the lowest collateralization ratio above 110% and traverse the list of Troves in ascending order of collateralization ratio.

Allowing redemptions if the TCR is below 110% would lower the average collateralization since it would wipe off Troves in the upper half of the list. That’s why it makes sense to suspend them in this extreme scenario and reactivate them when the TCR recovers and reaches 110% again.

Consequences of a full redemption

In case of a redemption the system uses the redeemed LUSD amount to repay the riskiest Trove with the lowest collateralization ratio. If the amount is higher than the Trove’s debt (i.e. the Trove is fully redeemed from), the system proceeds with the next riskiest position and so on.

Initially Troves would have been left open if affected by a redemption, regardless of whether the redemption is full or partial. However, leaving open Troves that have been fully redeemed from led to implementation challenges, since such Troves would have a 0 debt and thus an infinitely high collateralization ratio.

This would potentially mess up our sorted list of Troves since different 0-debt Troves may receive different debt and collateral shares from other Troves through the redistribution process (the fallback mode of liquidation when the Stability Pool is empty). For this reason, we decided to close Troves in case of a full redemption and make the remaining collateral (in ETH) claimable by the borrower.

Note that directly pushing the remainder to the Trove owner’s Ethereum address was no alternative for us. While nicer from a UX perspective, such a solution would have introduced security issues because of the fallback function of the Solidity contract that may be attached to the owner’s address. Given that the fallback function can contain arbitrary code, it may revert for any reason and effectively block redemptions.

Fee slippage protection

Liquity charges two types of fees:

• borrowing fee on the amount of LUSD issued as a loan
• redemption fee on the LUSD amount that is redeemed for ETH (note that redemption is not the same as repaying your own debt, but something that can be done by any holder)

Both fees are algorithmically determined by a base rate. The base rate increases with every redemption, depending on the amount redeemed, and slowly decays (i.e. decreases) over time.

When a user sends a transaction to open a loan or increase an existing debt, they most likely do that relying on the current borrowing fee shown by the UI. However, it is possible that a pending redemption transaction gets processed before the borrower’s transaction is added to a block, which may negatively impact the fee.

To mitigate this issue, we introduced a protection mechanism similar to Uniswap’s slippage protection: users can specify a maximum percentage they are willing to pay when sending the transaction. This can be higher than the current fee, according to the user’s choice. The same mechanism applies to redemptions, whose fee can similarly be driven up by other redemptions that are processed first.

‍