Stream factory does not have enough validations for time settings to prevent accidental lock of tokens.
Vulnerability Detail
When creating a stream, the user can choose any startTime and stopTime as long as these conditions are met:
if (stopTime <= startTime) revert DurationMustBePositive();
if (tokenAmount < stopTime - startTime) revert TokenAmountLessThanDuration();
It does not validate that the duration is not absurdly long, e.g. 100 years, or that the end timestamp is not too far in the future, e.g. year 2100. I believe the protocol should be robust enough to save users from such mistakes. For example, a maximum duration could be 4 years, and the max end time could be now +5 years or something like that.
Impact
If a stream is created with an impractical duration or stop time, and then funded with some tokens, these tokens will be inaccessible unless the stream is canceled by the payer.
HonorLt
medium
Max duration and end time
Summary
Stream factory does not have enough validations for time settings to prevent accidental lock of tokens.
Vulnerability Detail
When creating a stream, the user can choose any
startTime
andstopTime
as long as these conditions are met:It does not validate that the duration is not absurdly long, e.g. 100 years, or that the end timestamp is not too far in the future, e.g. year 2100. I believe the protocol should be robust enough to save users from such mistakes. For example, a maximum duration could be 4 years, and the max end time could be now +5 years or something like that.
Impact
If a stream is created with an impractical duration or stop time, and then funded with some tokens, these tokens will be inaccessible unless the stream is canceled by the payer.
Code Snippet
https://github.com/nounsDAO/streamer/blob/master/src/StreamFactory.sol#L199-L200
Tool used
Manual Review
Recommendation
Consider introducing reasonable maximum duration and stop-time limits.