Core Contracts

Summary

The calculateLiquidityRate function is designed to compute a net liquidity rate by subtracting a protocol fee from a gross liquidity rate. However, the implementation subtracts a fee computed as a fraction of the gross liquidity rate using RAY multiplication. In effect, this reduces the rate that liquidity providers receive, acting as a discount rather than charging a fee in the traditional sense.

Vulnerability Details

Liquidity Rate Calculation

The function in question is defined as follows:

• Gross Liquidity Rate:
  Computed as utilizationRate.rayMul(usageRate), it represents the full interest rate based on system utilization and usage parameters.

• Protocol Fee Amount:
  Calculated by multiplying the gross rate by protocolFeeRate (using rayMul), which—if protocolFeeRate is nonzero—produces a fee that is then subtracted from the gross liquidity rate.

• Net Liquidity Rate:
  The function returns the gross liquidity rate minus the fee. Thus, instead of adding a fee component to the borrower’s cost or accumulating fees separately, the fee is applied as a discount to the depositors’ yield.

Key Observation

If the protocol fee is set (for example, a 10% fee expressed in RAY), the net liquidity rate becomes 90% of the gross rate. While mathematically correct for a fee subtraction, this implementation effectively reduces the interest rate that depositors receive, rather than properly charging a fee to the borrowers or allocating the fee to protocol revenue. As a result, the protocol is not collecting fees in the expected manner—it is simply lowering the deposit rate.

Impact

• Reduced Depositor Yield:
  Depositors receive a lower interest rate (net liquidity rate) due to the fee subtraction. This might be interpreted as a discount on the deposit yield rather than a fee charged to borrowers.

• Fee Misallocation:
  The deducted fee amount is not being handled separately (e.g., credited to a fee pool) but is merely subtracted from the liquidity rate. This could lead to unintended economic consequences if the protocol is meant to generate revenue through fee collection.

• Inconsistent Incentives:
  The intended design is to charge borrowers a fee while giving depositors the full gross liquidity rate (or to handle fees in a separate mechanism), this approach misaligns incentives. Borrowers might not be paying the expected fee, and the protocol may not accrue sufficient revenue.

• Potential for Economic Exploitation:
  Users might be incentivized to deposit funds expecting a higher yield, not realizing that a portion of the interest is effectively “discounted” away as a fee. This can distort market behavior and lead to suboptimal outcomes for both liquidity providers and the protocol.

Tools Used

Manual review

Recommendations

1. Reassess Fee Application:
   Determine whether the protocol's intent is to charge borrowers a fee or to reduce depositors’ yield. If the fee should be charged to borrowers, then the liquidity rate calculation should not subtract the fee from the deposit yield. Instead, the fee should be applied separately or added to the borrow rate.

2. Separate Fee Accumulation:
   Consider modifying the mechanism so that the fee amount is accumulated in a dedicated fee pool or added as a premium on borrow rates, rather than directly discounting the liquidity rate.