Description
Summary
Within the Fluxora streaming contract, this work tightens externally visible assurances for one focused concern. Treasury operators, recipient-facing applications, and third-party auditors must be able to reason about this area using only on-chain observables and published protocol documentation—without inferring hidden rules from how the implementation happens to be structured. The scenarios captured by this issue title must therefore have crisp success semantics, crisp failure semantics, and no silent drift between stored state, user-visible errors, and emitted events. Authorization boundaries for this slice must be explicit: who may trigger each path, and what proof they must supply. In practical terms, treat “Negative tests: schedule mutations by recipient” as the scope boundary: everything materially related to that caption should be covered by evidence (automated or documented) in this change, and anything intentionally excluded should be called out with rationale and residual risk.
Issue caption: Negative tests: schedule mutations by recipient
Domain context
This repository hosts the Fluxora streaming contract on Soroban (Stellar). Streams lock funded assets in contract
storage, release entitlement over time according to schedule parameters (including cliffs), and expose explicit roles:
senders who fund and may adjust certain parameters, recipients who claim vested value, administrators who may intervene
under policy, and—where applicable—permissionless callers for maintenance reads or cleanup. Integrators (wallets,
indexers, treasury tooling) depend on coherent state transitions, emitted signals, and error behavior when inputs or
timing are invalid.
Work to complete
- Characterize the intended protocol semantics for Negative tests: schedule mutations by recipient in both success and failure cases, treating the Summary above as the authoritative scope statement.
- Map which roles may participate, what each role must prove, and which operations must be impossible for non-authorized actors.
- Enumerate edge cases driven by time (start, cliff, end, cancellation freeze), numeric ranges, and stream status combinations; capture expectations with tests or explicit audit exceptions.
- Ensure externally visible behavior—persistent fields, contract errors, and emitted payloads—does not contradict documentation that integrators rely on.
Definition of done
- An independent reader can confirm Negative tests: schedule mutations by recipient matches the stated intent using tests, traces, snapshots (where used), or written review notes.
- Documentation for this slice of the protocol is consistent with observable on-chain behavior after the change.
- The pull request explains verification performed, scope boundaries, and any residual assumptions or risks.
Constraints for contributors
- Describe outcomes, invariants, and evidence, not a single “right” internal design unless the issue title already names a concrete subsystem.
- Prefer observable guarantees: state transitions, balances, authorization failures, emitted events, error classifications, and documentation that integrators rely on.
- If something cannot be tested automatically, capture the gap as audit notes with explicit rationale and residual risk.
Requirements and context
- Must be secure, well-tested, and documented.
- Should be gas-conscious (Soroban budget) and easy to audit.
Suggested execution
- Fork the repo and create a branch:
git checkout -b feature/negative-schedule-auth
- Implement changes
- Contract / modules:
contracts/stream/src/lib.rs
- Comprehensive tests:
contracts/stream/src/test.rs and contracts/stream/tests/integration_suite.rs
- Documentation:
docs/ (e.g. streaming.md, security.md, events.md)
- Include Rust doc comments on public items (NatSpec-style clarity for auditors)
- Validate security assumptions (CEI ordering, token trust model, auth paths)
- Test and commit
- Run
cargo test in contracts/stream (and workspace if applicable)
- Cover edge cases (overflow, TTL, paused/cancelled/completed)
- Attach test output summary + security notes in the PR
Example commit message
test(stream): negative schedule mutation auth
Guidelines
- Aim for ≥95% coverage on touched Rust modules (
cargo llvm-cov or project-standard tooling).
- Clear documentation (protocol semantics + operator runbooks where relevant)
- Timeframe: 96 hours
Description
Summary
Within the Fluxora streaming contract, this work tightens externally visible assurances for one focused concern. Treasury operators, recipient-facing applications, and third-party auditors must be able to reason about this area using only on-chain observables and published protocol documentation—without inferring hidden rules from how the implementation happens to be structured. The scenarios captured by this issue title must therefore have crisp success semantics, crisp failure semantics, and no silent drift between stored state, user-visible errors, and emitted events. Authorization boundaries for this slice must be explicit: who may trigger each path, and what proof they must supply. In practical terms, treat “Negative tests: schedule mutations by recipient” as the scope boundary: everything materially related to that caption should be covered by evidence (automated or documented) in this change, and anything intentionally excluded should be called out with rationale and residual risk.
Issue caption: Negative tests: schedule mutations by recipient
Domain context
This repository hosts the Fluxora streaming contract on Soroban (Stellar). Streams lock funded assets in contract
storage, release entitlement over time according to schedule parameters (including cliffs), and expose explicit roles:
senders who fund and may adjust certain parameters, recipients who claim vested value, administrators who may intervene
under policy, and—where applicable—permissionless callers for maintenance reads or cleanup. Integrators (wallets,
indexers, treasury tooling) depend on coherent state transitions, emitted signals, and error behavior when inputs or
timing are invalid.
Work to complete
Definition of done
Constraints for contributors
Requirements and context
Suggested execution
contracts/stream/src/lib.rscontracts/stream/src/test.rsandcontracts/stream/tests/integration_suite.rsdocs/(e.g.streaming.md,security.md,events.md)cargo testincontracts/stream(and workspace if applicable)Example commit message
Guidelines
cargo llvm-covor project-standard tooling).