Flow

Summary

Reorgs could cause senders to update the RPS on an incorrect stream, leading to accruing debt faster/slower than intended.

Calling depositAndPause() may deposit on the wrong stream when a reorg occurs.

Vulnerability Details

Adjusting the RPS for a stream only requires the streamId, if a reorg occurs, the streamId for the stream where the RPS is intended to be changed may be different.

• For example, if the same sender creates two streams contigously, the stream Ids are assigned as follows:

  • streamId: 10 | receiver: alice

  • streamId: 11 | receiver bob

• A reorg occurs and the stream Ids end up as follows:

  • streamId: 10 | receiver: bob

  • streamId: 11 | receiver alice

• If the sender intends to update the RPS for the stream of alice, sender sends a tx to update RPS for streamId: 10, but a reorg occurs, and when the tx is executed, the RPS will be actually updated for the stream of bob.

The same concern applies for the void(), refund() && pause(), but, the one that may be impacted the most is depositAndPause().

• If a reorg occurs when calling depositAndPause(), the deposit may be made on the wrong stream. Following the example for adjusting RPS, if the sender intended to deposit on the stream of alice, after the reorg, the deposit would be made on the stream of bob.

Submitting this as a low since it does not really leads to a loss of funds, the only difference is how fast/slow the debt would be accrued, plus, this action can be corrected once the sender realizes the RPS was updated for the wrong stream.

• Also, for the depositAndPause(), the sender can recover the funds by calling the refund(). Since sender was the depositor, those funds are not lost, therefore, a low sev seems reasonable.

Impact

Reorgs could cause senders to update the RPS on an incorrect stream, or end up causing deposits to be made on the wrong stream.

Tools Used

Manual Audit

Recommendations

SablierFlow.adjustRatePerSecond()

• For the depositAndPause(), apply the above fix too.