Closed code423n4 closed 2 years ago
Duplicate of #273
I don't think this is a dupe of #273 - but I also don't think its really medium severity either. The DOS attack is a separate problem, this warden is simply highlighting that two approved proposals can "fight" to become the next active proposal. While this is true, I am not sure why alone this is actually an attack vector if all else is functioning correctly in the governance process. The community would still have had to endorse them knowing that a vote on one could delay another.
Downgrading to QA, marking as dupe of wardens QA report #457
Lines of code
https://github.com/code-423n4/2022-08-olympus/blob/main/src/policies/Governance.sol#L205-L236
Vulnerability details
Impact
After two users' proposals receive enough endorsements, both users will call the following
activateProposal
function to activate their proposals. One user is incentivized to front-run the other user'sactivateProposal
call by providing a slightly higher gas fee for activating own proposal first without any delay. After a proposal becomes active, the other proposal must wait for theGRACE_PERIOD
time before it can be activated because only one proposal can be active at a time. After the front-running, the other user'sactivateProposal
call would revert with gas being wasted while she or he has to wait.https://github.com/code-423n4/2022-08-olympus/blob/main/src/policies/Governance.sol#L205-L236
Proof of Concept
Please append the following test in
src\test\policies\Governance.t.sol
. This test will pass to demonstrate the described scenario.Tools Used
VSCode
Recommended Mitigation Steps
Please consider supporting activation and voting for multiple proposals at a time. If this is not possible, please consider using flashbots for keeping users'
activateProposal
call transactions away from the mempool.