Omniscia rain protocol Audit
Cooldown Code Style Findings
Cooldown Code Style Findings
COO-01C: Potential Mutability Optimization
Type | Severity | Location |
---|---|---|
Gas Optimization | Cooldown.sol:L45, L61 |
Description:
The Cooldown
contract is meant to be an upgrade-able contract that contains a single member set once during the initializeCooldown
function.
Example:
44/// Time in blocks to restrict access to modified functions.45uint256 internal cooldownDuration;46
47/// Every caller has its own cooldown, the minimum block that the caller48/// call another function sharing the same cooldown state.49mapping(address => uint256) private cooldowns;50address private caller;51
52/// Initialize the cooldown duration.53/// The cooldown duration is global to the contract.54/// Cooldown duration must be greater than 0.55/// Cooldown duration can only be set once.56/// @param cooldownDuration_ The global cooldown duration.57function initializeCooldown(uint256 cooldownDuration_) internal {58 require(cooldownDuration_ > 0, "COOLDOWN_0");59 // Reinitialization is a bug.60 assert(cooldownDuration == 0);61 cooldownDuration = cooldownDuration_;62 emit CooldownInitialize(msg.sender, cooldownDuration_);63}
Recommendation:
We advise the assignment to be set to a constructor
instead and the variable to be set as immutable
, reducing the gas cost of the onlyAfterCooldown
function by one SLOAD
operation on each invocation. We should note that constructor
implementations setting immutable
variables are completely compatible with upgrade-able contracts given that immutable
variables do not occupy storage space.
Alleviation:
The contract is meant to be deployed via a factory with different durations each time and as a result, the variable cannot be immutable
and shared among implementations. Based on this fact, we consider the exhibit nullified.