Hector Network (Audit 2)

When the farming contract receives reward tokens during a distribution period, only parts of the reward tokens are actually distributed: **(endTime - lastRewardTimestamp)/(endTime - beginRewardTimestamp + 1)*[received amount]** There will be leftover tokens in the farming contract. ```solidity=290 uint256 multiplier = block.timestamp - lastRewardTimestamp; uint256 tokenReward = (multiplier * totalReward) / totalRewardPeriod; rewardAmount += tokenReward; accTokenPerShare += ((tokenReward * SHARE_MULTIPLIER) /totalTokenBoostedSupply); ``` For example, in an 8-week emission period, if the farming contract receives rewards on the first second of week four and the farming contract is also updated on that timestamp, only 5/8 newly added rewards will be distributed among stakers.

In the contract LockFarm, the function `onRewardReceived()` updates the variables `totalReward` and `totalRewardPeriod` which are used in the calculations of `pendingReward()`. However ,`updateFarm()` updates the variables `accTokenPerShare` and `lastRewardTimestamp` which are also used by calculations in `pendingReward()`. Users who view the `pendingReward()` function would see a different expected rewards output once the `updateFarm()` logic is executed elsewhere in the contract. Notice that other Masterchef-like contracts will update pools when changing the emission rate.

In the current implementation, there is no upper limit for the `RewardWeight`. Misuse of these fee setting functions could interrupt the reward split. For example, receivers with `RewardWeight` set higher to 10000 will get all reward tokens, preventing other receivers from receiving rewards. Also, `RewardWeight` of all receivers should add to 10000 to make sure each receiver can get their share of rewards.

State variables that are unchanged in the code base can be declared as `constant`.

The variables assigned in the constructor can declare with `immutable`. Immutable state variables can be assigned during contract creation but will remain constant throughout the lifetime of a deployed contract. A big advantage of immutable variables is that reading them is significantly cheaper than reading from regular state variables since will not be stored in storage. Still, values will directly insert the values into the runtime code.

The function that affects the status of sensitive variables should be able to emit events as notifications to listeners.

The computation for each iteration is complex, it could lead to gas insufficiency when the `receivers` length is extremely large.

In the contract `LockFarm`, the function `processReward()` calculates the variable `boostedAmount` internally with the supplied config parameters. Each respective function that calls `processReward()` recalculates `boostedAmount` for local use.

In the contract `LockFarm`, function `stake()` requires the parameter `secs` to be greater than zero and greater than or equal to `lockedStakeMinTime`. `lockedStakeMinTime` is already assign `7 days` and not modified within the code base, making the initial greater than zero check redundant.

The contract `LockAddressRegistry` only enables including farms to the `_isFarm` mapping. Should a farm become compromised, the contract should be able to disable the status of the address.