The startTime parameter in the createVestingSchedule function is not validated, allowing the creation of vesting schedules with invalid or malicious startTime values. This could lead to:
Vesting schedules starting in the past: Tokens could become immediately claimable, bypassing the intended vesting period.
The createVestingSchedule function does not validate the startTime parameter. Specifically:
There is no check to ensure startTime is in the future (i.e., startTime > block.timestamp).
The issue requires the caller to intentionally or accidentally provide an invalid startTime.
Since the function is restricted to ORCHESTRATOR_ROLE, the likelihood of exploitation depends on the trustworthiness of the role holder.
However, mistakes in setting startTime (e.g., using a past timestamp) are plausible.
Manual Review
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.