The _queueProposal
function incorrectly reverts with ProposalAlreadyExecuted
when the operation is pending (i.e., isOperationPending(id)
returns true
). This is backward logic because the operation is not executed yet—it is only pending. The error message is also misleading, as it suggests the proposal has already been executed when it has not.
The isOperationPending
function in the timelock contract returns true
if the operation is pending (i.e., op.timestamp != 0 && !op.executed
). This means the operation has been scheduled but not yet executed.
In _queueProposal
, the following condition is used:
If isOperationPending(id)
returns true
, the operation is pending (not executed), but the code reverts with ProposalAlreadyExecuted
.
This is incorrect because the operation is not executed yet—it is only pending.
The intended behavior should be to revert if the operation is already executed (i.e., op.executed = true
), not if it is pending.
This issue arises due to a misunderstanding of the isOperationPending
function's behavior and a mismatch between the condition and the error message.
The function reverts when it should not revert, preventing valid proposals from being queued.
The misleading error message could confuse users and developers, making debugging and troubleshooting more difficult.
This could lead to proposals being stuck in an incorrect state, requiring manual intervention to resolve.
Manual Review
Reverse the condition to revert only if the operation is already executed (e.g., by checking isOperationReady
, isOperationDone
, or the executed
flag directly).
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.