stake.link

Summary

This report identifies a potential issue in the condition checks of several contracts in the Stake-Link project. The contracts use the block.timestamp variable to compare with other variables that represent time durations or expiry dates. However, the condition checks do not account for the case when block.timestamp is equal to the compared variable, which could lead to unexpected or undesired outcomes. The report recommends adding an equal sign to the condition checks to make them more robust and accurate.

Vulnerability Details

The issue affects the following contracts and functions in the Stake-Link project:

https://github.com/Cyfrin/2023-12-stake-link/tree/main/contracts/core/sdlPool/SDLPoolPrimary.sol#L110

https://github.com/Cyfrin/2023-12-stake-link/tree/main/contracts/core/sdlPool/SDLPoolSecondary.sol#L185

https://github.com/Cyfrin/2023-12-stake-link/tree/main/contracts/core/sdlPool/SDLPoolSecondary.sol#L224

https://github.com/Cyfrin/2023-12-stake-link/tree/main/contracts/core/sdlPool/base/SDLPool.sol#L413

• SDLPoolPrimary: This contract is responsible for managing the primary pool of the Stake-Link token. The contract has a function called withdraw that allows users to withdraw their tokens after locking them for a certain period of time. The function has a condition check that requires the block.timestamp to be greater than the start time of the lock plus half of the duration of the lock. However, the condition check does not revert when block.timestamp is equal to the start time of the lock plus half of the duration of the lock, which could allow users to withdraw their tokens earlier than intended.

• SDLPoolSecondary: This contract is responsible for managing the secondary pool of the Stake-Link token. The contract has a function called withdraw that allows users to withdraw their tokens after locking them for a certain period of time. The function has two condition checks that require the block.timestamp to be greater than the start time of the lock plus half of the duration of the lock, and the expiry date of the lock. However, the condition checks do not revert when block.timestamp is equal to the start time of the lock plus half of the duration of the lock, or the expiry date of the lock, which could allow users to withdraw their tokens earlier than intended.

• SDLPool: This contract is an abstract contract that implements the base logic for the Stake-Link pool contracts. The contract has a function called lock that allows users to lock their tokens for a certain period of time. The function has a condition check that requires the block.timestamp to be less than the expiry date of the lock and the locking duration to be less than the duration of the lock. However, the condition check does not revert when block.timestamp is equal to the expiry date of the lock, which could allow users to lock their tokens for longer than intended.

Impact

The impact of this issue depends on the contract and the function that are affected. In general, the issue could affect the logic and the security of the contract functionality, and the incentives and the economics of the project. The issue could allow users to withdraw or lock their tokens earlier or later than intended, which could result in a loss of rewards or penalties for the users or the project.

Tools Used

Manul

Recommendations

The report recommends adding an equal sign to the condition checks that use the block.timestamp variable to compare with other variables that represent time durations or expiry dates. This would make the condition checks more robust and accurate, and prevent the issue from occurring. The report suggests modifying the following lines of code in the following contracts: