Possible to create Stream with start and stop time in past
Summary
Possible to create Stream with start and stop time in past. In case if it was done by mistake then receiver will be able to receive all payment instantly and not wait vesting time.
function createStream(
address payer,
address recipient,
uint256 tokenAmount,
address tokenAddress,
uint256 startTime,
uint256 stopTime,
uint8 nonce
) public returns (address stream) {
// These input checks are here rather than in Stream because these parameters are written
// using clone-with-immutable-args, meaning they are already set when Stream is created and can't be
// verified there. The main benefit of this approach is significant gas savings.
if (payer == address(0)) revert PayerIsAddressZero();
if (recipient == address(0)) revert RecipientIsAddressZero();
if (tokenAmount == 0) revert TokenAmountIsZero();
if (stopTime <= startTime) revert DurationMustBePositive();
if (tokenAmount < stopTime - startTime) revert TokenAmountLessThanDuration();
stream = streamImplementation.cloneDeterministic(
encodeData(payer, recipient, tokenAmount, tokenAddress, startTime, stopTime),
salt(
msg.sender, payer, recipient, tokenAmount, tokenAddress, startTime, stopTime, nonce
)
);
IStream(stream).initialize();
emit StreamCreated(
msg.sender, payer, recipient, tokenAmount, tokenAddress, startTime, stopTime, stream
);
}
StreamFactory doesn't cheks that stopTime is after startTime, however it doesn't check if startTime is bigger than block.timestamp.
In case if StreamFactory.createStream was called with startTime and stopTime in the past by mistake, then receiver of payment will be able to claim all tokens instantly, avoiding vesting period.
Impact
Possible to create Stream with start and stop time in past, which allows to ignore vesting period
rvierdiiev
medium
Possible to create Stream with start and stop time in past
Summary
Possible to create Stream with start and stop time in past. In case if it was done by mistake then receiver will be able to receive all payment instantly and not wait vesting time.
Vulnerability Detail
https://github.com/sherlock-audit/2022-11-nounsdao/blob/main/src/StreamFactory.sol#L184-L213
StreamFactory doesn't cheks that stopTime is after startTime, however it doesn't check if startTime is bigger than block.timestamp. In case if StreamFactory.createStream was called with startTime and stopTime in the past by mistake, then receiver of payment will be able to claim all tokens instantly, avoiding vesting period.
Impact
Possible to create Stream with start and stop time in past, which allows to ignore vesting period
Code Snippet
https://github.com/sherlock-audit/2022-11-nounsdao/blob/main/src/StreamFactory.sol#L184-L213
Tool used
Manual Review
Recommendation
Check that startTime and stopTime are in future.
Duplicate of #66