Omniscia rain protocol Audit

Cooldown Code Style Findings

Cooldown Code Style Findings

COO-01C: Potential Mutability Optimization

Description:

The Cooldown contract is meant to be an upgrade-able contract that contains a single member set once during the initializeCooldown function.

Example:

contracts/cooldown/Cooldown.sol
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 caller
48/// 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.