Omniscia rain protocol Audit

TierByConstruction Code Style Findings

TierByConstruction Code Style Findings

TBC-01C: Potential Mutability Optimization

Description:

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

Example:

contracts/tier/TierByConstruction.sol
44event TierByConstructionInitialize(
45 /// `msg.sender` that initialized the contract.
46 address sender,
47 /// Tier contract to reference.
48 address tierContract,
49 /// Construction block to reference.
50 uint256 constructionBlockNumber
51);
52/// Tier contract to reference.
53ITier internal tierContract;
54/// Construction block to reference.
55uint256 internal constructionBlockNumber;
56
57/// Initialize the tier contract and block number.
58/// @param tierContract_ The tier contract to check against construction.
59function initializeTierByConstruction(ITier tierContract_) internal {
60 // Tier contract must be configured. Set to a contract that returns `0`
61 // for `report` to disable tier checks.
62 require(address(tierContract_) != address(0), "ZERO_TIER_ADDRESS");
63 // Reinitialization is a bug.

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 isTier 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, however, the constructionBlockNumber must remain settable in an initialize-style function given that it is meant to indicate the proxy's "construction" rather than the logic contract's.

Alleviation:

The Rain Protocol team stated that the TierByConstruction contract has been deprecated and will be removed soon. As a result, we consider this exhibit acknowledged.