nmfix(stream-manager): reject create-stream when rate-per-block would b…

[Sobilo34]

Independent review for StackStream Clarity contracts

Scope: stream-manager.clar, stream-factory.clar — authorization, arithmetic, state transitions, token handling, aligned with SECURITY_REVIEW.md v1.0.0-rc1.

Method: Manual trace of all public entry points; ran local simnet tests via npm install && npx vitest run (Vitest + Clarinet SDK).
Summary: I agree with the bulk of the author review: use of contract-caller for access control, token principal equality checks, ordering of SIP-010 transfers vs map updates on create/top-up, cancel fund split (recipient-amount + sender-refund vs escrow), pause/resume accounting, and factory track-stream requiring the caller to be the stream’s sender. I did not identify a critical vulnerability (e.g. arbitrary drain or principal spoofing) in this codebase under standard SIP-010 assumptions.

Finding non-zero rate-per-block invariant
The document states that rate-per-block cannot be zero given deposit > 0 and duration > 0. With Clarity integer division, rate-per-block = floor((deposit * PRECISION) / duration) is zero whenever deposit * PRECISION < duration. Effects: no accrual for the recipient; top-up-stream divides by rate and fails for those streams. Funds are recoverable by the sender via cancel-stream, so this is not a direct theft bug, but it is a real edge case and breaks an implied invariant.

Recommendation: Reject create-stream when (deposit-amount * PRECISION) < duration-blocks (equivalently require >= so the computed rate is at least 1). I implemented this guard and a regression test in my branch/PR: [link if applicable].
Residual notes: Operator must protect CONTRACT-OWNER; emergency pause scope matches code. Third-party token behavior remains a deployment/integration risk.

Closes #1

[vercel]

@Sobilo34 is attempting to deploy a commit to the dev_jaytee's projects Team on Vercel.

A member of the Team first needs to authorize it.