Problem
Neither create_stream nor create_streams_batch (contracts/streaming/src/lib.rs:387-632) validates that start_time (or cliff_time) is >= now. There's no test covering this case.
Impact
A sender can backdate start_time (and/or cliff_time) into the past so that a large chunk of the deposit unlocks immediately upon creation, bypassing the vesting UX entirely. For payroll/grant/vesting use cases — the contract's stated purpose — this defeats the whole point of "unlocks continuously by the second," and could be used to mislead a recipient about the vesting schedule they're agreeing to (e.g. a UI showing a multi-year vest that's actually mostly unlocked on day one).
Suggested fix
Add a check in create_stream/create_streams_batch that rejects start_time < ledger_timestamp() (and/or cliff_time < start_time), returning a typed StreamError. Add tests covering backdated start_time and backdated cliff_time.
Location
contracts/streaming/src/lib.rs:387-632 (create_stream, create_streams_batch)
Problem
Neither
create_streamnorcreate_streams_batch(contracts/streaming/src/lib.rs:387-632) validates thatstart_time(orcliff_time) is>= now. There's no test covering this case.Impact
A sender can backdate
start_time(and/orcliff_time) into the past so that a large chunk of the deposit unlocks immediately upon creation, bypassing the vesting UX entirely. For payroll/grant/vesting use cases — the contract's stated purpose — this defeats the whole point of "unlocks continuously by the second," and could be used to mislead a recipient about the vesting schedule they're agreeing to (e.g. a UI showing a multi-year vest that's actually mostly unlocked on day one).Suggested fix
Add a check in
create_stream/create_streams_batchthat rejectsstart_time < ledger_timestamp()(and/orcliff_time < start_time), returning a typedStreamError. Add tests covering backdatedstart_timeand backdatedcliff_time.Location
contracts/streaming/src/lib.rs:387-632(create_stream,create_streams_batch)