Exploring the DeFi lending and liquidation mechanism, its implementation principles, risks, and use cases.

Original Title: "DeFi Lending Concepts Part 2: Liquidations"

Original Author: Tal

Original Translation: Kxp, BlockBeats

This article is the second in a series of three articles discussing the workings of DeFi lending protocols - their key components, formulas, and use cases. In our previous articles, we reviewed the core operation of DeFi - lending, and how different protocols choose to implement these operations (remember "share tokens"?). In this article, we will focus on what we believe to be one of the most exciting DeFi lending concepts: liquidation.

Overcollateralization and Bad Debt

You may recall from our previous blog posts that protocol users can only borrow assets against a percentage of the collateral they provide to the protocol. This makes sense because the protocol needs to ensure that it can recover its assets (or any other assets of equal value) from you if you are unable to repay your debt. This process of collateralizing assets began in traditional finance, where today, a person can use their house or Lamborghini as collateral for a loan repayment.

Mortgage relies on the premise that the value of the collateral remains stable - although the prices of houses or Lamborghinis cannot be guaranteed, their respective values are relatively stable compared to assets such as ERC20 or NFT.

In most DeFi lending protocols, your collateralized assets must be worth more than the value of your loan, a practice known as overcollateralization.

If a loan agreement wants to maintain financial stability, it is advantageous to only allow over-collateralized loans. Imagine that you provide some assets as collateral, and the value of these assets suddenly drops below the value of the assets you borrowed from the agreement. Now, the value of your collateral is lower than the debt you owe under the agreement, and you have no incentive to repay. After all, during the process of repaying the loan, the current value of the collateral you will save is lower than the amount actually needed to repay the loan. This loan is now unable to be repaid.

Every unrepayable loan is harmful to the agreement it belongs to. The debt generated from unrepayable loans creates an unsafe factor in the agreement, as the amount of debt is the amount of assets that the lender cannot recover from the agreement. To emphasize how bad these bad debts are: if there is a situation similar to the traditional financial "bank run" on the agreement, the last group of users who extract their assets from the agreement will not be able to do so.

Of course, agreements with a large number of bad debts have less appeal to users.

Clearing and Clearing Threshold

We have determined that when the value of the collateral for a loan is lower than the value of the borrower's debt with interest (also known as being underwater), the borrower's debt poses a threat to the health of the lending agreement. To prevent an increase in underwater positions, the agreement allows third parties (not necessarily users of the agreement) to repay debts that are underwater (or close to being underwater). By repaying debts that are underwater, these third parties, known as liquidators, have the right to demand the return of the collateral of their covered debtors at a discounted price. This process is known as liquidation.

You may wonder: why does the protocol rely on third parties to liquidate unhealthy positions? After all, the protocol can encode the automatic liquidation mechanism into its code.

The cost of sending settlement transactions is very high. If the protocol automatically sends these expensive transactions, resulting gas costs will increase its operating costs, thereby weakening its profits.

In addition, the design of an automatic clearing system is very difficult. The protocol must not only consider whether a position should be automatically cleared, but also when to do so and at a rate that reflects market volatility. By incentivizing specialized third parties to clear these positions, the process can be much simpler.

Clearing is not inherently profitable - for this process, the debtor's collateral must be worth more than the amount they owe. If the clearing agent cannot guarantee that the process will be profitable, they will not clear a position.

So when can a position be liquidated? This condition is determined by the agreement and is a function of the liquidation threshold assigned to each asset.

When it comes to the clearing threshold, time is crucial. As we know, if the debt value of a position exceeds its collateral value, liquidating those positions is not profitable for the liquidator and the agreement may face bad debt. Therefore, a safe clearing threshold provides enough time for the liquidator to liquidate the positions before they become irrecoverable.

Now that we understand the motivation for each participant to maintain a healthy position, we will demonstrate how the protocol actually implements these mechanisms:

Compound: Account Liquidity

Compound involves a parameter called AccountLiquidity, which calculates the Liquidation Threshold in the Compound Comptroller main contract.

Comptroller has a function called getAccountLiquidity(), which returns information about account liquidity. Internally, this function calls getHypotheticalAccountLiquidityInternal():

Here we can see that the main logic of the function is limited to a for loop. This indicates that the calculation of account liquidity is completed by iterating through all markets in which the account participates. In other words, when calculating account liquidity, all assets that are borrowed or used as collateral by the user are taken into consideration.

Recall from our previous blog posts that cTokenBalance is the amount of underlying assets provided by the user as collateral. In this example, we also see borrowBalance and some mysterious exchangeRateMantissa, both of which are returned from getAccountSnapshot().

In our previous blog posts discussing the generalized exchangeRate variable, we wrote:

A random interest rate can increase the number of Tokens minted. If exchangeRate < 1, it can decrease the number of Tokens, and if exchangeRate > 1, it can increase the number of Tokens.

This also applies to exchangeRateMantissa, which represents the exchange rate between cToken and the underlying asset.

As we can see in this example, after obtaining the three parameters mentioned above, the Comptroller will first obtain the collateralFactor for the specific market currently being iterated. This collateralFactor information refers to the indicator of how much money a user can borrow based on their collateral. From this definition, we can assume that each collateral can be used to secure different loan amounts.

The reason why the amount varies between different assets is mainly because each asset has its own "risk" in the protocol's view, usually referring to the degree of fluctuation in asset value over time.

Compound's governance adjusts the collateral factor based on market conditions, but at no time can the collateral factor exceed 0.9 - meaning you can borrow up to 90% of the collateral you deposit:

Then, we see the call to oracle.getUnderlyingPrice(asset), which calls an external contract named Oracle.

Oracle is an interesting mechanism that deserves a dedicated blog post (stay tuned). For the sake of brevity, what we are explaining now is that Oracle is a contract used to obtain the price of an asset in a lending agreement, with the price typically based on a certain public currency (usually USD, ETH, or a stablecoin used in the agreement).

Attention: In Compound, the price of assets is denominated in US dollars (USD).

This is a rather long list of variables, but if you try to remember the Compound section in our "Token" article, you will find the following expression:

Simply represents the underlying asset value of user cToken.

In addition, the borrowBalance_{user} variable, as you can see here, is the total balance of assets borrowed by the user, including accrued interest.

Now, we have reached the following points of the candidate AccountLiquidity equations:

Maker 

Another agreement that sets a threshold for under-collateralized liquidation is Maker.

Let's check the deployment of the protocol for handling settlement in two contracts:

· Cat：liquidations 1.2，bite()。 

· grab(): VAT contract, used as a method for liquidation before deploying the cat contract.  

Let's take a look at the snippet in bite() function:

and similar segments from bark()

You may notice that both have the same not-unsafe message. Therefore, for each settlement function, the security requirements of Vault are the same and can be expressed by the following equation:

We can use this equation to define an inequality so that Vault (the name used by Maker for positions) remains secure:

Optimize it:

We suggest our readers to refer to the MakerDAO Glossary to expand on the information we provide regarding the different variable names and terms in the Maker ecosystem.

Or, you can trust us to summarize the content here: 

• spot_{ilk} is the price of the collateral used in this inequality, denominated in DAI, divided by the liquidation ratio of the collateral (determined by governance).

• ink_{urn} is the collateral balance of the position.

• rate_{ilk} is the cumulative debt of a specific collateral type. When multiplied by art_{urn}, this is a standardized debt amount for a position borrowed, and we can obtain the total debt denominated in DAI.

In order to simplify the content we just covered and avoid using Maker terminology, we will represent it as follows:

Attention: Maker has decided to value collateral and debt in DAI - the stablecoin of the protocol.

AAVE V2 - Health Factor

AAVE V2 also defines its own threshold HealthFactor. Users with a HealthFactor value of H_{f} < 1 can be liquidated.

The definition is as follows:

Obviously, when users have no debt, their positions cannot be liquidated, so the health factor defaults to type(uint256).max.

Otherwise, the health factor is defined as:

When the clearing threshold is defined independently of governance, all risk parameters, including LiquidationThresholds, are currently provided by Gauntlet on behalf of the protocol.

Bankruptcy Position Analysis

Now we have discussed the concept of bad debt, and next we will provide a real-world example to emphasize its importance.

The position we are discussing is the following account on AAVE V2: 0x227cAa7eF6D955A92F483dB2BD01172997A1a623.

Let's investigate the current situation by calling the getUserAccountData function on the AAVE V2 lending protocol.

Now let's break down the above content and see how bad the situation is for this position: 

· Total Debt ETH: 17.83508595148699ETH 

· Total Collateral ETH: 0.013596360502551568 ETH

This is all the information we need to know. The position is troublesome - the value of the collateral is only a small part of the debt.

So how did this position get into trouble?

To answer this question, we can look at the user's latest actions on AAVE: 

Everything seemed fine until block 13514857, in which a user borrowed some assets from AAVE. Let's see what they did:

The debtor borrowed 700,000 MANA, and quickly checking the USD price of MANA reveals that the price is:  

Each MANA unit is 0.00032838 ETH.

Through simple multiplication, we know that the user increased the debt of the protocol in the following way:

0.00032838 * 700000 = 229.866 ETH

It is worth mentioning that the USD price in this block is $4417.40.

Please note the deposit operation that occurred in the above figure, which took place at block 13517657 several hours after the loan. Let's see if there is anything in the market that has shaken the confidence of our users:

The above is a RPC call sent to the AAVE V2 price Oracle to obtain the wei value of 1 MANA unit in the specified block.

If we use this data to convert the above prices, we can see what happens: 

0.00033625 * 700000 = 235.375 ETH

Within a few short hours, the debt increased by 5.5 ETH, worth $24,000.

As a practitioner in the encryption industry, I will translate the following Chinese text into English without considering the context or industry-specific terms and phrases. English words and phrases in uppercase should not be translated or abbreviated, such as ZKS, STARK, and SCROLL. If there are English characters in an a tag, they should be returned without translation. When the content only contains punctuation marks, the punctuation marks should be returned as is. HTML tags in the content, such as

, , , and

, should not be translated. If there are English characters in the HTML tags, they should be omitted and returned directly. The content in the a tag should be preserved and not translated. All Chinese characters should be translated. The text to be translated is: "由于我们知道这个头寸的故事结局，我们知道它在某个时候是可清算的，因此让我们检查是否有涉及该用户地址的 liquidationCall 调用：" The English translation is: "As we know the outcome of this position's story, we know that it can be liquidated at some point. Therefore, let's check if there is a liquidationCall invocation related to the user's address:"

Once we find the first settlement event, we can understand why users deposit assets shortly after borrowing.

Here, we can see that the first settlement occurred in block 13520838. This settlement occurred before the user deposited funds (about 7 minutes before the deposit transaction).

Then, a series of small settlements occurred between blocks 13520838-13522070, and these settlements ultimately had a high value:

Let's examine all the types of collateral assets that the clearing house seizes from users across these blocks:

We can see that there are only 2 types of assets, DAI (stablecoin) and ETH.

and their quantity:  

~50 ETH 

~387663 DAI 

Some people may ask, why is clearing divided into such small blocks?

When a large position like this is liquidated all at once, the market interprets the acquisition of such a large amount of collateral as a sell signal for these asset types. Please note: according to the settlement reward policy of the agreement, assets obtained in the settlement are purchased at a discount.

A large-scale liquidation will trigger a series of liquidations. As selling pressure increases, other market participants may also sell their assets, causing asset prices to further "collapse", leading to more liquidations of other positions in the agreement.

Therefore, protocols typically limit the amount of assets that can be seized in a single liquidation. The AAVE version of this restriction, as a variable, is shown below:

As we can see, the limit percentage is 50%, which means only half of the position debt is allowed to be repaid in one settlement.

The liquidator has an incentive to split the liquidation into smaller chunks. If there is not enough liquidity in the market to provide collateral assets during the liquidation, splitting the liquidation into smaller chunks makes it more likely for the liquidator to obtain liquidation assets and profit from their liquidation.

In addition, if there is not enough liquidity in the market to acquire debt assets, the liquidator may need to spend a lot of money to obtain the debt of users who have not fully repaid their mortgages.

Finally, imagine trying to liquidate a large amount of a certain Token without actually owning that much. If you go to a DEX and try to exchange some WETH or other assets to obtain this Token, you may encounter very high gas fees, which will make your liquidation unprofitable.

To return to our example, in order to check the position parameters after a series of settlements in the chain, we need to parse the data returned to us from getUserAccountData:

Then we use the cast query chain:

Final parsing output:

Here, we can see the impact of clearing on the position: there is almost no remaining collateral, precisely 0.6 ETH. But what about the debt? It is as high as 45.26716296709878 ETH.

The MANA price of this block is how much?

0.000862110734985458 ETH。

If you remember, our user borrowed MANA at a price of 0.00032838 ETH just a few hours ago. This is equivalent to opening a short position on a stock, and the price of this stock has increased by 2.65 times.

These liquidators were unable to liquidate the entire position in time before the price dropped to a point where it was no longer profitable, leaving us with a bankrupt position.

Now, we can realize the importance of an effective liquidity threshold in preventing protocol bad debt.

Summary

Although we cannot be certain whether there is an equation to define the liquidity threshold of positions, we can certainly see similarities between protocols:

· All protocols define their threshold as a function of some collateral and debt (whether it is a ratio or a difference).

· All protocols have left some room for governance to determine the value of each collateral risk parameter based on market conditions, as some assets are more volatile than others.

· All protocols use oracles to price their collateral and debt in a widely accepted currency (such as ETH, USD, DAI).

We have seen that Maker and AAVE have chosen to use the same equation to represent the security of positions:

Original article link

欢迎加入律动 BlockBeats 官方社群：

Telegram 订阅群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方账号：https://twitter.com/BlockBeatsAsia