Inefficient Cooldown Process Due to userLastStakeTime Not Being Updated in unstake Function
Summary
Vulnerability Detail
In the StakingRewardsV2 contract, the userLastStakeTime is updated in the _stakeEscrow function but not in the unstake function. This design requires users to stake tokens to initiate the 7-day cooldown period before they can unstake their tokens. This approach is inefficient and user-unfriendly, as it forces users to perform an additional staking operation just to start the cooldown period for unstaking.
Updating userLastStakeTime in the unstake function would streamline the process, allowing users to directly initiate the cooldown period when they intend to unstake their tokens, thereby improving the overall user experience and efficiency of the protocol.
Example Scenario
Current Process:
User stakes tokens, and userLastStakeTime is set to the current block timestamp.
User's userLastStakeTime is now T1.
User wants to unstake tokens but must wait for the 7-day cooldown period.
User stakes additional tokens to reset userLastStakeTime and start the cooldown period.
User's userLastStakeTime is now T2.
After 7 days from T2, the user can unstake tokens.
Proposed Process:
User stakes tokens, and userLastStakeTime is set to the current block timestamp.
User's userLastStakeTime is now T1.
User wants to unstake tokens and initiates the unstake operation.
userLastStakeTime is updated to the current block timestamp during unstaking.
User's userLastStakeTime is now T2.
After 7 days from T2, the user can unstake tokens without needing an additional staking operation.
Impact
Updating userLastStakeTime during unstaking allows users to directly initiate the cooldown period when they intend to unstake their tokens. This eliminates the need for an additional staking operation just to start the cooldown period.
AresAudits
Medium
Inefficient
CooldownProcess Due touserLastStakeTimeNot Being Updated inunstakeFunctionSummary
Vulnerability Detail
In the
StakingRewardsV2contract, theuserLastStakeTimeis updated in the_stakeEscrowfunction but not in theunstakefunction. This design requires users to stake tokens to initiate the 7-day cooldown period before they can unstake their tokens. This approach is inefficient and user-unfriendly, as it forces users to perform an additional staking operation just to start the cooldown period for unstaking.Updating
userLastStakeTimein theunstakefunction would streamline the process, allowing users to directly initiate the cooldown period when they intend to unstake their tokens, thereby improving the overall user experience and efficiency of the protocol.Example Scenario
userLastStakeTimeis set to the current block timestamp.userLastStakeTimeis nowT1.userLastStakeTimeand start the cooldown period.userLastStakeTimeis nowT2.T2, the user can unstake tokens.userLastStakeTimeis set to the current block timestamp.userLastStakeTimeis nowT1.userLastStakeTimeis updated to the current block timestamp during unstaking.userLastStakeTimeis nowT2.T2, the user can unstake tokens without needing an additional staking operation.Impact
Updating
userLastStakeTimeduring unstaking allows users to directly initiate the cooldown period when they intend to unstake their tokens. This eliminates the need for an additional staking operation just to start the cooldown period.Code Snippet
https://github.com/sherlock-audit/2024-07-kwenta-staking-contracts/blob/0527fb7425206a3338c23177416436c6286cedf9/token/contracts/StakingRewardsV2.sol#L252C5-L271C6
Tool used
Manual Review
Recommendation