Each swap request should be assigned a unique requestId, incrementing sequentially per user.
This ensures that swapRequests[user][requestId] references a distinct swap, even when multiple swaps are initiated in the same transaction. This is not done in the code as can be seen below.
Inside the loop of initiateSwap, the requestId for each swap in the batch is fetched by:
The nextId function does not increment on retrieval. The nextId returns the current ID without incrementing, all swaps in the batch receive the same requestId.
Example: First swap gets requestId=5, the second also gets requestId=5 in the same transaction.**** All swaps in the batch clobber the same swapRequests[user][5] entry, leaving only the last swap’s details.
Another Example:
User calls initiateSwap with 3 swaps (vaultIds.length=3).
Current nextId=5 for the user.
First Loop (i=0):
nextId returns 5, assigns requestId=5.
Sets swapRequests[user][5] = SwapRequest_1.
Second Loop (i=1):
nextId still returns 5 (not incremented).
Overwrites swapRequests[user][5] = SwapRequest_2.
Third Loop (i=2):
Same requestId=5. Overwrites to SwapRequest_3.
Result:
Only SwapRequest_3 is stored. SwapRequest_1 and SwapRequest_2 are permanently lost.
Users lose USD tokens for the first two swaps, as no entries exist to refund or fulfill them.
Users cannot refund/fulfill any swap except the last one, leading to permanent loss of funds.
Manual Review
Increment nextId Appropriately: Modify nextId to auto-increment per user on retrieval
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.