The StabilityPool contract is designed as an upgradable contract, yet it imports and inherits from the non-upgradeable ReentrancyGuard. This can result in storage layout mismatches and potential upgrade issues, affecting long-term contract stability.
Inconsistent Import:
The contract currently imports:
whereas, for upgradable contracts, the upgradable version should be used:
Implications:
Storage Layout Mismatch:
Non-upgradeable contracts have a fixed storage layout. Using a non-upgradeable ReentrancyGuard in an upgradable contract may lead to conflicts during upgrades, since the proxy pattern relies on consistent storage layout across versions.
Initialization Issues:
Upgradable contracts require explicit initialization of inherited contracts. The non-upgradeable ReentrancyGuard does not support this, potentially causing uninitialized state variables or misaligned storage.
Maintainability:
The presence of non-upgradeable components in an upgradable contract can cause confusion among developers and auditors, and may lead to future upgrade risks.
While the immediate functionality of the contract is not compromised, the use of a non-upgradeable ReentrancyGuard increases the risk of subtle bugs during future upgrades or migrations.
If the contract is upgraded, mismatches in storage layout between the non-upgradeable ReentrancyGuard and its upgradable counterpart could result in unexpected behavior or require complex migrations.
Manual review
Use the Upgradable Version:
Replace the current import with:
Adjust Inheritance:
Modify the contract declaration to inherit from ReentrancyGuardUpgradeable:
Initialize the Reentrancy Guard:
In the initialize function, include the initialization call:
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.