First Flight #6: Voting Booth
First Flight #6
Beginner FriendlyFoundry
100 EXP
View results
Previous Next
Submission Details
Severity: high
Valid

`rewardPerVoter` is computed divided by the total voters but distributed only to votedFor, locking the remaining funds in the contract

f3d0ss

Summary

The code contains a discrepancy in the reward distribution logic within the contract. The variable rewardPerVoter is calculated based on the total rewards divided by the total votes, yet it's solely distributed among those who voted for a proposal, excluding those who voted against it. Consequently, this mismatch in calculation and distribution leads to an accumulation of unallocated funds within the contract.

Vulnerability Details

The vulnerability lies in the disparity between the computation of rewardPerVoter and its allocation. The code computes the reward per voter based on the total rewards divided by the total votes, including both votes for and against a proposal. However, it only distributes this reward to the voters who supported the proposal, leaving out those who voted against it. This inconsistency results in unassigned funds that remain locked within the contract after the voting cycle.
The following test will fail proving the problem:

function test_wrongDistribution() public {
address[] memory voters = new address[](5);
voters[0] = address(0x9);
voters[1] = address(0x1);
voters[2] = address(0x2);
voters[3] = address(0x3);
voters[4] = address(0x4);
​
deal(address(this), ETH_REWARD);
booth = new VotingBooth{value: ETH_REWARD}(voters);
​
vm.prank(address(0x1));
booth.vote(true);
​
vm.prank(address(0x2));
booth.vote(true);
​
vm.prank(address(0x3));
booth.vote(false);
​
assert(!booth.isActive());
assertEq(address(booth).balance, 0);
}

Impact

Misaligned reward distribution permanently locks funds within the contract. These inaccessible funds, intended for all voters, remain immobilized as they're only distributed to supporting voters. This immobilization limits financial flexibility and fair distribution, necessitating resolution for better fund utilization and equitable rewards.

Tools Used

Testing with foundry

Recommendations

One of the following:

  1. Refine Reward Distribution Logic: Refactor the reward distribution mechanism to accurately allocate funds exclusively among voters who supported the proposal. This adjustment ensures that the distribution process aligns with the computed rewardPerVoter specifically for supporting voters, maintaining fairness and transparency within the voting system.

else {
- uint256 rewardPerVoter = totalRewards / totalVotes;
+ uint256 rewardPerVoter = totalRewards / totalVotesFor;
​
for (uint256 i; i < totalVotesFor; ++i) {
// proposal creator is trusted when creating allowed list of voters,
// findings related to gas griefing attacks or sending eth
// to an address reverting thereby stopping the reward payouts are
// invalid. Yes pull is to be preferred to push but this
// has not been implemented in this simplified version to
// reduce complexity & help you focus on finding the
// harder to find bug
​
// if at the last voter round up to avoid leaving dust; this means that
// the last voter can get 1 wei more than the rest - this is not
// a valid finding, it is simply how we deal with imperfect division
if (i == totalVotesFor - 1) {
- rewardPerVoter = Math.mulDiv(totalRewards, 1, totalVotes, Math.Rounding.Ceil);
+ rewardPerVoter = Math.mulDiv(totalRewards, 1, totalVotesFor, Math.Rounding.Ceil);
}
_sendEth(s_votersFor[i], rewardPerVoter);
}
}

  1. Refund Unallocated Funds: Implement a process to refund the unassigned funds within the contract to the proposer. This action rectifies the discrepancy and prevents the accumulation of unused funds.

Updates

Lead Judging Commences

0xnevi Lead Judge over 1 year ago
Submission Judgement Published
Validated
Assigned finding tags:

VotingBooth._distributeRewards(): Incorrect computation of rewardPerVoter

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.