@UniLend_Finance is a permissionless decentralized money market protocol with lending and borrowing service through smart contracts.
UniLend enables users to utilize their cryptocurrencies by supplying collateral to the network that may be borrowed by pledging over-collateralized cryptocurrencies. This creates a secure lending environment where the lender receives a compounded interest rate annually (APY) paid per block while the borrower pays interest on the cryptocurrency borrowed.
UniLend Protocol V2 functions through three primary technical components:
1.Dual Asset Pool Model
UniLend utilizes isolated dual asset pools for each ERC20/ERC20-compatible pair. This design ensures that the performance or volatility of one asset does not affect others, enhancing security and stability. The architecture allows any user to create and manage lending and borrowing pools for a wide variety of assets across multiple blockchains.
2.Supply and Borrowing
3.Interest Rate Model
UniLend employs a dynamic interest rate model based on the pool’s Utilization Ratio (U), calculated as:
Ux=BorrowxBorrowx+Cashx
Borrowing Interest Rate:
Borrowing Interest Ratex=10%+(Ux×30%)
Rates increase with higher utilization to balance supply and demand.
Supply Interest Ratex=Borrowing Interest Ratex×Ux×(1−S)
This ensures suppliers earn sustainable returns while the protocol remains profitable.
These components work together to create a secure, efficient, and scalable decentralized money market.
On January 12, 2025, a security vulnerability in the UniLend protocol was exploited, resulting in the loss of approximately $200,000 from the UniLend Pool. The attacker manipulated the collateral calculations, which incorrectly assessed the user’s health factor. This flaw allowed the attacker to withdraw 60 stETH tokens without adequate collateral backing.
The stolen assets included 60 stETH tokens, leveraging the protocol’s miscalculation of user token balances.
The attacker initiated the exploit by leveraging a flash loan to deposit a massive amount of USDC into the UniLend pool. Specifically, they deposited 60 million USDC, significantly inflating their collateral within the pool.
Flash loans allow users to borrow large amounts of assets without collateral, provided the borrowed amount is returned within the same transaction.
The attacker utilized this mechanism to obtain the necessary USDC without upfront capital, thereby creating an artificially inflated position within the pool.
Upon depositing the USDC, the attacker proceeded to borrow stETH tokens. The protocol calculates the user’s collateral value based on their token balance within the pool. However, due to the flawed implementation, the balance was calculated using the current balance of tokens in the pool contract rather than the actual transferred amount during the health factor check. This discrepancy meant that the user’s token balance appeared significantly higher than it truly was, especially in pools with large liquidity.
The root of this manipulation lies in the userBalanceOfToken function. In scenarios where the pool has substantial liquidity, this function can return a high lendBalance even when there is only a small lend share remaining. This overestimation of the user’s balance provided the attacker with the illusion of having more collateral than they actually possessed. Consequently, the attacker could borrow stETH tokens beyond their rightful entitlement based on their actual collateral.
With the inflated collateral value, the attacker proceeded to redeem their USDC and stETH. The redeemUnderlying function was called, which burnt the LP tokens associated with the user’s deposit. However, due to the flawed health factor check occurring before the transfer of tokens, the system believed the user had sufficient collateral to withdraw more than they were entitled to. This flaw allowed the attacker to withdraw 60 stETH tokens without maintaining the necessary collateral, effectively gaining these tokens for free.
To prevent the attack, UniLend should have reordered the operations within the redeemUnderlying function. By performing the health factor check after transferring tokens to the user, the protocol would ensure that the user’s actual token balance accurately reflects their collateral status.
Blockchain security isn’t optional. Protect your smart contracts and DeFi protocols with Three Sigma, a trusted security partner in blockchain audits, smart contract vulnerability assessments, and Web3 security.
Click to Get Your Smart Contract Audited Today.
The UniLend exploit resulted in a significant financial loss of approximately $200,000 from the UniLend pool. This substantial loss directly impacted the platform’s reserves and reduced the available liquidity for other users, potentially disrupting ongoing lending and borrowing activities.
Following the exploit, UniLend took immediate steps to address the vulnerability and reassure its user base.
They announced a 20% bounty to the responsible party for the safe return of funds.
Addresses
Attack Transaction:
Exploiter Address:
UnilendV2Core Address:
@UniLend_Finance is a permissionless decentralized money market protocol with lending and borrowing service through smart contracts.
UniLend enables users to utilize their cryptocurrencies by supplying collateral to the network that may be borrowed by pledging over-collateralized cryptocurrencies. This creates a secure lending environment where the lender receives a compounded interest rate annually (APY) paid per block while the borrower pays interest on the cryptocurrency borrowed.
UniLend Protocol V2 functions through three primary technical components:
1.Dual Asset Pool Model
UniLend utilizes isolated dual asset pools for each ERC20/ERC20-compatible pair. This design ensures that the performance or volatility of one asset does not affect others, enhancing security and stability. The architecture allows any user to create and manage lending and borrowing pools for a wide variety of assets across multiple blockchains.
2.Supply and Borrowing
3.Interest Rate Model
UniLend employs a dynamic interest rate model based on the pool’s Utilization Ratio (U), calculated as:
Ux=BorrowxBorrowx+Cashx
Borrowing Interest Rate:
Borrowing Interest Ratex=10%+(Ux×30%)
Rates increase with higher utilization to balance supply and demand.
Supply Interest Ratex=Borrowing Interest Ratex×Ux×(1−S)
This ensures suppliers earn sustainable returns while the protocol remains profitable.
These components work together to create a secure, efficient, and scalable decentralized money market.
On January 12, 2025, a security vulnerability in the UniLend protocol was exploited, resulting in the loss of approximately $200,000 from the UniLend Pool. The attacker manipulated the collateral calculations, which incorrectly assessed the user’s health factor. This flaw allowed the attacker to withdraw 60 stETH tokens without adequate collateral backing.
The stolen assets included 60 stETH tokens, leveraging the protocol’s miscalculation of user token balances.
The attacker initiated the exploit by leveraging a flash loan to deposit a massive amount of USDC into the UniLend pool. Specifically, they deposited 60 million USDC, significantly inflating their collateral within the pool.
Flash loans allow users to borrow large amounts of assets without collateral, provided the borrowed amount is returned within the same transaction.
The attacker utilized this mechanism to obtain the necessary USDC without upfront capital, thereby creating an artificially inflated position within the pool.
Upon depositing the USDC, the attacker proceeded to borrow stETH tokens. The protocol calculates the user’s collateral value based on their token balance within the pool. However, due to the flawed implementation, the balance was calculated using the current balance of tokens in the pool contract rather than the actual transferred amount during the health factor check. This discrepancy meant that the user’s token balance appeared significantly higher than it truly was, especially in pools with large liquidity.
The root of this manipulation lies in the userBalanceOfToken function. In scenarios where the pool has substantial liquidity, this function can return a high lendBalance even when there is only a small lend share remaining. This overestimation of the user’s balance provided the attacker with the illusion of having more collateral than they actually possessed. Consequently, the attacker could borrow stETH tokens beyond their rightful entitlement based on their actual collateral.
With the inflated collateral value, the attacker proceeded to redeem their USDC and stETH. The redeemUnderlying function was called, which burnt the LP tokens associated with the user’s deposit. However, due to the flawed health factor check occurring before the transfer of tokens, the system believed the user had sufficient collateral to withdraw more than they were entitled to. This flaw allowed the attacker to withdraw 60 stETH tokens without maintaining the necessary collateral, effectively gaining these tokens for free.
To prevent the attack, UniLend should have reordered the operations within the redeemUnderlying function. By performing the health factor check after transferring tokens to the user, the protocol would ensure that the user’s actual token balance accurately reflects their collateral status.
Blockchain security isn’t optional. Protect your smart contracts and DeFi protocols with Three Sigma, a trusted security partner in blockchain audits, smart contract vulnerability assessments, and Web3 security.
Click to Get Your Smart Contract Audited Today.
The UniLend exploit resulted in a significant financial loss of approximately $200,000 from the UniLend pool. This substantial loss directly impacted the platform’s reserves and reduced the available liquidity for other users, potentially disrupting ongoing lending and borrowing activities.
Following the exploit, UniLend took immediate steps to address the vulnerability and reassure its user base.
They announced a 20% bounty to the responsible party for the safe return of funds.
Addresses
Attack Transaction:
Exploiter Address:
UnilendV2Core Address: