veRWA - sl1's results

Lines of code

https://github.com/code-423n4/2023-08-verwa/blob/a693b4db05b9e202816346a6f9cada94f28a2698/src/VotingEscrow.sol#L185-L218 https://github.com/code-423n4/2023-08-verwa/blob/a693b4db05b9e202816346a6f9cada94f28a2698/src/GaugeController.sol#L69-L83 https://github.com/code-423n4/2023-08-verwa/blob/a693b4db05b9e202816346a6f9cada94f28a2698/src/GaugeController.sol#L95-L109 https://github.com/code-423n4/2023-08-verwa/blob/a693b4db05b9e202816346a6f9cada94f28a2698/src/GaugeController.sol#L247-L249

Vulnerability details

Impact

VotingEscrow.sol and GaugeController.sol rely on several loops that can loop for hundred of times while being costly in terms of gas consumption.

for (uint256 i = 0; i < 255; i++) {

for (uint256 i; i < 500; ++i) {

These loops are executed on every interaction with each of the smart contracts.

Moreover in GaugeController.sol there are two calls to two different loops in the same function vote_for_gauge_weights.

uint256 old_weight_bias = _get_weight(_gauge_addr);
uint256 old_weight_slope = points_weight[_gauge_addr][next_time].slope;
uint256 old_sum_bias = _get_sum();

In one single function call the smart contract is expected to iterate both of these loops with each loop having upper bound of 500 iterations. This approach is error-prone and if the number of periods is large, the contract is essentially deemed useless as his core-functionality will be broken. I consider this to be a Medium severity as assets are not at direct-risk but the core function of the protocol and it's availability could be impacted.

Tools Used

VS-Code/Manual Review

Recommended Mitigation Steps

The good approach could be allowing iteration over periods in mutliple transactions.

Assessed type

Loop