The bug here is that the function doesn't properly handle the case where the _to token has a longer lock time than the _from token.
It correctly calculates the new end time as the maximum of the two lock end times.
However, when calling _deposit_for, it uses value0 (the amount from the _from token) and end (the new end time), but it doesn't adjust the amount based on the potentially extended lock time.
This could lead to an unfair advantage where a user could merge a token with a shorter lock time into one with a longer lock time, effectively increasing their voting power without extending the lock on the merged-in tokens.
Minato7namikazi
High
unhandled missed case in merge function
Vulnerability Detail
The bug here is that the function doesn't properly handle the case where the
_to
token has a longer lock time than the_from
token._deposit_for
, it usesvalue0
(the amount from the_from
token) andend
(the new end time), but it doesn't adjust the amount based on the potentially extended lock time.This could lead to an unfair advantage where a user could merge a token with a shorter lock time into one with a longer lock time, effectively increasing their voting power without extending the lock on the merged-in tokens.
Code Snippet
https://github.com/sherlock-audit/2024-06-velocimeter/blob/main/v4-contracts/contracts/VotingEscrow.sol#L1195
Tool used
Manual Review