Core Contracts

Summary

In the burn function, the contract calculates a scaled amount with amount.rayMul(index) to adjust for accrued interest, but this value is never used. As a result, when a user burns tokens, only the raw (unscaled) amount is processed. This bug causes users to receive less underlying asset than they are entitled to, directly stripping them of the full benefit of accrued interest.

Vulnerability Details

1. Scaled Amount Calculation:

   The burn function includes the following code:

   uint256 amountScaled = amount.rayMul(index);

   For example, if:

   • amount = 200 tokens (in underlying asset units), and

   • index = 2e27 (with RAY defined as 1e27, indicating that the liquidity index has doubled),

   then:

   • Expected Scaled Amount:
     amountScaled = 200 * (2e27) / 1e27 = 400 tokens.

2. Actual Burn Operation:

   Instead of using the computed amountScaled, the function proceeds as follows:

   _burn(from, amount.toUint128());

   This call burns only 200 tokens—the raw, unscaled amount—ignoring the fact that, due to accrued interest, the user's effective balance should be equivalent to 400 tokens.

3. Real-World Example:

   • Initial State:

     • A user originally mints 100 tokens when the liquidity index is 1e27.

     • Reported balance:
       100 * (1e27) / 1e27 = 100 tokens.

   • After Accrued Interest:

     • The liquidity index increases to 2e27 (doubling the interest accumulation).

     • Reported balance becomes:
       100 * (2e27) / 1e27 = 200 tokens.

   • Burn Operation:

     • The user calls burn with amount = 200 tokens (reflecting their updated, underlying balance) and passes index = 2e27.

     • Intended Behavior:
       The user should redeem the full accrued value. Since the scaled amount is calculated as:
       200 * (2e27) / 1e27 = 400 tokens, the burn should effectively account for 400 tokens of underlying value.

     • Actual Behavior:
       The function discards amountScaled and burns only 200 tokens.
       The contract then transfers 200 underlying tokens to the user.

   • Impact on the User:
     The user receives 200 tokens in underlying assets instead of the correct amount of 400 tokens, effectively losing 200 tokens worth of accrued interest.

4. Accounting Discrepancy:

   • User Loss:
     Every burn operation under these conditions results in a direct loss equal to the accrued interest that is not accounted for.

   • Total Supply Mismatch:
     The total supply, computed via scaled balances, will be higher than the amount of tokens actually redeemed, leading to inconsistencies across the protocol.

Impact

• Direct Financial Loss:
  In the above example, a user who should redeem 400 underlying tokens (due to a doubling of their effective balance) only receives 200 tokens. This is a concrete 50% loss in the value expected from the accrued interest.

• Inaccurate Accounting:
  The internal accounting of token balances and total supply becomes inconsistent with the intended interest accrual mechanism. Users’ on-chain balances (when scaled) indicate a higher value than what is actually redeemed upon burning.

Tools Used

Manual review

Recommendations

1. Integrate the Scaled Amount:

   • Modify the burn logic so that the computed amountScaled is used to determine the actual value burned. For example, instead of burning the raw amount, the burn operation should deduct the appropriate scaled amount corresponding to the user’s effective balance.

2. Align Scaling in All Operations:

   • Ensure that both mint and burn functions consistently apply the liquidity index adjustments. The _burn function should be updated to reflect the scaled (accrued) amount rather than the unscaled amount.