Lending is the biggest crypto vertical based on the TVL (Total Value Locked), exceeding $50B at the time of writing. Over the years, lending has been one of the greatest primitives in DeFi, with the major contributor being Aave due to its simple nature and easy-to-understand architecture.
This blog discusses the core fundamentals of Lending that users, developers, and auditors must understand, security vulnerabilities to consider while interacting with or auditing these protocols, and their prevention.
Lending and Borrowing Protocols Taxonomy: Classification based on Design
Lending Protocols are not just limited to a single architecture or design, but have expanded to cater to different sets of users with different risk requirements. We try to divide lending protocols based on features around how they handle liquidity, borrowing efficiency, and their design.
There are certain overlapping features in all of them, while covering all of them will go out of scope, we have discussed major features offered by top protocols here.
But before we move on to classification, let’s focus on the basics of Lending and Borrowing Protocols and understand some terminologies. Lending Protocols are easy to interact with, and users get the concept of where the yield is generated from easily.
Borrowing
Users can borrow funds by depositing collateral into the protocol. For each asset a user borrows, there is a Loan-to-Value (LTV) ratio pre-determined. This ratio is decided based on the asset volatility.
For example, if a user provides 1 ETH at the price of $2500 as collateral and the LTV ratio is 80%, they get $2000 USDC in return.
Lending
The liquidity provided to the borrower comes from the pool where lenders provide the initial liquidity. The borrowers pay interest on the amount they borrowed, this interest generates yield for the lenders, hence incentivizing them.
Liquidation
Each borrowing position, when opened, is subject to borrowing funds up to the LTV (Loan-to-Value) ratio. With this ratio pre-defined, there is another metric involved, known as the liquidation threshold. Liquidation Threshold is a point where, if the value of collateral drops, the position is subject to liquidation.
Liquidation is usually carried out by a Liquidator, this liquidator pays off the debt in exchange for the discounted collateral they receive from the position they liquidated.
Utilization Rate
The Utilization Rate is calculated with a simple formula as follows:
APY (Annual Percentage Yield)
APY is the yield accrued on an asset over the year. This yield is compounded in nature on the principal amount the lender deposited. The formula to calculate APY is as follows:
Note: The above image is for representational purposes only and does not reflect the exact architecture or functioning of any specific protocol.
There are multiple ways to classify lending protocols, including interest rate mechanism, liquidation mechanism, liquidity management, collateral management, and more. We have tried to cover the major ones here:
Collateral Management
This section classifies protocols based on how they manage the collateral on their loans. The lending protocols can be broadly classified into three categories:
Overcollateralized Lending
This is the most common type of lending protocol. Most of the on-chain lending protocols are overcollateralized in nature. Protocols like Aave and Compound fall under this category as they require users to provide more collateral than they are borrowing.
They are completely trustless and permissionless and require no user information to execute a certain transaction.
Undercollateralized Lending
Undercollateralized Lending is a type of protocol that provides more amount of loan than the value of the collateral itself. The borrowers here are mostly institutions that are looking for loans, and the protocol vets them. Protocols like Wildcat come under this category.
Here, borrowers are allowed to set their terms, and lenders get exposure to private credit infrastructure to earn yields.
Uncollateralized Lending
Uncollateralized Lending, or Flashloans, is the type of borrowing in which the borrower doesn’t need to provide any upfront collateral to get the loan.
Since flashloans are restricted to per block, and if the loan is not returned in a particular block, the transaction is reverted. To facilitate this, protocols take a small fee from the users (0.05% of the borrowed amount in Aave v3).
Interest Rate Mechanism
The Protocols can be classified based on the Interest Rate Mechanism for borrowers and lenders. There are two categories to cover here:
Float Rate
Most lending protocols like Aave utilize floating rates that change based on the utilization rate. These dynamic rate changes incentivize users to either borrow more or lend more.
If the utilization is high, the lender APY increases as the borrow rate increases, attracting more lenders, while in contrast, if the utilization is low, the borrow rate is low, increasing the borrowing on the platform.
Fixed Rate
Certain new protocols also tried out the different direction for calculating the interest rate. In such protocols, the interest rates are fixed for lenders and borrowers, reflecting less volatility to users. Protocols like Notional Finance fall under this category.
Liquidity Management
This section classifies these protocols based on how they manage liquidity. There are different ways to manage liquidity and the markets within the vertical.
Pooled Liquidity
While pooled liquidity is generally not a great idea since risk is democratized to a pool of assets but the protocols have tried out different strategies to improve capital efficiency in the space. In the pooled liquidity, all the protocol’s lending liquidity is pooled in a single smart contract.
A great example of such a protocol is Fluid. Fluid has maximized capital efficiency by utilizing the collateral deposited by the users in lending markets in a spot pool to earn interest on the collateral itself, reducing the borrowing rate for the borrower.
Isolated Liquidity
Isolated liquidity is generally considered more secure as the pool is concentrated on a particular asset, and users who are looking for exposure to certain assets only prefer such protocols. Liquidity is siloed in protocols like Silo and users can choose where to provide liquidity.
Other Mechanisms
These are certain mechanisms that cannot be categorized but are witnessed in the lending space as an interesting and emerging feature, and can be called Looping or leveraged lending strategy.
Leveraged Lending Vaults
Leveraged Lending Vaults are mostly seen as a feature that a protocol offers to serve high-risk enabled users. A user allowed leveraged is based on the LTV ratio of a particular pool. For a pool with a 90% LTV ratio, the allowed leverage would be 10x. The leverage here can be calculated using the following formula:
- A user lends $100 in a pool with 90% LTV.
- The vault takes a flashloan of $900.
- The initial $100 deposited by the user and $900 borrowed through a flashloan are deposited in the pool.
- Against the $1000 in collateral, $900 is borrowed (90% LTV)
- This $900 is used to repay the flashloan, and the user attains the optimum leverage position.
This position is possible through the Liquid Staking Tokens pool and yield-bearing assets. Since there is an interest that needs to be paid on the borrowed funds from the pool, the user earns positive interest if the (Accrued Yield on the Asset > Borrow Rate).
Source: Kamino Lend Multiply Vault Docs
Attack Vectors in Lending and Borrowing Protocols: Targets on Pricing Mechanism, Governance, Smart Contracts, and More
Oracle Manipulation Attack
Oracle Manipulation attacks are common in the DeFi space. In the context of Lending Protocols, the attacker's goal is to borrow more than the collateral they provide and put the protocol into bad debt.
These attacks mostly occur when protocols depend on a single source of price, which can be manipulated, such as the pricing from a Uniswap Pool. This is how the price of a token can be calculated from a Uniswap pool in simple terms:
Though a sophisticated DeFi protocol cannot rely on such a simple equation, as attackers can manipulate the amount of tokens in the pool easily through Flashloans, especially in pools with low liquidity. Bad pricing mechanisms can sometimes lead to unintended liquidations as well.
To protect a protocol from Price Manipulation Attack, developers/auditors can take the following measures:
- Don’t use a single source dependency for the price, which can be easily manipulated.
- Use a decentralized oracle like Chainlink to get the correct and updated prices of assets.
- If getting a price from Uniswap, consider using TWAP (Time-Weighted Average Price). TWAP is a price source that takes out the average of the price over a given period of time to protect from any short-term price discrepancies.
While all these methods might ensure a secure price feed, it is important to analyze the risks by comparing the cost and profit of the attack. If the cost is relatively less than the profit, then there is always a chance that an attack can happen, which is possible in the case where pricing comes from TWAP.
Recently, Loopscale was hacked due to its bad pricing mechanism for principal tokens from other protocols. The attacker took a series of undercollateralized loans after manipulating the price of tokens.
Join 1400+ leaders who secured themselves from losing Billion Dollars.
Governance Attacks
Lending Protocols, which are run through DAO, can be attacked as a bad actor can pass a proposal by either gaining enough voting power or manipulating the governance fundamentals.
These proposals can change the risk parameters of a protocol, whitelist certain assets, and change reserve factors in favor of the attacker.
To protect a protocol from a Governance attack, one can take the following measures:
- Include Timelocks that introduce delays between the proposal approval and execution to filter any malicious proposals.
- Introduce higher quorum thresholds that are hard to achieve by attackers. Quoram thresholds ensures that enough members of DAO participate in the proposal.
Read the guide to prevent a protocol from governance attacks to know more and stay secured.
Reentrancy Attacks
Reentrancy attacks generally occur when the attacker's smart contract does an external call without updating the contract storage. The reentrancy attack is observed around ERC777 tokens, as these tokens use the tokensReceived hook.
In the case of the lending protocol, the attacker provides collateral and borrows the ERC777 tokens. Now, since the attacker has completed the LTV check by providing collateral at the first place, they can borrow multiple times, as the storage wasn’t updated before transferring the tokens.
To protect a protocol from a Reentrancy attack, one can do the following:
- Ensure the contract follows a Check Effects Interaction pattern to avoid external calls without the state update.
- Use a Reentrancy Guard to avoid reentrancy attacks on certain functions.
Smart Contract Vulnerabilities and Business Logic
While the above categories overlap with this one, there is a great chance of vulnerabilities in how the protocol handles accounting logic, precision decimals, the liquidation engine, business logic, and more.
It is important for developers/auditors to properly vet the business logic and its implementation before allowing the contracts to handle the actual funds. They should look at how the following implementation works:
- Liquidation Engine: Check the design and flow of how liquidation happens.
- LP Tokens Mispricing: Some Lending Protocols let users borrow against their LP tokens, and the pricing mechanism of these tokens often needs to be verified.
- Economic Design: Check for vulnerabilities in the protocol's economic design, such as how it rewards its users and whether any incentive can become an attack vector.
- Dependency on different Assets: A lending protocol runs best when the markets are less volatile, as fewer liquidation events occur. It is important to analyze how a protocol reacts in the case when another protocol fails, such as scenarios where a certain stablecoin depeg.
Conclusion
Lending and Borrowing Protocols are one of the biggest verticals in Decentralized Finance and handle a huge amount of value, thus exposing them to more risk. The article covers the basics of lending protocols to understand them from a user and developer perspective.
Developers and Auditors should mitigate maximum attack vectors and analyze the business logic correctly to safeguard users from any unintended risk and vulnerability.
At QuillAudits, with our 7+ years of experience in testing and auditing smart contracts attested with our multi-layered auditing framework, we ensure that protocols and users are secure.
