Hector Network security record

The `mintWithdraw()` function doesn't have any access control and it can be called by anyone. An attacker can call the function with itself as the `recipient` and an arbitrary `redeemAmount`, thus draining the funds from the Redemption Treasury contract.

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.

The smart contract does not check or store the return value of an external call in a local or state variable, which may introduce vulnerabilities due to the unhandled outcome.

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.