Improving Lending Protocols with Liquidity Oracles

Decentralized (or DeFi) lending protocols use a simple valuation model to enable users to borrow assets against collateral. These protocols value assets using the simple formula of price times quantity, ignoring the market impact of selling on the asset price. This simple valuation model creates solvency risks, as large collateral positions cannot be liquidated at the current price. Indeed, multiple lending protocols have experienced losses from these situations. This post explores this problem and discusses how a liquidity oracle can make lending protocols more resilient.

How do Lending Protocols work?

A decentralized (or DeFi) lending protocol lets users lend and borrow cryptocurrency without going to a centralized intermediary. These protocols allow anyone to deposit collateral tokens, then borrow other tokens against them. Lending protocols use an oracle — a protocol that publishes off-chain information on chain — to continuously value the collateral and the borrow. The oracle publishes the price of each asset, and positions are valued by multiplying price (in USD) and quantity. The loan-to-value (LTV) ratio is defined as the value of the borrow divided by the value of the collateral; this ratio measures the size of the borrow in terms of the collateral. New loans can only be issued if the LTV is less than a certain ratio (the origination threshold). Once a loan is taken, the LTV evolves with market conditions. If at any time the LTV exceeds a predefined threshold (the liquidation threshold), the position is called undercollateralized and can be liquidated. Liquidation is a permissionless operation: anyone can repay a portion (typically half) of the loan on behalf of the borrower, obtaining some collateral in exchange. Liquidators receive a liquidation bonus, for example 10% of the value repaid, to incentivize them to perform this task. Liquidations are designed to decrease the loan-to-value ratio of positions or equivalently to decrease the liquidation price to maintain them below the liquidation threshold.

Let’s run through an example to illustrate lending and liquidation mechanisms. Let’s say Alice has 10ETH and wants to borrow USDT on Aave, the largest lending protocol. The origination threshold for ETH is 75%, so Alice can borrow up to 7500 USDT at an ETH price of $1,000 and a USDT price of $1. She borrows the full amount.

Now say the price of ETH falls below $937.5. The liquidation threshold for ETH is 80%, so Alice’s position is now undercollateralized.

A liquidator repays half of Alice’s debt and gets 105% of the repaid value in ETH from Alice’s collateral (5% liquidation bonus). The liquidator pays 3,750 USDT and receives 4.2 ETH. The liquidator has earned a liquidation bonus of 0.2 ETH, worth 187.5 USDT at the current ETH price of 937.5 USDT.

The Alice’s loan is now 3750 USDT, and her collateral 5.8 ETH. Her loan-to-value ratio is now 69%, and her new liquidation price is $808. Note that both her loan-to-value ratio and liquidation price have decreased.

Although this liquidation mechanism appears to be quite robust, it can and has failed in cases. The mechanism depends on liquidators actively liquidating loans before the value of the collateral falls below that of the loan. The liquidation bonus provides an incentive for these liquidators, and the fact that the liquidation threshold is below 100% provides time to act. The appropriate values of these two parameters is a constant debate between security and efficiency for lending protocols. However, despite the careful choice of these parameters, sometimes a liquidation cannot take place before the collateral value falls below that of the loan. In this instance, the protocol is left with bad debt that will never be repaid.

Why can Liquidations fail?

Liquidators want to realize a profit and avoid exposure to asset prices, so they immediately sell the collateral they receive. Typically, liquidators purchase the borrowed asset, liquidate the borrower’s debt in exchange for the collateral, then swap the collateral back to their preferred currency. The collateral swap can happen on-chain or off-chain. Thus, two problems can occur during the process of a liquidation:

1. Market impact. Placing a large trade moves the market. Market impact quantifies this movement and is defined as the difference between the average price at which one buys or sells an asset and the market price just before the order is filled. The larger the position that needs to be liquidated, the greater the difference between the average fill price and the market price. If the impact is larger than the liquidation bonus, liquidators will not liquidate the position since they cannot realize a profit.
2. Network issues. On Ethereum, network congestion can lead to transaction fees exceeding the liquidation bonus for small positions. On Solana, because transaction fees are extremely low, liquidators tend to spam the network on large liquidations, which has halted the entire network in the past. In both cases, some undercollateralized positions cannot be liquidated.

To illustrate the issue with market impact, let’s have a look at Alice’s situation when she’s about to be undercollateralized. If selling 4.2 ETH makes the average price go below $890 (market impact larger than $47.5), then liquidators can’t realize a profit. Liquidators will therefore choose not to liquidate Alice’s position, and if the ETH price continues to decline, the lending protocol will have bad debt. Network issues can be illustrated with the “Solend whale” episode: a large position on the Solend platform was nearing the liquidation threshold. In this instance, Solend’s team proposed to their community to temporarily reduce the percentage of the position that could be liquidated in a single transaction from 20% to 1% and to reduce the liquidation bonus from 5% to 2%. They hoped to “reduce liquidator spam while still giving enough of a bonus for liquidators to break even on slippage on decentralized exchanges in case the liquidation happened.”

For network issues, very little can be done by lending protocols besides extraordinary measures like the Solend team took. However, for market impact, improvements to the protocol’s logic can diminish the risk of liquidation failures. These failures occur because lending protocols only account for the best market price, which can differ significantly from the realistic average fill price for large positions. Modeling this difference can reduce the risk of failures.

Improving Lending Protocols Resiliency

Lending protocols can reduce the risk of liquidation failures by accounting for market impact. We propose three ways to use market impact to reduce the risk: (1) refined maximum loan size, (2) variable liquidation bonus, and (3) introduction of a risk interest rate. These proposals require the protocol to be able to quantify the market impact, which can be estimated off-chain from exchange liquidity and published on-chain by a liquidity oracle. We also consider some design criteria for this liquidity oracle.

a. Improving Lending Protocols’ Solvency

A first improvement is refining the maximum loan size. In current designs, users cannot borrow more than the origination threshold times their collateral value, obtained by multiplying the quantity of collateral by the current oracle price: V = qp. With market impact estimates, this valuation can be refined: V = q(p-I(q)), where I(q) denotes the impact on the price of selling quantity q of the asset. This change reduces the value of large quantities of collateral, which should make it impossible for users to create positions that are too large to liquidate (like the Solend whale). Such positions could still arise, eg. if liquidity shrinks, but at least they cannot be created.

A second improvement is variable liquidation bonuses. If the impact exceeds the liquidation bonus, the position will not be liquidated. So instead of a fixed liquidation bonus, the protocol can adjust the liquidation bonus to handle extremely large collaterals, for example, bonus = max(a, a/2 + I(q)/p) where a is the default protocol-chosen liquidation bonus. I(q)/p is the relative market impact, i.e., the market impact measured as a percentage of the price. This formula increases the size of the liquidation bonus if the relative market impact is large, thereby compensating liquidators for the market impact they will incur when they try to sell the collateral. This approach lessens the probability of liquidation failures for large positions. However, this approach only works to a certain extent: liquidations must decrease the loan-to-value ratio of positions, which sets an upper bound for the liquidation bonus.

Let’s illustrate this second proposal with Alice’s situation. Her loan is 7,500 USDT, her collateral is 10 ETH, and let’s assume the current market price is her liquidation price (1 ETH = $937.5). Let’s say the relative market impact for 4 ETH (worth $3,750 at liquidation price 1 ETH=$937.5) is estimated at 4%. Instead of 5%, the protocol gives the liquidator a 6.5% liquidation bonus per the adjusted formula above. The liquidator pays 3,750 USDT and receives 4.26 ETH. The liquidator receives an extra 0.06 ETH for the liquidation in this case. After liquidation, Alice’s loan is 3,750 USDT, and her collateral 5.74 ETH. Her loan represents 69.7% of her collateral, and her new liquidation price is $817. Note that the loan-to-value ratio and liquidation price have decreased because the liquidation bonus was reasonable, but how large could it have been? If, after liquidation, the loan-to-value ratio must be less than 75% (the origination threshold for ETH), then the maximum bonus is 16.7%. The example shows that variable liquidation bonuses help incentivize large liquidations. However, there is a limit to their effectiveness. In this example, the maximum possible bonus is 16.7%, and the liquidation would fail if that bonus were insufficient to motivate liquidators.

A third proposal is to make borrowers pay interest to the protocol itself — not to the lenders — based on their position’s risk. The risk interest rate would be computed as an increasing function of the relative market impact of the collateral and the distance between the liquidation price and the current market price. One possible formula for this rate is:

where:

• i is the instantaneous risk interest rate
• C a constant,
• I(q) the estimated market impact for the collateral quantity q,
• p the current market price,
• a the protocol parameter for liquidation bonuses (see second proposal),
• pl the liquidation price (necessarily smaller than p)
• σ a parameter depending on the volatility of the asset used as collateral.

This formula charges borrowers extra interest when two conditions are satisfied. First, the relative market impact of their position must be large compared to the liquidation bonus. Second, the current market price must be close to their liquidation prices, where the distance measure accounts for asset volatility. When these conditions are satisfied, the protocol is close to a large liquidation event, which creates a solvency risk for the protocol.

In this proposal, borrowers who threaten the protocol’s solvency have to pay extra interest. This (a) seems fair and (b) incentivizes them to manage their position. However, if the position is liquidated, any debt due to the protocol is canceled. In practice, this means liquidation is triggered with a lower loan-to-value ratio: the debt due to the protocol is included for allowing the liquidation but is canceled right after. Canceling this debt allows for a larger liquidation bonus, so the situation is less risky for the protocol. For a given risky position, if market conditions don’t change and the borrower doesn’t modify their position, the liquidation price is constantly increasing. The position will become less and less risky until the moment it is liquidated.

Again, let’s use Alice’s case to illustrate this third proposal. Assume now that Alice has not been liquidated yet and the market price is $950. Her relative market impact for 4 ETH is still estimated at 4%. It is significant (close to the normal 5% liquidation bonus), and Alice is close to being liquidated given the volatility of ETH. Suppose the smart contract uses a 1% per week risk interest. After 9 days, Alice’s debt towards Aave is 100 USDT. Her total debt is now 7,600 USDT, and her position has reached the liquidation threshold. The liquidator would receive a liquidation bonus of 6.5% (again because of the 4% estimated relative impact). At 1 ETH=$950 they pay 3,750 USDT and receive 4.2 ETH. After liquidation, Alice’s loan is 3,750 USDT, and her collateral 5.8 ETH. Her loan represents 68% of her collateral, and her new liquidation price is $808. Importantly, the liquidation price has decreased more than in the previous example, and the liquidation bonus could have been 20% while having a post-loan-to-collateral ratio of 75%. This example illustrates that the risk interest rate helps improve lending protocols’ solvency.

Note that all of these proposals face a potential issue with Sybil attacks: a user can split their large position into many smaller positions at the same liquidation price. If the price drops, all these positions will be liquidated almost simultaneously, resulting in a larger market impact than if positions were liquidated alone. To solve this problem, the impact estimate should also depend on other positions with nearby liquidation prices. Such an impact estimate would make all of the proposals above more robust.

b. Estimating Market Impact

The proposals above require the lending protocol to know the market impact I(q). It turns out that the impact is well-approximated by a linear function of the quantity q, where the slope is inversely proportional to the asset’s liquidity. We define liquidity as the sum of the order sizes in the order book of exchanges where the asset is listed. We can also discuss liquidity on a price range and/or an exchange and/or a trading pair. We also define liquidity intensity as the liquidity on a price range divided by the length of the range. Empirical observations across various cryptocurrencies, marketplaces, days, and market conditions show that market impact is well approximated by a linear function of the quantity sold q. This observation is supported by research like [1]. Equivalently, liquidity intensity l is constant across price ranges, and market impact is simply I(q) = q/2l.

For example, on Binance, the liquidity between mid-price -2% and mid-price + 2% for BTC/USDT on 07/02/2022 is roughly 2,000 BTC. The liquidity intensity is roughly 2 BTC/USDT (because mid-price -2% to mid-price +2% represents approximately 1,000 USDT). The figure below shows the impact for BTC on the same day on Binance. Each curve represents the average of 50 snapshots of the order book at particular moments in time. We plot the moments with maximal and minimal volatility, along with some that are randomly chosen. Note that the slope is roughly 0.25 USDT/BTC, which is consistent with the formula above and a liquidity density of 2 BTC/USDT.

While the plot above averages many moments in time together, the linearity property also holds for individual moments in time. The plot below shows the same function at various randomly chosen single moments in time:

c . Proposal for a Liquidity Oracle

In order for lending protocols to account for market impact, the relevant information must be published on-chain by a liquidity oracle. This oracle aggregates off-chain information about liquidity and makes it available on-chain. We make two proposals for how to build such an oracle.

Both proposals publish the liquidity of an asset (a) between mid-price and mid-price +10% and (b) between mid-price and mid-price -10%. From these two numbers, users can derive the liquidity intensity and market impact, assuming linearity per the section above. The oracles publish separate liquidity values for buying and selling because liquidity is not always symmetric.

The key difficulty in designing this oracle is how to aggregate the information. The ideal solution would be to have a number of publishers report the liquidity of every asset on every exchange. The oracle can robustly combine these liquidity estimates by taking the median, thereby preventing small groups of publishers from manipulating the result. The oracle can then add up the liquidity of the asset across all of its exchanges to create a combined liquidity estimate. (Protocols could also customize which exchanges to rely on in this proposal if they so desired.) Note that this approach gives a lower bound on the total available liquidity, as some exchanges or trading pairs may be missing. The problem with this approach is that it is difficult to scale: it requires tracking every exchange and trading pair for the asset and aggregating that information on-chain at every moment in time.

The second option is to rely on publishers to aggregate across exchanges. Publishers would compute a liquidity estimate across all exchanges they track, then submit that estimate to the on-chain oracle. The oracle could again robustly combine these estimates by taking the median. This approach is simpler but has some issues. First, it requires all of the publishers to have access to the same set of exchanges. Second, it is less transparent — even though the result is correct, it’s not clear how publishers calculated their estimates.

In both of these options, there is a further question of which exchanges and product types should be included in the liquidity calculation. We argue that the oracle should only use liquidity on off-chain exchanges. The problem is that on-chain liquidity is easy to manipulate (e.g., using flash loans). Liquidation bots today typically execute their swaps against on-chain exchanges; however, as these bots become more sophisticated, they will execute against off-chain exchanges as well (and some bots are doing so already). We also argue that the oracle should include futures markets in the liquidity estimates. Futures markets reflect genuine demand for the underlying asset but are more convenient for trading and therefore represent most of the volume.

Conclusion

We have proposed three concrete ways to improve lending protocols’ resiliency using estimates of market impact: capping loan sizes, varying liquidation bonuses, and charging risk interest rates. These three proposals need a liquidity oracle in order to estimate market impact. We additionally made two proposals for how to design a liquidity oracle. Both proposals allow users to estimate the market impact of buying/selling an asset using a simple linear formula. The creation of such an oracle and the implementation of the improvements presented could significantly improve the resilience of lending protocols.

We would love to hear your feedback on this piece! Please feel free to reach out to us in Discord with questions or comments. We’re also considering doing additional similar pieces for other use cases of oracles (such as AMMs) in the future. If you have an interesting use case for us, please let us know!

Reference

1. An Analysis of the Market Risk to Participants in the Compound Protocol, Hsien-Tang Kao, Tarun Chitra, Rei Chiang, John Morrow (Gauntlet research team). Link.