The voting duration is one day and it should only occur once, as outlined in the documentation, but the protocol owner might accidentally or maliciously called MartenitsaVoting::startVoting
for more than one time, thus extending the voting period for more than one day.
There is no validation in MartenitsaVoting::startVoting
, allowing it to be called multiple times. If the protocol owner initiates voting at block.timestamp
, intending it to end at block.timestamp + 1 day
, a mistake or malicious action could occur if the function is called before the voting period ends. This would reset the voting period's end time to the current timestamp plus an additional day, effectively extending the voting duration. Furthermore, the protocol owner has the ability to initiate a new voting event, contrary to the documentation's intended specification that the voting should occur only once.
A simple proof-of-concept is as follows, add the test in MartenitsaVoting.t.sol
and run forge test —mt testVotingPeriodCanBeExtendedMoreThanOneDay
. The success indicate the voting period might exceed one day.
The extended voting period is different from the protocol's original intention, potentially giving users additional time to vote, this might result in unintended voting outcomes.
Manual Review, Foundry Test
To prevent the voting period being reset, validate the MartenitsaVoting::startVoting before updating the state variable.
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.