The withdrawalBatchIdCutoff
value is incorrectly updated in the WithdrawalPool::updateWithdrawalBatchIdCutoff()
function, leading to potential discrepancies in tracking completed withdrawal batches.
As shown in the following code snippet, when the @>1
code line is established and the loop is jumped out, the @>2
code line will not be executed. At this time, the value of newWithdrawalBatchIdCutoff
is actually equal to i - 1
. According to the function annotation, newWithdrawalBatchIdCutoff -> withdrawalBatchIdCutoff
should point to the next batch index after all withdrawal requests have been fully completed, so the value of this index should be i
.
In the current implementation of the WithdrawalPool::updateWithdrawalBatchIdCutoff()
function, as highlighted in the code snippet below, when the condition at line @>1
is met and the loop is exited, the code at line @>2
is not executed. This results in newWithdrawalBatchIdCutoff retaining the value of i - 1
instead of i
. According to the function's documentation, newWithdrawalBatchIdCutoff
(which is eventually assigned to withdrawalBatchIdCutoff
) should point to the batch index where all withdrawal requests have been fully processed. Therefore, the value of newWithdrawalBatchIdCutoff
should be updated to i
before breaking the loop.
This issue causes the withdrawalBatchIdCutoff
to be updated incorrectly, leading to an inaccurate representation of the last fully completed withdrawal batch. If not addressed, this could affect the efficiency and correctness of withdrawal data, potentially impacting the proper tracking of withdrawal batches and the return of outdated batch data.
Manual Review
To ensure newWithdrawalBatchIdCutoff
correctly reflects the batch where all withdrawals have been completed, update its value to i
before breaking the loop, as shown in the proposed code modification below:
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.