Glamorous Plum Baboon
Medium
The validateBorrow
and validateRepay
functions enforce the use of InterestRateMode.VARIABLE
by explicitly restricting the interestRateMode
to VARIABLE
. This approach implicitly assumes that fixed interest rate borrowing is disabled, which may unnecessarily restrict legitimate use cases where fixed interest rates could be supported.
In the validateBorrow
and validateRepay
functions, the following check enforces that only InterestRateMode.VARIABLE
is allowed:
require(
params.interestRateMode == DataTypes.InterestRateMode.VARIABLE,
Errors.INVALID_INTEREST_RATE_MODE_SELECTED
);
This requirement prevents the selection of InterestRateMode.STABLE
for borrowing or repaying, potentially limiting the flexibility of the protocol. While this may align with the current design choice of the system, it fails to accommodate scenarios where both variable and stable interest rate borrowing might be enabled in the future or in specific configurations.
By hardcoding this restriction, the code assumes that fixed interest rate borrowing is permanently disabled. Such rigid enforcement could hinder adaptability and limit the protocol’s ability to support diverse use cases.
The root cause lies in the explicit enforcement of InterestRateMode.VARIABLE
in the following lines of code:
ValidationLogic:validateBorrow
require(
params.interestRateMode == DataTypes.InterestRateMode.VARIABLE,
Errors.INVALID_INTEREST_RATE_MODE_SELECTED
);
https://github.com/sherlock-audit/2025-01-aave-v3-3/blob/main/aave-v3-origin/src/contracts/protocol/libraries/logic/ValidationLogic.sol#L168-L173
ValidationLogic:validateRepay
require(
params.interestRateMode == DataTypes.InterestRateMode.VARIABLE,
Errors.INVALID_INTEREST_RATE_MODE_SELECTED
);
The impact of this issue is medium, as it limits the protocol's flexibility and potential use cases. While the current design might intentionally restrict fixed interest rate borrowing, such enforcement eliminates the possibility of enabling both modes in future configurations or deployments without modifying the code.
This limitation could lead to missed opportunities for supporting diverse borrower preferences and adapting to changing market demands.
- Attempt to borrow with
InterestRateMode.STABLE
:
params.interestRateMode = DataTypes.InterestRateMode.STABLE;
validateBorrow(params);
// Transaction fails with INVALID_INTEREST_RATE_MODE_SELECTED error.
- Attempt to repay with
InterestRateMode.STABLE
:
params.interestRateMode = DataTypes.InterestRateMode.STABLE;
validateRepay(params);
// Transaction fails with INVALID_INTEREST_RATE_MODE_SELECTED error.
These examples demonstrate how the current implementation explicitly rejects fixed interest rate usage, even if such a feature might be desired in the future.
Refactor the validateBorrow
and validateRepay
functions to allow both InterestRateMode.VARIABLE
and InterestRateMode.STABLE
, unless explicitly restricted by protocol configuration. This change can be implemented by checking against a configurable parameter.
Add a configuration parameter to enable or disable fixed interest rate mode. Modify the require
statements as follows:
require(
params.interestRateMode == DataTypes.InterestRateMode.VARIABLE ||
params.interestRateMode == DataTypes.InterestRateMode.STABLE,
Errors.INVALID_INTEREST_RATE_MODE_SELECTED
);
// Optionally, enforce restrictions via configuration:
require(
(params.interestRateMode == DataTypes.InterestRateMode.STABLE && config.stableRateEnabled) ||
(params.interestRateMode == DataTypes.InterestRateMode.VARIABLE && config.variableRateEnabled),
Errors.INVALID_INTEREST_RATE_MODE_SELECTED
);
This approach ensures that both interest rate modes are supported, with the ability to enable or disable specific modes as needed.