novaman33 - _unlockOperators can manipulate votes

[sherlock-admin2]

novaman33

High

_unlockOperators can manipulate votes

Summary

In the MlumStaking.sol unlock operators have the right to unlock a position anytime. This gives them the right to create serious manipulation of the vote.

Vulnerability Detail

The vote function only checks if the vote duration for the current position and the initial lock duration are over the minimum to vote. However this is not enough as unlock operators can create multiple positions vote and than withdraw.
Consider the following scenario:

1. Vote has started. An unlock operator creates a position and votes.
2. Then they withdraw and create position again and vote again.

Impact

_unlockOperators will cause huge vote manipulation and also cut other user's rewards - High

Code Snippet

https://github.com/sherlock-audit/2024-06-magicsea/blob/42e799446595c542eff9519353d3becc50cdba63/magicsea-staking/src/Voter.sol#L172

Tool used

Manual Review

Recommendation

Do not allow positions that were just created to vote. Create a delay so that they can vote starting next voting period.

[0xSmartContract]

After a thorough review, it has been determined that this issue represents a centralization risk rather than a vulnerability in the smart contract itself. The ability for _unlockOperators to manipulate votes hinges on the centralized control these operators have. Such risks are inherent in systems where centralized entities have significant control, and mitigating these risks often involves governance and oversight mechanisms rather than technical fixes.

This issue is categorized as a centralization risk, which should be managed through governance and oversight, not as a technical vulnerability. Therefore, it is marked as invalid.