app/create/page.tsx's zod schema (line 27) is:
durationSeconds: z.coerce.number().min(3600, 'Minimum 1 hour'),
There's a minimum (1 hour) but no maximum. A user can type an arbitrarily large number of seconds — there's no client-side guard preventing, say, a multi-million-year duration. endTime = startTime + data.durationSeconds is computed with plain JS number arithmetic and then passed to nativeToScVal(args.endTime, { type: 'u64' }) in lib/factory.ts's createStream() with no range check either. While a u64 technically has room for very large values, there's no product-level reason a stream duration should be unbounded, and an accidental extra digit (e.g. typing 25920000 instead of 2592000) currently has no client-side guard catching an obviously-wrong value before the user signs a transaction for it. Suggest adding a sane .max() (e.g. a few years in seconds) with a clear error message, mirroring the existing wouldRateTruncateToZero guard that already protects against the too-small end of the range.
app/create/page.tsx's zod schema (line 27) is:There's a minimum (1 hour) but no maximum. A user can type an arbitrarily large number of seconds — there's no client-side guard preventing, say, a multi-million-year duration.
endTime = startTime + data.durationSecondsis computed with plain JS number arithmetic and then passed tonativeToScVal(args.endTime, { type: 'u64' })inlib/factory.ts'screateStream()with no range check either. While a u64 technically has room for very large values, there's no product-level reason a stream duration should be unbounded, and an accidental extra digit (e.g. typing25920000instead of2592000) currently has no client-side guard catching an obviously-wrong value before the user signs a transaction for it. Suggest adding a sane.max()(e.g. a few years in seconds) with a clear error message, mirroring the existingwouldRateTruncateToZeroguard that already protects against the too-small end of the range.