The President-Elector smart contract is vulnerable to hitting the block gas limit, which could prevent the selection of a new president. This vulnerability is primarily due to unbounded loops in the selectPresident
and _selectPresidentRecursive
functions, which iterate over all voters and candidates, despite the number of candidates being capped at 10.
The vulnerability stems from two main issues:
The selectPresident
function iterates over all voters and their ranked candidates (up to 10).
The _selectPresidentRecursive
function performs multiple nested loops over all voters and candidates (up to 10) in each round of the selection process.
As the number of voters increases, the gas consumption of these functions grows linearly, potentially exceeding the block gas limit.
Consider a scenario with a large number of voters (e.g., 10,000) and the maximum number of candidates (10). The selectPresident
function would need to iterate 10,000 * 10 = 100,000 times in the worst case. Subsequently, _selectPresidentRecursive
would need to perform this operation multiple times, once for each round of elimination (up to 9 times with 10 candidates).
With a large number of voters, even though candidates are capped at 10, these nested loops could still exceed the block gas limit, making it impossible to select a new president.
The impact of this vulnerability is significant:
It could prevent the selection of a new president, effectively freezing the governance process.
It makes the contract unusable as the number of voters increases, even with the candidate limit of 10.
It could lead to centralization risks if only entities with high gas limits (like certain MEV bots) can execute the function.
Manual review
Implement a phased voting system where vote counting is done in batches.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.