LiquidityMiningCampaign Code Style Findings

LMC-01C: Inconsistent Reward Multiplier Sync

Description:

The reward multiplier is consistently updated after the user has been validated to at least have some amountStaked whereas in the linked statement it is synchronized before the validation occurs.

Example:

Copy
128updateRewardMultipliers();
129if (user.amountStaked == 0) {
130    return;
131}
132
133updateUserAccruedReward(_userAddress);

Recommendation:

We advise that the updateRewardMultipliers function is instead moved after the subceding if clause to ensure consistency across the codebase.

Alleviation:

The synchronization of the reward multipliers was adjusted to be in the same order as the other functions.

LMC-02C: Inefficient Loop Limit Evaluation

Description:

The linked for loops all extract the limit until which they are meant to iterate from the length member of an in-storage array thus causing a redundant load on each iteration.

Example:

Copy
62for (uint256 i = 0; i < lockSchemes.length; i++) {
63
64    uint256 additionalRewards = calculateProportionalRewards(_userAddress, userRewards.sub(userAccruedRewads[_userAddress]), lockSchemes[i]);
65    LockScheme(lockSchemes[i]).updateUserAccruedRewards(_userAddress, additionalRewards);
66}

Recommendation:

We advise that the limits are stored to temporary in-memory variables greatly optimizing the gas cost involved in iterating within these loops.

Alleviation:

The loop limit is now cached in the codebase properly, however, we should note that the variable utilized to do so contains a typo we advise to be fixed.

LMC-03C: Inexistent Variable Visibility

Description:

The linked variable declarations have no visibility specifier set.

Example:

Copy
20address rewardToken;
21address[] lockSchemes;
22mapping(address => uint256) public userAccruedRewads;

Recommendation:

As indeterminate visibility specifiers are automatically set by the compiler, different compiler versions may yield different results for the same piece of code leading to ambiguity. We advise that visibility specifiers for the linked variables are strictly defined to alleviate this issue.

Alleviation:

The public visibility specifier was properly introduced for both linked variables.

LMC-04C: Variable Mutability Specifier

Description:

The rewardToken variable is assigned to only once during the constructor of the contract.

Example:

Copy
28constructor(
29    IERC20Detailed _stakingToken,
30    uint256 _startBlock,
31    uint256 _endBlock,
32    address[] memory _rewardsTokens,
33    uint256[] memory _rewardPerBlock,
34    uint256 _stakeLimit) public RewardsPoolBase(_stakingToken, _startBlock, _endBlock, _rewardsTokens, _rewardPerBlock,_stakeLimit) 
35{
36
37    rewardToken = _rewardsTokens[0];
38}

Recommendation:

We advise that the immutable mutability specifier is introduced to the variable declaration to greatly optimize the gas cost involved in utilizing it.

Alleviation:

The rewardToken variable was set to immutable to benefit from the gas optimizations applied by the mutability specifier.

LMC-05C: Variable Naming Typo

Description:

The userAccruedRewads mapping is incorrectly spelled.

Example:

Copy
20address rewardToken;
21address[] lockSchemes;
22mapping(address => uint256) public userAccruedRewads;

Recommendation:

We advise that the variable name is corrected to aid in the code's legibility.

Alleviation:

The variable's spelling error was properly corrected.