Core Contracts

Summary

The createVestingSchedule function allows the orchestrator to set the vesting schedule's start time to an arbitrary value without validation. This lack of constraints enables the orchestrator to manipulate the vesting timeline, potentially bypassing intended vesting cliffs or durations.

Vulnerability Details

In the createVestingSchedule function, the start time for the vesting schedule is set directly from an external parameter:

There is no validation to ensure that startTime is either in the future relative to the creation time or within an acceptable range. Consequently, an orchestrator (or an account with the ORCHESTRATOR_ROLE) can specify a start time in the past or at an arbitrary moment, which directly affects the calculations in the _calculateReleasableAmount function:

• If startTime is set far in the past, the beneficiary might immediately meet the vesting cliff (VESTING_CLIFF) and be able to release a large portion—or even all—of the tokens prematurely.

• Conversely, if startTime is set too far in the future, it may delay vesting beyond the intended schedule, unfairly locking tokens.

This flexibility undermines the predictability and security of the vesting mechanism.

Impact

• Premature Token Release: By setting startTime in the past, a malicious orchestrator could enable beneficiaries to release tokens earlier than intended, potentially compromising the vesting schedule and overall tokenomics.

• *isruption of Vesting Mechanics: Arbitrarily chosen start times can distort the intended vesting period, either accelerating or unnecessarily delaying token release, leading to potential disputes or financial imbalances.

• Loss of Trust: Inconsistent vesting behavior may erode stakeholder confidence in the protocol’s fairness and reliability, especially if vesting terms appear to be manipulated.

Tools Used

• Manual Code Review

Recommended Mitigation

• Validate startTime: Enforce constraints on the startTime parameter in the createVestingSchedule function. For example, require that startTime be no earlier than the current block timestamp or within a predefined acceptable window.

  Example:

  require(startTime >= block.timestamp, "Start time must be in the future");

• Standardize Vesting Start: Consider removing the external startTime parameter entirely and using a standardized start time (e.g., setting it to block.timestamp at schedule creation) to ensure consistent vesting behavior.