Core Contracts

Summary

The createVestingSchedule function lacks validation to ensure that the provided startTime is greater than or equal to the current block timestamp (block.timestamp). This allows vesting schedules to start in the past, potentially disrupting the intended vesting logic.

Vulnerability Details

• There is no check to prevent setting startTime in the past.

• A beneficiary could receive tokens immediately if a past startTime is set, violating the intended vesting schedule.

• The issue can be exploited by setting startTime to a very old timestamp, effectively bypassing the vesting delay.

Impact

• Vesting schedules could start retroactively, leading to immediate or unintended token release.

• It could create discrepancies in token distributions and cause inconsistencies in the vesting logic.

• If the vesting mechanism assumes a future startTime, its functionality may be compromised.

Tools Used

• Manual code review

• Functional analysis

Recommendations

Add a validation check to ensure startTime is not in the past:

• Implement unit tests to verify that the function reverts when startTime is set in the past.

• Consider logging an event if an invalid startTime is attempted, to track incorrect input attempts.