user loses tokens in partial withdrawals.
function withdraw(uint256[] calldata _withdrawalIds, uint256[] calldata _batchIds) external {
address owner = msg.sender;
uint256 amountToWithdraw;
The issue of incomplete withdrawal processing occurs in the section I've highlighted above. Let's break it down:
The function iterates through the queuedWithdrawals
array.
When it encounters a withdrawal where sharesRemaining < sharesToWithdraw
, it does the following:
Reduces sharesToWithdraw
by sharesRemaining
Continues to the next iteration of the loop without processing the current withdrawal
This approach is problematic for several reasons:
The current withdrawal is not processed at all. The function doesn't update the withdrawal record or transfer any tokens to the user.
The sharesRemaining
for this withdrawal are effectively "lost" in the system. They're subtracted from sharesToWithdraw
, but not accounted for anywhere else.
The user who requested this withdrawal will never receive their funds through this mechanism.
User loses their tokens
Manual review
We process every withdrawal we encounter, whether it's smaller than, equal to, or larger than sharesToWithdraw
.
For withdrawals smaller than or equal to sharesToWithdraw
, we process them fully.
For withdrawals larger than sharesToWithdraw
, we process them partially.
We keep track of sharesToWithdraw
and stop when we've processed all requested shares.
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.