The implementation of the staking function does not explicitly check if a stream is cancelled before processing the staking operation. This oversight could allow users to stake tokens from streams that have been cancelled, leading to financial losses or inconsistencies in the contract’s state.
Here is where the issue is located in the stakeVested function. The relevant code snippet is:
The function stakeVested is designed to allow users to stake tokens from Sablier streams. It performs several checks to validate the stream and process the staking operation. However, it currently lacks a crucial check for whether the stream is cancelled.
The function verifies that the sender of the steam is authorized and that the asset being staked is the correct type `fjordToken. and it calculates the available amount for staking by substracting withdrawn and refunded amounts from the deposited amount.If these checks pass, the function updates the user's data and processes the staking.
The vulnerability arises because the function does not check whether the stream identified by _streamID has been cancelled. This oversight means that if a stream is cancelled, it could still be processed for staking, leading to unauthorized staking,incorrect amount calaculation and state inconsistencies.
Here is how the issue can be reproduced:
Create a cancelled stream using the Sablier protocol.
Attempt to stake tokens from this cancelled stream using the stakeVested function.
Observe that the function processes the staking despite the stream being cancelled, indicating a lack of proper validation.
##Impact
The contract’s state could become inconsistent, potentially affecting reward distribution and overall contract integrity.
Manual
Add a check to verify if the stream is cancelled before processing staking operations.
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.