Flow

Summary

The Sablier FlowStream doesn't have a continuous streaming nature when streaming a low decimal token. Rather, it has a discrete streaming nature. This simply means that there are some points in time when no token will be accrued. Knowing this, plus the fact that the protocol allows any random address to call the withdraw function, can cause an annoying delay in withdrawing the recipient's desired amount from the stream whenever the sender streams a high-value token with low decimal and very low rps

Vulnerability Details

The Sablier Protocol explains how a Sablier Flowstream will become a discrete function of funds instead of a continuous function of funds with respect to time in this doc https://github.com/sablier-labs/flow/blob/b01cc2daf6493ae792a858d6179facc6250403e2/TECHNICAL-DOC.md particularly in the Delay due to Descaling (unlock interval) section of the docs. The fact that a Sablier Flowstream becomes a discrete stream instead of a continuous stream when a sender is streaming a low decimal token, plus the fact that the protocol allows any address to call the withdrawfunction on the Sablier Flowcontract on behalf of the recipient, creates a room where if anyone for any reason is interested in delaying the recipient from getting their desired amount from the stream at the appropriate time they can easily do that.

The below is a test to show the discrete behavior of the Sablier Flowstream when streaming a very low decimal token at a very low rps.copy the below test and paste it in withdrawDelay.t.solyou will find it inside the concretefolder that is inside the integrationfolder which is inside the testfolder.

Run the test with forge test --mt test_withdraw_Unbearable -vvvvcommand and you will get the below output showing the discrete behavior of the stream

From the test output above, we can clearly see how discrete the stream is. The stream was only able to accrue 1 wei of the token it is streaming after one week of actively streaming, and it was only able to accrue 2 wei of the token it is streaming after one week and five days of actively streaming. Now that we have seen how much delay there can be for a low decimal and low rps stream to increase its accrued amount from 1 wei to 2 wei, I think it is time to understand the vulnerability I am pointing out. If, for any reason, there is anyone who does not want the recipient of this stream to receive the 2 wei from the stream at a week and five days of the stream actively streaming, they just need to call the withdraw function on the SablierFlowcontract at a week and four days of streaming, and that will withdraw only 1 wei to the recipient who has been waiting all along to withdraw their 2 wei the next day. This will be really annoying and frustrating to the recipient. You can argue that the user doesn't lose any funds and can still withdraw another 1 wei to complete the 2 wei, and that is correct, but the problem is the recipient will now have to wait for a whole week to get the 1 wei which they would have gotten the next day if no one had called the withdraw function on the SablierFlowcontract on their behalf.

Impact

This vulnerability leads to the recipient having to wait unnecessarily to withdraw their desired amount from the stream.

Tools Used

Manual Review

Recommendations

The protocol should restrict the withdrawfunction to the recipient and the sender as those are the people who have a trust base relationship, and we can assume that the sender will not do anything to harm the recipient, but we can't assume that any random address will not do anything to harm the recipient.