sherlock-audit / 2024-03-zap-protocol-judging

3 stars 1 forks source link

Varun_05 - UpdateVestingPoints should not be allowed because slightiest of error can cause some users to not claim their tokens #189

Closed sherlock-admin3 closed 7 months ago

sherlock-admin3 commented 7 months ago

Varun_05

high

UpdateVestingPoints should not be allowed because slightiest of error can cause some users to not claim their tokens

Summary

UpdateVestingPoints should not be allowed because slightiest of error can cause some users to not claim their tokens

Vulnerability Detail

Following is updateVestingPoints function

function updateVestingPoints(
        uint128[2][] memory _vestingPoints
    ) external onlyRole(DEFAULT_ADMIN_ROLE) {
        uint256 sum;
        (vestingPoints, sum) = ascendingSort(_vestingPoints);
        require(sum == 10000, "sum not 10000");
        require(block.timestamp <= _vestingPoints[0][0], "Time lapsed");
    }

From above when ascendingSort is called it only sorts the _vestingPoints[i][0] elements not the _vestingPoints[i][1] So if someone has claimed their token till vestingPoints.length - 2 index and has claimed 50% of the tokens and has only 50% tokens left to claim .Now if updateVesting points is called and makes the vestingPoints[vestingPoints.length - 1][1] = 6000(60%) then the user will be able to claim more tokens than 100% conversly if updateVestingPoints makes vestingPoints[vestingPoints.length - 1][1] = 40% then user will receive less tokens.

Impact

User may receive less or more tokens.It can also drain the contract and some users may not be able to claim their tokens.

Code Snippet

https://github.com/sherlock-audit/2024-03-zap-protocol/blob/main/zap-contracts-labs/contracts/Vesting.sol#L94

Tool used

Manual Review

Recommendation

Should not updateVesting if a user has started a claim before or maybe introduce a check for values of _vestingPoints[i][1] to be same as previous points.

Duplicate of #52

vsharma4394 commented 7 months ago

I have given correct reasoning why it should be a valid finding and a duplicate of #52

Hash01011122 commented 7 months ago

This is a valid duplicate of #52