For
voters leading to stuck reward in the Smart Contract.Description: When a vote reaches the quorom, the reward should be distributed amoung the For
voters. However, when we take a look over the distribution of the voters, we can see that it does not match the reward amount they should receive. This is due to a mis calculation of the reward by individus. To compute the reward to each individu, the smart contract take the total rewards, which is the balance of the smart contract and divide it by the total numbers of votes. However, we should used the total number of For
instead, else the totality of the reward will not be distributed.
Impact: The distribution of rewards is not valid, as a proportion is not distributed for the For
voters. Additionally, when a vote is terminated, tokens may be lost on the smart contract and no one can retrieve them.
Proof of Concept:
Place the following test into PuppyRaffleTest.t.sol
.
Recommended Mitigation:
Instead of using the total number of voters, it can be interesting to use the total of For
voters:
In line VotingBooth.sol:192
, we can change:
And we can also change line VotingBooth.sol:207
:
Also, defined what you intended by reward, is it the totality of the pool, as it is not a defined information, I suspect this could be something that wasn't thought of beforehand.
Consider using a specific version of Solidity in your contracts instead of a wide version. For example, instead of pragma solidity ^0.8.0;
, use pragma solidity 0.8.0;
Found in src/VotingBooth.sol Line: 2
Solc compiler version 0.8.20 switches the default target EVM version to Shanghai, which means that the generated bytecode will include PUSH0 opcodes. Be sure to select the appropriate EVM version in case you intend to deploy on a chain other than mainnet like L2 chains that may not support PUSH0, otherwise deployment of your contracts will fail.
Found in src/VotingBooth.sol Line: 2
VotingBooth.DISALLOWED
is never used in VotingBooth
.In the contract, the vote has a state called disallowed
. However, this state is never used in the code.
It seems this is a functionnality that is not intended to be use. If it is the case, I think it should be removed or implemented in the code.
Some of the variables could be defined as immutable as there are only defined in the constructor of the smart contract. We notice the following variables impacted: s_creator
and s_totalAllowedVoters
. Here is our recommendation:
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.