The smart contract manages a voting mechanism where a reward in ETH is distributed among voters based on the majority vote. When the majority votes "for," but there are individuals who voted against, the reward distribution is flawed. There's a miscalculation in the reward distribution logic that incorrectly divides the reward by the total number of votes instead of only among the voters who voted "for" the proposal.
The contract tracks voters who cast their votes "for" and "against" a proposal. Upon tallying the votes, it computes the total number of votes for and against the proposal, respectively. The issue arises during the distribution of rewards where it incorrectly divides the reward among all voters, but it only distributes the reward to the voters who voted "for." The flawed reward calculation and distribution logic are as follows:
The contract computes rewardPerVoter
based on the total number of votes (both "for" and "against"), yet it only sends rewards to the voters who voted "for." Consequently, it incorrectly divides the reward among all voters, leading to an incorrect distribution and loss of funds.
The flaw in the reward distribution logic results in an incorrect division of rewards among voters. Although the intention is to distribute rewards only among the voters who voted "for," the contract divides the reward among all voters, leading to an incorrect distribution of ETH rewards. This incorrect distribution causes an imbalance, leaving ETH locked in the contract indefinitely.
Add the test in the file: test/VotingBoothTest.t.sol
Run the test:
Foundry
Update the reward calculation logic
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.