Comprehensive interpretation of DeFi lending: composition, formula, use case
Original title: "DeFi Lending Concepts Part 1: Lending and Borrowing"
Original Author: Tal
Original compilation: Kxp, Blockbeats
first level title
lending pool
In traditional finance (or TradFi), borrowing and lending are coordinated by third-party financial institutions. These financial institutions are entrusted with two key tasks: enforcing interest payments from borrowers to lenders, and assessing and preventing parties deemed untrustworthy from engaging in these activities.
By contrast, in decentralized finance (or DeFi), third-party borrowers and lenders are not trustworthy. This lack of trust has inspired an innovative design for facilitating the lending process on-chain.
The lending pool is a smart contract. DeFi protocol users can deposit assets (usually ERC 20 Token) with the purpose of using the contract to lend their deposited assets. Other users can interact with the lending pool and enjoy instant loans, i.e. mortgage the assets in the pool for borrowing.
Lending pools have some significant advantages when it comes to lending compared to traditional financial methods, such as:
· In DeFi, lending is not limited by the 1:1 availability of loan funds and borrowing amounts. Instead, funds from all users of the protocol are pooled, creating a token inventory large enough to satisfy lending needs immediately.
· DeFi does not require a repayment plan. Loans are executed against previously deposited collateral, and users can choose to repay at any time.
At this point, you might be thinking, “Why would I want to borrow an asset on a lending agreement if I have to put up an asset of equal value (or even overvalued) as collateral? Shouldn’t I sell the collateral and buy the borrowed asset? "
In fact, this DeFi lending protocol seems to only allow fully collateralized (or overcollateralized) loans, opening the door to an interesting "transaction" method: leverage.
Let's say you're very bullish on WBTC and pretty sure its value will skyrocket! You can deposit some WBTC (worth $1000) on your favorite lending protocol, then use that to borrow some stablecoins (e.g. USDC), then use those stablecoins to buy more WBTC on some exchange ( For our scenario, assume half of your initial deposit, which is $500). In this case, your exposure to WBTC is worth $1500, and your initial deposit was only $1000.
But what if you deposit your $500 of WBTC collateral into the protocol to borrow more USDC? This process is called over-leveraging, and you can keep doing this until you exceed your borrowing capacity, and the policy of the protocol prevents you from doing so.
first level title
share token
As with traditional finance, users who deposit assets into the lending pool are incentivized to keep their funds long-term and earn interest on their deposits. Interest accrues over time, calculated as a percentage of a user's deposit in the protocol, and claimed by their corresponding depositing user. The longer users keep assets in the lending pool, the more interest they earn.
How does the protocol keep track of each user's share in the pool? When a user deposits assets into the pool, their "share" dilutes the shares of all users, and the protocol reflects this accordingly. However, instead of directly tracking and updating each user's pool share, the protocol only handles changes to depositors' shares without actively updating other users' shares every time they withdraw or deposit.
You might think that this agreement allows you to have your cake and eat it. But it doesn't actually look like this:
The protocol handles interest payments by minting and burning ERC 20 tokens, which we call "share tokens", which represent a lender's share (or proportion of deposit assets) in the loan pool. This "Share Token" design automatically adjusts for other "Shareholders" share dilution to reflect the minting and burning of "Shares" in proportion to the deposit or withdrawal of their underlying assets.
first level title
aToken: AAVE's "Share Token"
aToken is AAVE’s yield-generating token that is minted and burned by the lending pool when depositing and withdrawing assets.
aToken is an ERC 20-like token integrated into the AAVE protocol, so each different market a user can access (deposit collateral) has a corresponding aToken.
If we look at the AAVE lending pool contract, we can see the basic operations that happen when a user deposits assets into the pool:
We can see that the aToken corresponding to the market that the user deposited will be called in the "minting" function.
We can see that the actual amount to be minted is:
As shown in the image above, in this example the user joins a market that has already earned some interest on previous deposits. The above equation helps us understand this because it shows how to account for the accrual of interest for all users using a global index, which is updated on various operations (deposits, withdrawals, etc.).
When users withdraw their underlying assets, the liquidityIndex will be used as a multiplier to calculate the amount of tokens owed in the transaction.
Here is the relevant code snippet from the lending pool contract:
Here, the balanceOf function of the aToken contract is a bit strange. After all, we just established that the amount of aToken minted is not the same as the amount of the underlying asset deposited. How does calling IAToken(aToken).balanceOf(address(user)) yield the amount of underlying asset that the user is about to withdraw (as shown at the bottom of the function)? The reasons are as follows:
· When users withdraw their assets, their aTokens will be destroyed. These burnt aTokens keep the total amount of aTokens owned by other users proportional to their share after the user's assets have been withdrawn.
· The market rate for users to withdraw funds will be updated with each withdrawal.
As we stated earlier, aToken is an ERC 20-like token. We emphasize that they are "similar" to ERC 20 tokens because their balanceOf function has unique properties. In a regular ERC 20 Token, the balanceOf function returns the number of Tokens an address owns.
Since aToken represents a share of the pool, rather than an immediate value, aToken's balanceOf function returns the amount of Base Token that the protocol owes the user to compensate for their deposit.
Here, the balanceOf function overrides the balanceOf function in the inherited aToken contract. As a result, the balanceOf logic in this example logic is executed instead of the normal (inherited) map lookup of user token quantities.
The number of Tokens mentioned above is then multiplied by the result of getReserveNormalizedIncome, which performs the following logic:
We can identify the branch here:
· If the reserved data has been updated in this block: returns the liquidityIndex value of this market as it has been updated.
· Otherwise: we need to see what happens in calculateLinearInterest to figure out the next flow.
The currentLiquidityRate and lastUpdateTimestamp from the ReserveData object of the current market are passed into this function, and the result of the function is:
Let's break down the components of this equation to better understand the gist of the linearInterest value:
currentLiquidityRate: Think of this as the annual interest rate (APY) for our market
block_{timestamp} - lastUpdatedTimestamp: time elapsed since last update
Note: Since we chose the second branch in getNormalizedIncome, the value is guaranteed to be positive at this point.
Therefore, we can think of this interest accrual mechanism as a simple interest compounding mechanism, which is compounded in each block. Now that we have determined the amount of interest to accrue for the user, we just need to multiply that value by the liquidity index and then do the user's normalized income multiplication in the balanceOf function:
Now that we understand the logic behind aToken, we still need to solve the mystery of how the liquidityIndex works.
In the example below, the liquidityIndex can be defined as the interest accumulated by the reserve over a certain period of time:
Recall the previously mentioned liquidityRate variable - now we will discuss its use in calculating the liquidityIndex. Interest will only accrue if the liquidityRate is greater than 0 - in other words, interest will only accrue if there is any APY in that market. It makes sense.
Let's quickly review calculateLinearInterest in action:
The above logic can be transformed into the following equation:
As we can see in the DefaultReserveInterestRateStrategy.sol contract, the liquidityRate is defined in the following way:
Therefore, it can be written as:
The overall borrowing rate (overallBorrowRate) is defined here as:
We can write this as:
The utilization rate (utilizationRate) can be defined as:
When defining utilization, it is easier to consider the ratio between the liquidity in reserves (currently lent liquidity) and the total liquidity in the market, which can be simplified as:
Now we can write the equation for the liquidity index using these two definitions:
Since totalBorrows exists in both the numerator and denominator, we can write:
first level title
cToken: Compound's "Share Token"
Let's move on to our next lending protocol example, Compound.
Compound handles borrowing and lending using "share tokens" called cTokens. This Token is used to record all assets that can be used for user lending in the Compound protocol.
Similar to what we discussed in AAVE V2, Compound’s “share tokens” are minted and used to redeem the underlying asset.
Compound uses an exchange rate similar to AAVE V2's Liquidity Index to determine how many cTokens should be minted. The exchange rate is a function like this:
Let me explain the key terms here:
·totalCash: The number of ERC 20 basic Tokens owned by the cToken account.
· totalBorrows: The number of ERC 20 basic tokens in the market borrowed by borrowers.
· totalReserves: A certain number of ERC 20 basic tokens reserved, which can be extracted or transferred through governance.
· totalSupply: An ERC 20 function that returns the total supply of a cToken.
With this background, we can write Compound's exchange rate equation:
When a user deposits an ERC 20 Token, the exchange rate determines how many cTokens will be minted in return:
first level title
eToken: Euler's "Share Token"
To further solidify the similarities between these protocols, let’s analyze another lending protocol, Euler, and see how it handles lending.
In the example below, the deposit function allows users to deposit ERC 20 Tokens in exchange for eTokens.
As we can see, internalAmount is the amount of eTokens minted for this transfer.
Once again there is a direct overlap with Compound's name and function exchangeRate.
Let me explain the key parameters used to calculate exchange rates:
· poolSize: In the ERC 20 contract using the underlying asset, the result of calling the balanceOf(address) function with the pool contract address.
· totalBorrows: The total amount of ERC 20 basic tokens lent, which are not currently in the pool.
· totalBalances: The total balance of all eToken holders.
Summarize
Summarize
We have covered 3 lending protocols:
· AAVE V2
· Compound
· Euler
We have examined how “Share Tokens” are minted and how they are exchanged for deposit assets through lending pools.
The three equations we propose can be reduced to a simple equation:
Remember that the exchange rate can be defined in any way the protocol defines. These arbitrary exchange rates can increase the amount of tokens minted (if less than 1), and decrease the amount if greater than 1.
In AAVE V2 and Compound, we've seen some similarities to the someRate variable. In Compound, someRate is:
For AAVE V2, someRate is defined as follows:
The liquidity index is defined as:
While we cannot generalize each protocol's exchange rate into a single formula, for AAVE 2 and Compound we know that the exchange rate is a function of the total liquidity in the market. Going back to our equation, given that totalLiquidity is the total amount of ERC 20 base tokens in the market, then the numerator in the exchangeRate expression and the denominator in the liquidityRate expression are functionally identical.
Original link
