Enabling rails to start from some future timestamp

[lordshashank]

It would be good improvement to enable starting rails from some future timestamp rather than current.
Currently modifyRailPayment when called would start vesting funds on per epoch basis from the timestamp when the function was called with non-zero newRate, this prompts user to call the function exactly at the instant from which he wants to start payments. Ideally it would be good to have generic function where one can specify the epoch from which he wants the payment to get vested, which can even be block.timestamp which would then represent the current implementation.

Generic use-cases:
lets say a grant aggrement is signed between entities with specific starting date in future. The funder would be able to configure the payment before hand to start vesting from some particular epoch rather than waiting until that and calling the function exactly at start epoch.

Filecoin use-case:

• it can help in pre-funding storage deal with some future activation epochs with rail being registered on-chain giving guarantee to SP of payments and he can onboard data before the activation epoch.
• With DDO, as we don't have notifications yet that would callback to contracts at the time sector is on-boarded which can start the rail, this would enable the rail creation while allocation is made with vesting scheduled at some future time which could then be validated/arbitrated if the SP actually on-boarded data or not.

[Chaitu-Tatipamula]

I would like to work on this.

Thought of, Implementing a flexible system that allows specifying a future start epoch for rail payments, both during rail creation and when modifying payments. This will enable users to configure payment schedules in advance without needing to execute transactions at specific times.

Design

1. Rail Creation

• Add optional startEpoch parameter to createRail
• If startEpoch is 0, rail starts vesting immediately
• If startEpoch is non-zero, it must be in the future
• Emit RailCreated event with startEpoch for transparency

2. Rail Payment Modification

• Add optional startEpoch parameter to modifyRailPayment
• Allow scheduling future payment starts at any time
• Maintain existing rate change and one-time payment functionality
• Emit RailPaymentModified event with startEpoch for tracking

3. Rail Settlement Logic

• Respect startEpoch in settlement calculations
• No settlements before startEpoch
• Maintain existing settlement behavior after startEpoch
• Integrate with rate change queue system

4. Security Considerations

• Validate startEpoch is not in the past
• Ensure proper access controls for modifying start epochs
• Maintain existing security model for settlements
• Prevent manipulation of payment schedules

5. Event Tracking

• Track start epoch changes through events

[aarshkshah1992]

@rjan90 This is nice to have but I would like to do this after M2 as it will need some careful thought and review because it will change some of the core accounting logic in the contract and none of the Synapse work is blocked on this yet, so changing the milestone to Mx.