A critical bug has been identified in the rewards distribution logic of the smart contract. The issue arises when the proposal is approved, and rewards are intended to be distributed among the "for" voters. However, the current implementation incorrectly uses the total number of voters (both "for" and "against") as the denominator in the reward calculation, leading to improper distribution and potential fund locking within the contract.
The issue is located in the distributeRewards
function within the smart contract.
The rewards distribution logic incorrectly calculates the denominator for the reward distribution. Instead of considering only the "for" voters, it uses the total number of voters (both "for" and "against"). This leads to a situation where the rewards are distributed among a larger group than intended, causing incorrect fund allocation.
The impact of this vulnerability is severe. It results in an incorrect distribution of rewards, causing funds to be allocated to a larger group of voters than intended. This can lead to fund locking within the contract and potential financial losses for users.
Copy the below test and add it in VotingBoothTest.t.sol
run this command forge test --match-test testVotePassesAndMoneyIsNotSentToAllVoters -vvvv
you will get the below result
Result:
Test Code:
Manual review + Fuzzing via foundry.
Update distributeRewards Function: Modify the distributeRewards
function to correctly calculate the total number of "for" voters and use this value as the denominator in the reward distribution calculation.
Also remove the round up check, if this is NOT removed the last voter might receive less reward than others.
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.