Griefing an account from getting votes delegated to it
Vulnerability Detail
Assume there's three addresse's (Bob,Alex and Maya). Maya got 1e18 of bpt tokens which she locked in VotingEscrow contract and received a tokenId of the created veALCX. Maya is hoping to delegate her votes to Alex now. But Bob is a malicious actor, He locks 0.0000001 ether of bpt in the VotingEscrow contract 1024 times.Therefore bob recieves 1024 tokenId's for a total of 0.0001024 ether of bpt locked.
Now bob delegates his votes from each of his tokenId's to Alex,So alex got votes from 1024 tokenId's. So what bob have done here is a grief, If you look at line 1110 under _moveAllDelegates() internal function. There's a require condition that checks the total number of delegates the destioation(dst) has and if its <= MAX_DELEGATES which is 1024. So since bob delegated votes from 1024 tokenId's to Alex, When Maya tries to delegate votes from her tokenId that she received from locking 1e18, The delegation will revert as the require statement fails. So this is how bob griefed Alex from getting votes delegated to him. Basically bob used his 0.0001024*10**18 bpt total locked deposit to grief Alex, But bob can use any amount less than 0.0001024*10**18 bpt,I just used that in the test. Ofcourse Alex would be able to delegate and clear out the unworthy votes sent by bob,But Bob can do the griefing again.
Impact
A malicious actor can grief another address from getting votes delegated to it by maxing out the MAX_DELEGATES limit.
sonny2k
Medium
Griefing an account from getting votes delegated to it
Vulnerability Detail
Assume there's three addresse's (Bob,Alex and Maya). Maya got
1e18ofbpt tokenswhich she locked inVotingEscrowcontract and received a tokenId of the createdveALCX. Maya is hoping to delegate her votes to Alex now. But Bob is a malicious actor, He locks0.0000001 ether of bptin theVotingEscrowcontract 1024 times.Therefore bob recieves 1024 tokenId's for a total of0.0001024 ether of bptlocked.Now bob delegates his votes from each of his tokenId's to Alex,So alex got votes from 1024 tokenId's. So what bob have done here is a grief, If you look at line 1110 under
_moveAllDelegates()internal function. There's a require condition that checks the total number of delegates the destioation(dst) has and if its <=MAX_DELEGATESwhich is 1024. So since bob delegated votes from 1024 tokenId's to Alex, When Maya tries to delegate votes from her tokenId that she received from locking1e18, The delegation will revert as the require statement fails. So this is how bob griefed Alex from getting votes delegated to him. Basically bob used his0.0001024*10**18 bpttotal locked deposit to grief Alex, But bob can use any amount less than0.0001024*10**18 bpt,I just used that in the test. Ofcourse Alex would be able to delegate and clear out the unworthy votes sent by bob,But Bob can do the griefing again.Impact
A malicious actor can grief another address from getting votes delegated to it by maxing out the
MAX_DELEGATESlimit.Code Snippet
https://github.com/sherlock-audit/2024-06-velocimeter/blob/main/v4-contracts/contracts/VotingEscrow.sol#L1266
Tool used
Manual Review
References
This report is inspired by the report from Immunefi Alchemix Boost #30704
Duplicate of #26