Core Contracts

unused timelock mechanism in RAACMinter contract

Summary

the TIMELOCK_DURATION and timeLocks mapping are declared but not used anywhere. So there's code related to timelocks that's not implemented. This could be a mistake or incomplete code. For example, functions that change critical parameters should have a timelock to prevent sudden changes. But in the current code, functions like setStabilityPool, setLendingPool, etc., can be changed immediately by UPDATER_ROLE. The presence of TIMELOCK_DURATION and the mapping suggests that the intent was to have timelocks, but they're not implemented. This could be a vulnerability if the protocol expects timelocks but they're not present, allowing immediate changes by privileged roles.

Vulnerability Details

The contract declares TIMELOCK_DURATION and timeLocks but never implements them. Critical parameter changes (e.g., setStabilityPool, setLendingPool) lack a timelock, allowing immediate execution.

implemnted but never used in RAACMinter

Impact

Privillaged roles can make abrupt changes without user notice.

Tools Used

manual review

Recommendations

Implement timelocks for sensitive functions using the declared variables

Emergency shutdown role in RAACMinter contract not used

Summary

In the constructor, the initialOwner is granted DEFAULT_ADMIN_ROLE, PAUSER_ROLE, and UPDATER_ROLE. But EMERGENCY_SHUTDOWN_ROLE is not granted to anyone. However, the emergencyShutdown function is only callable by DEFAULT_ADMIN_ROLE. So the code uses DEFAULT_ADMIN_ROLE for emergency shutdown, not EMERGENCY_SHUTDOWN_ROLE. But the EMERGENCY_SHUTDOWN_ROLE is defined but not used. This is an inconsistency. The emergencyShutdown function should be protected by EMERGENCY_SHUTDOWN_ROLE instead of DEFAULT_ADMIN_ROLE. Currently, it's using onlyRole(DEFAULT_ADMIN_ROLE), which may not be intended.

Vulnerability Details

The emergencyShutdown function checks for DEFAULT_ADMIN_ROLE instead of the defined EMERGENCY_SHUTDOWN_ROLE, creating a role inconsistency.

Impact

creates role inconsistency

Tools Used

manual review

Recommendations

Update the modifier to use EMERGENCY_SHUTDOWN_ROLE and grant the role appropriately.

Natspec contradicting code logic in LendingPool::_repay

Summary

The Natspec comments state that if onBehalfOf is set to address(0), the function should default to repaying the caller's own debt. However, the code logic reverts the transaction if onBehalfOf is address(0). This creates a mismatch between the documented behavior and the actual implementation.

Vulnerability Details

The code reverts if onBehalfOf is address(0), which contradicts the Natspec comment that suggests the function should default to repaying the caller's own debt in such a case.

Impact

Users relying on the Natspec documentation will expect the function to repay their own debt when onBehalfOf is address(0). However, the function will revert instead, leading to confusion

Tools Used

manual review

Recommendations

Update the code logic to match the Natspec documentation. If onBehalfOf is address(0), the function should default to repaying the caller's own debt.