Having no clear path to define totalLpPoolWeight and initially set totalLpPoolWeight to zero maybe problematic for the protocol

[code423n4]

Lines of code

https://github.com/code-423n4/2022-05-backd/blob/2a5664d35cde5b036074edef3c1369b984d10010/protocol/contracts/tokenomics/LpGauge.sol#L111
https://github.com/code-423n4/2022-05-backd/blob/2a5664d35cde5b036074edef3c1369b984d10010/protocol/contracts/tokenomics/InflationManager.sol#L581
https://github.com/code-423n4/2022-05-backd/blob/2a5664d35cde5b036074edef3c1369b984d10010/protocol/contracts/tokenomics/InflationManager.sol#L588

Vulnerability details

For totalLpPoolWeight to have some values, someone need to call InflationManager.executeLpPoolWeight. During the execution process, totalLpPoolWeight will need to go through totalLpPoolWeight = totalLpPoolWeight - currentUInts256[key] + pendingUInts256[key]; which can be problematic because the initial value of totalLpPoolWeight is zero that requires subtraction from currentUInts256[key] which I also have no information about the value but I assume that the value should not be absurdly high.

Since uint256 does not support negative value, the subtraction between these two variables would result in an underflow which will prompt error in solidity 0.8.0. However, the contract imports UnceckMath library, enable underflow possible. Therefore, the subtraction of totalLpPoolWeight - currentUInts256[key] can be restated as type(uint256).max - currentUInts256[key]. This produces an absurdly high totalLpPoolWeight which may affect currentRate of the pool causing it to likely be zero.

Still I am not sure if this is intended by the dev because I am not sure about the value of currentUInts256[key] and pendingUInts256[key]. If these two are high enough to match totalLpPoolWeight, it could bring currentRate to be in a reasonable level.

Proof Of Concepts

*totalLpPoolWeight should initially be zero.

[danhper]

totalLpPoolWeight is the sum of all currentUInts256[k], so this cannot underflow

[GalloDaSballo]

Dup of #172