Core Contracts

Summary

The function getUtilizationRate computes utilization as follows:

However, totalBorrowed (from lendingPool.getNormalizedDebt()) is scaled by 1 × 10^27 while totalDeposits (from stabilityPool.getTotalDeposits()) is likely scaled by 1 × 10^18. This scaling mismatch results in an erroneously high utilization rate. Moreover, an attacker could exploit this discrepancy by temporarily inflating the utilization before an emission update, thereby manipulating the dynamic emissions schedule.

Vulnerability Details

Scaling Mismatch:

• Normalized Debt:
  The value returned by lendingPool.getNormalizedDebt() is in high-precision units (scaled by 1 × 10^27).

• Total Deposits:
  The value from stabilityPool.getTotalDeposits() is in standard token units (scaled by 1 × 10^18).

• Current Calculation:
  The contract calculates utilization as:

  Utilization = (totalBorrowed * 100) / totalDeposits

  For example, if:

  • totalBorrowed = 1 × 10^27 (representing 1 underlying unit)

  • totalDeposits = 1 × 10^18 (representing 1 underlying unit)

  then:

  Utilization = (1 × 10^27 * 100) / (1 × 10^18) = 1 × 10^11 (or 100,000,000,000%), which is far greater than the expected 100%.

Potential Exploitation:

• Manipulation Opportunity:
  An attacker can temporarily inflate the totalBorrowed (for example, using a flash loan) just before an emission update. This spike would artificially raise the computed utilization.

• Emission Rate Impact:
  A high utilization triggers the contract to increase the emission rate. Once the attacker repays the borrowed amount, the protocol remains with an elevated emission rate, leading to excessive token minting.

Proof-of-Concept (POC) Example

Assume:

• totalBorrowed = 1 × 10^27 (normalized, representing 1 underlying unit)

• totalDeposits = 1 × 10^18 (representing 1 underlying unit)

Expected Utilization:
If 1 unit is borrowed out of 1 unit deposited, the utilization should be 100%.

Current Calculation:
Utilization = (1 × 10^27 * 100) / (1 × 10^18) = 1 × 10^11 (or 100,000,000,000%)

Outcome:
The computed utilization is orders of magnitude higher than intended. An attacker could exploit this by causing a temporary spike in totalBorrowed, thereby increasing the emission rate before repaying the borrowed funds.

Impact

• Misguided Emission Adjustments:
  Incorrect utilization data will cause the emission rate to be adjusted inappropriately, potentially leading to over-minting of tokens.

• Economic Exploitation:
  Attackers can leverage this vulnerability to manipulate the dynamic emissions schedule, benefitting from artificially high emission rates.

• System Instability:
  Inaccurate metrics and potential exploitation can destabilize the reward and emission mechanisms, undermining the protocol's economic model.

Tools Used

Manual review

Recommendations

1. Correct the Scaling:

   • Adjust the calculation to account for the scaling difference. For example, convert totalBorrowed from a 1e27 scale to a 1e18 scale by computing:
     adjustedBorrowed = totalBorrowed / 1e9
     Then, compute:
     Utilization = (adjustedBorrowed * 100) / totalDeposits

2. Mitigate Manipulation:

   • Consider implementing time-weighted averages or delay mechanisms to smooth out temporary spikes in utilization caused by flash loans or short-term borrowing.