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.