The Standard

Summary

Block increasePosition, decreasePosition or distributeAssets by having too much pending stake.

Vulnerability Details

When increasing the position, we add a pending stake object in the pendingStakes variables. A deadline of 1 day is defined to take into consideration the pending stake and to delete it from the pending list. This verification is done when we are calling some functions as increasePosition, decreasePosition or distributeAssets. Each time, we iterate over all the list element, to verify if we can delete the item or not. The main issue is when we have too much pending stakes waiting inside the pendingStakes. This lead to a significant increase of the gas used which can block users to interact with it as it could be impossible to be execute on chain.

Impact

Each time we add a new item in the pendingStakes by using for instance increasePosition() function, we increase the gas price that the user will have to use leading to a potential block of the request. This can block the access to increasePosition, decreasePosition or distributeAssets functions.

For instance, we have reproduce a small code that show the impact of increasing the gas:

• For 10 iterations : 397 956 gas

• For 100 iterations: 11 089 498 gas

=> We have multiple by 27.

An attacker can decide to add small liquidity just to block the functions to be use.

Tools Used

Manual review / Hardhat.

Recommendations

Have the possibility to run consolidatePendingStakes in a batch to avoid too much treatment when calling increasePosition, decreasePosition or distributeAssets functions.

Also, avoid iteration on all the pendingStakes variable when not necessary. Each time we add a new item in the list, it is order by timestamps. So we can break the loop when we do not match the deadline. See: