The createVestingSchedule
function allows the startTime
to be set to a date earlier than the current block timestamp. This enables creating vesting schedules that are already partially or fully vested upon creation, potentially allowing beneficiaries to claim tokens immediately.
The current implementation does not validate the startTime
:
Loss of intended time-locking mechanism, undermining vesting integrity.
Potential financial risks if large token allocations become instantly available.
Unfair advantage to malicious orchestrators who can backdate vesting schedules.
Manual code review.
Add a validation check to ensure the startTime
is not in the past:
This enforces that vesting schedules can only start at the current or future timestamps, preserving their intended function.
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.