BakerySwap security record

The linked segments contain the unicode icon 🦄 as a leftover from Uniswap.

We have taken note of an extensive test suite located in the repository, however we advise that fuzz-based testing is introduced to ensure that the values retrieved from the reward calculation follow the plot you have set within the calculations.

The linked mathematical statements are conducted in a different order than each other, with the former being a subtraction - multiplication - division and the latter being a subtraction - division (w/ subtraction rounding) - multiplication. In Solidity, the order of mathematical execution is important as there is no concept of a decimal number and divisions are rounded down.

The linked case ensures that `fromBulkNumber` is greater-than (>) the literal 0 before multiplying it with a value in the ternary operator after being subtracted by 1. Since the value is subtracted by 1, in the case that `fromBlockNumber` is 1 the multiplication would again yield 0.

The conditionals check whether the uint256 variables are less than the literal 1. This is only the case when the value is 0.

The linked statements conduct a greater-than (>) comparison between an unsigned integer and the value literal 0.

Each instruction on the EVM costs gas to execute and in this case, each member of the struct is independently written to instead of conducting a single mass-write by instantiating a `PoolInfo` declaration in `memory` and subsequently assigning it to `poolInfoMap[_pair]`.

The manual zeroing operations could instead be replaced by a delete operation on `poolUserInfoMap[_pair][msg.sender]` which is more readable and gas efficient.

The newly added boolean variable is meant to represent whether an entry to the new poolInfoMap mapping exists to prevent duplicate calls to the add function. While this functions as intended, it is possible to utilize the already-existent non-zero variable `lastRewardBlock` for this particular purpose.

The linked newly introduced assignment should utilize the already existent `_feeToSetter` variable in `memory` rather than retrieving the newly stored `feeToSetter` variable from `storage`, optimizing the gas cost involved in deploying the contract.