In-depth discussion on the DeFi lending and liquidation mechanism and its implementation principles, risks and use cases
Original title: "DeFi Lending Concepts Part 2: Liquidations"
Original compilation: Kxp, BlockBeats
Original compilation: Kxp, BlockBeats
first level title
Overcollateralization and Bad Debt
You may recall from our previous blog post that protocol users can only lend or borrow assets based on a percentage of the collateral they provide to the protocol. This makes sense, since the protocol needs to ensure that it can recover its asset (or any other asset of equal value) from you if you fail to repay the debt. This process of asset mortgages started in traditional finance, for example today, where a person can put their house or Lamborghini as collateral for loan repayments.
Mortgages rely on the precondition that the price of the collateral maintains its value - although the price of a house or a Lamborghini is not guaranteed, their respective values are relatively less volatile and more stable than assets such as ERC 20 or NFT.
In most DeFi lending protocols, your collateralized loan assets must be worth more than the value of your loan, which is called over-collateralization.
Only allowing over-collateralized loans is beneficial if the lending protocol wants to maintain financial stability. Imagine you put up some assets as collateral, and the value of those assets is suddenly lower than the value of the assets you borrowed from the protocol. Now, your collateral is worth less than what you owe to the protocol, and you have no incentive to pay back. After all, in the process of repaying the loan, the collateral you will be bailing out is now worth less than the amount actually needed to repay the loan. This loan is now insolvent.
Every defaulted loan is detrimental to the agreement it is in. Debt arising from insolvent loans creates an element of insecurity in the protocol, after all, the amount of debt is the amount of assets that the lender cannot recover from the protocol. To underscore how bad these bad debts are: if there was something like a traditional financial "bank run" on the protocol, the last users to withdraw their assets from the protocol would not be able to do so.
first level title
Liquidation and Liquidation Threshold
We have established that when the loan collateral is worth less than the borrower's interest-bearing debt (also known as undercollateralization), the borrower's debt poses a threat to the health of the lending agreement in which it is placed. To prevent undercollateralized holdings from increasing, the protocol allows third parties (not necessarily users of the protocol) to repay undercollateralized (or close to undercollateralized) debt. By paying off the debt below the collateral, these third parties, known as liquidators, are entitled to demand the return of their covered debtor's collateral at a discount. This process is called liquidation.
You might be wondering: why does the protocol rely on third parties to liquidate unhealthy positions? After all, protocols can encode automatic liquidation mechanisms into their code.
The cost of sending a clearing transaction is very high. If the protocol automatically sends these expensive transactions, the resulting gas costs will increase its operating costs, thereby weakening its profits.
In addition, the design of automatic liquidation system is very difficult. Protocols must consider not only whether a position should be automatically liquidated, but when to do so, and at a rate that reflects market volatility. By incentivizing dedicated third parties to liquidate these positions, the process is much simpler.
Liquidation is not inherently profitable - for this process, the debtor's collateral must be worth more than the amount they owe. If the liquidator does not guarantee that the process will be profitable, they will not liquidate a position.
So when can a position be liquidated? This condition is determined by the protocol and is a function of the liquidation threshold assigned to each asset.
Timing is very important when it comes to liquidation thresholds. As we know, if the debt value of a position exceeds its collateral value, liquidating these positions is not profitable for the liquidator, and the protocol will also face bad debt. Therefore, a safe liquidation threshold provides sufficient time for liquidators to liquidate positions before they reach a state of insolvency.
first level title
Compound: Account Liquidity
Compound involves a parameter called AccountLiquidity, which calculates the Liquidation Threshold in the Comptroller, the main contract of Compound.
Comptroller has a function called getAccountLiquidity() that returns information about the account's liquidity. Internally, this function calls getHypotheticalAccountLiquidityInternal():
We see here that the main logic of the function is scoped within a for loop. This shows that computing account liquidity is done by iterating over all markets in which the account participates. In other words, when calculating account liquidity, all assets that users have borrowed or used as collateral are taken into account.
Recall from our previous blog post that cTokenBalance is the amount of underlying asset that a user provides for collateral. In this example, we can also see borrowBalance and some mysterious exchangeRateMantissa, both returned from getAccountSnapshot().
In the generalized exchangeRate variable discussed in our previous blog post, we wrote:
"An arbitrary interest rate can increase the number of Tokens minted. If exchangeRate < 1, it can reduce the number of Tokens. If exchangeRate > 1, it can increase the number of Tokens."
This also applies to exchangeRateMantissa, which represents the exchange rate between the cToken and the underlying asset.
As we can see in this example, after getting the three parameters mentioned above, the Comptroller will first get the collateralFactor of the specific market that is currently iterating. This collateralFactor information is an indicator of how much a user can borrow against their collateral. From this definition, we can assume that each collateral deposit can be collateralized with different borrowing amounts.
The reason this amount varies between assets is primarily because each asset carries its own "risk" in the eyes of the protocol, usually referring to the degree to which the asset's value fluctuates over time.
Compound’s governance changes the collateralization factor based on market conditions, but at any point, their collateralization factor cannot exceed 0.9 — up to 90% of the collateral you deposit can be lent out:
Then, we see a call to oracle.getUnderlyingPrice(asset), which calls an external contract called Oracle.
Oracles are an interesting mechanism that deserves a dedicated blog post (stay tuned). For the sake of brevity, what we're explaining now is that an oracle is a contract used to obtain the price of an asset in a lending protocol, usually in some public currency used by the protocol (usually USD, ETH, or a stablecoin used by the protocol) as the basis.
Now that we've covered all the factors that affect the health of an individual market, we'll write down the equation to calculate AccountLiquidity for an individual market:
Note: In Compound, asset prices are denominated in United States dollars (USD).
That's a pretty long list of variables, but if you try to remember the Compound section from our "Share Token" article, you'll find the following expressions:
It simply represents the basic asset value of the user's cToken.
Additionally, the borrowBalance_{user} variable, as you can see here, is the total balance of the asset borrowed by the user, including accrued interest on it.
first level title
Maker
Another protocol that sets thresholds for liquidating undercollateralized positions is Maker.
Let's examine the two contracts that the protocol deploys to handle liquidations:
Dog: Deployed after migrating to liquidations 2.0 (what Maker governance calls it). The liquidation function here is bark().
· Cat：liquidations 1.2 ，bite()。
grab(): VAT contract, used as a method for liquidation before the cat contract is deployed.
Let's look at the snippet in bite():
and a similar snippet from bark():
You may notice that both have the same not-unsafe message. Therefore, Vault's security requirements are the same for each liquidation function and can be expressed by the following equation:
We can use this equation to define an inequality so that Vault (the name Maker uses for positions) is still safe:
Optimize it:
We recommend our readers to head over to the MakerDAO Glossary to expand on the information we provide about different variable names and terms in the Maker ecosystem.
Alternatively, you can trust what we've outlined here:
• spot_{ilk} is used in this inequality as the price of collateral, 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 liability for a particular collateral type. When multiplied with art_{urn}, which is the normalized amount of debt borrowed by a position, we get the total debt denominated in DAI
To simplify what we've just covered, without using Maker terminology, we'll represent it like this:
first level title
AAVE V2 - Health Factor
AAVE V2 also defines its own threshold HealthFactor. Users with a health factor value of H_{f} < 1 can be liquidated.
It is defined as follows:
Obviously, when users have no debt, their positions cannot be liquidated, so the health factor defaults to type(uint 256).max.
Otherwise, the health factor is defined as:
first level title
Bankruptcy Position Analysis
Now that we have discussed the concept of bad debt, we will provide a real-world example to emphasize its importance.
The position we are going to discuss is the following account on AAVE V2: 0x 227 cAa 7 eF 6 D 955 A 92 F 483 d B2B D 01172997 A 1 a 623 .
Let's investigate the current state of the AAVE V2 lending protocol by calling the getUserAccountData function on it:
Now let's break down the above and see how bad things are with this position:
· Total owed ETH: 17.83508595148699 ETH
· Total pledged ETH: 0.013596360502551568 ETH
That's all we need to know, this position is in trouble - the collateral is worth a fraction of what is owed.
So how did this position get into trouble?
To answer this question, we can look at the most recent actions performed by this user on AAVE:
All seemed fine until block 13514857, where a user lent some assets from AAVE. Let's see what they do:
The debtor has borrowed 700,000 MANA, a quick look at the USD price of MANA reveals that the price is:
0.00032838 ETH per MANA unit.
By simple multiplication, we know that this user has increased the debt of the protocol by: 0.00032838 * 700000 = 229.866 ETH
It is worth mentioning that the USD price at that block is $4417.40.
Note the deposit operation that occurred in the image above, at block 13517657, a few hours after the borrow. Let's see if anything in the market has shaken the confidence of our users:
Above is the RPC call sent to the AAVE V2 price oracle to get the wei value for 1 MANA unit in the specified block.
If we transform the above prices using this data, we can see what happens:
0.00033625 * 700000 = 235.375 ETH
In just a few hours, the debt increased by 5.5 ETH, worth $24,000.
Since we know the end of the story for this position, we know it will be liquidable at some point, so let's check if there is a liquidationCall involving this user address:
Once we find the first liquidation event, we can understand why users deposit assets shortly after borrowing:
Here we can see that the first liquidation occurred at block 13520838. This liquidation occurs before the user deposits funds (~7 minutes before the deposit transaction).
Then, between blocks 13520838-13522070 there was a series of small liquidations that ended up being worth quite a lot:
Let's examine all collateral asset types seized by liquidators from users between these blocks:
We can see that there are only 2 assets, DAI (stablecoin) and ETH.
and their counts:
~ 50 ETH
~ 387663 DAI
One might ask, why is the liquidation divided into such small chunks?
When large positions like this are liquidated in one go, the market interprets such large collateral acquisitions as a sell signal for these asset types. Remember: Assets acquired in liquidations are purchased at a discount according to the protocol's liquidation reward policy.
A large liquidation triggers a cascade of liquidations, and as selling pressure builds, other market participants may also sell their assets, causing a further "crash" in the asset's price, which in turn leads to more liquidations of other positions in the protocol.
As such, protocols typically limit the amount of assets that can be seized by a single liquidation. This limitation of the AAVE version, as a variable, is as follows:
As we can see, the limit percentage is 50%, which means that only half of the position's debt is allowed to be repaid in one liquidation.
Liquidators have an incentive to split their liquidations into smaller chunks. If there is not enough liquidity in the market to provide collateral assets at the time of liquidation, then by breaking the liquidation into smaller chunks, the liquidator is more likely to obtain the liquidated assets and profit from their liquidations.
Additionally, if there is not enough liquidity in the market to acquire debt assets, it may cost liquidators a lot to acquire debts that have to be repaid to undercollateralized users in the first place.
Finally, imagine trying to liquidate a large amount of some kind of token without owning that much. If you go to a DEX and try to exchange some WETH or other assets to get this token, you may encounter very high gas fees, which will make your liquidation unprofitable.
Returning to our example, in order to check the position parameters after a series of liquidations in the chain, we need to parse the data returned to us from getUserAccountData:
Then we query the chain using cast:
Final parsing output:
Here we see the effect of the liquidation on the position: there is almost no collateral left, 0.6 ETH to be precise. But what about debt? Up to 45.26716296709878 ETH.
What is the MANA price for this block?
0.000862110734985458 ETH。
If you recall, our user borrowed MANA just a few hours ago for 0.00032838 ETH. This is equivalent to opening a short position in a stock whose price has risen 2.65 times.
These liquidators were unable to liquidate the entire position in time before the price dropped to an unprofitable level and we were left with a bankrupt position.
Summarize
Summarize
While we cannot be sure if there is an equation that defines the liquidity threshold for a position, we can certainly see similarities between the protocols:
All protocols define their threshold as a function of some sort of collateral vs. debt (whether it is a ratio or difference).
All protocols leave some room for governance to decide the value of each collateral risk parameter based on changing 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 (e.g. ETH, USD, DAI).
Original link
