DOS attack by delegating tokens at MAX_DELEGATES = 1024. An attacker could deliberately delegate tokens to a victim's address to fill up their delegate array, making it impossible for the victim to perform essential operations.
Vulnerability Detail
In VotingEscrow.sol, the MAX_DELEGATES is set to 1024:
uint public constant MAX_DELEGATES = 1024;
Users can delegate their voting power to other addresses. The implementation maintains these delegations in an array, which has a maximum size defined by MAX_DELEGATES = 1024,
An attacker could exploit this by delegating tokens to a victim's address repeatedly until the victim's delegate array is full, thereby making it impossible for the victim to perform essential operations like transferring or withdrawing tokens due to the high gas costs exceeding the block limit.
We can see also that the protocol will be deployed on different L2 networks where there is less Block gas limit:
First on IOTA EVM, but the code was build with any EVM-compatible network in mind.
When the number of delegates reaches the MAX_DELEGATES limit (1024), operations like transfer, burn, or minting tokens become extremely expensive in terms of gas consumption. It's estimated that these operations could consume around 23 million gas, whereas the gas limit on the Optimism chain (Op-chain) is currently around 15 million gas.
Impact
When the delegate array reaches its maximum size (1024), any operation on the token (such as transfer, burn, or mint) becomes extremely expensive in terms of gas. Users who have a large number of delegates is unable to transfer or withdraw their tokens. This can cause significant inconvenience and potential financial loss.
An attacker could deliberately delegate tokens to a victim's address to fill up their delegate array, making it impossible for the victim to perform essential operations. This could be done maliciously to cause harm or to gain an advantage in voting or other governance mechanisms.
StraawHaat
High
DOS attack by delegating many tokens
Summary
DOS attack by delegating tokens at
MAX_DELEGATES = 1024
. An attacker could deliberately delegate tokens to a victim's address to fill up their delegate array, making it impossible for the victim to perform essential operations.Vulnerability Detail
In
VotingEscrow.sol
, theMAX_DELEGATES
is set to 1024:Users can delegate their voting power to other addresses. The implementation maintains these delegations in an array, which has a maximum size defined by
MAX_DELEGATES = 1024
,An attacker could exploit this by delegating tokens to a victim's address repeatedly until the victim's delegate array is full, thereby making it impossible for the victim to perform essential operations like transferring or withdrawing tokens due to the high gas costs exceeding the block limit.
We can see also that the protocol will be deployed on different L2 networks where there is less Block gas limit:
When the number of delegates reaches the
MAX_DELEGATES
limit (1024), operations like transfer, burn, or minting tokens become extremely expensive in terms of gas consumption. It's estimated that these operations could consume around 23 million gas, whereas the gas limit on the Optimism chain (Op-chain) is currently around 15 million gas.Impact
When the delegate array reaches its maximum size (1024), any operation on the token (such as transfer, burn, or mint) becomes extremely expensive in terms of gas. Users who have a large number of delegates is unable to transfer or withdraw their tokens. This can cause significant inconvenience and potential financial loss.
An attacker could deliberately delegate tokens to a victim's address to fill up their delegate array, making it impossible for the victim to perform essential operations. This could be done maliciously to cause harm or to gain an advantage in voting or other governance mechanisms.
Code Snippet
https://github.com/sherlock-audit/2024-06-velocimeter/blob/main/v4-contracts/contracts/VotingEscrow.sol#L1266
Tool used
Manual Review
Recommendation
The
MAX_DELEGATES
value can be set to a lower value.Duplicate of #26