Add contract test: create_streams_batch() rejects a batch entry whose recipient is the contract itself

[Austinaminu2]

Description

`test_security.rs` has `test_recipient_is_contract_rejected` for the single `create_stream` path, but no equivalent test exists for the identical guard in `create_streams_batch()` (`lib.rs:550-552`).

Task

Add a batch-create test with one entry whose recipient is the contract address itself, asserting the batch is rejected the same way the single-stream path is.

Good for contributors because

Mirrors an existing, well-understood single-stream test — mostly a matter of adapting it to the batch API.

[adewaleomolara522-coder]

@adewaleomolara522-coder has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hi Maintainer, I understand the problem and am confident I can provide a high quality fix, kindly assign this issue to me thanks

ℹ️ Repo Maintainers: To accept this application, review their application or assign @adewaleomolara522-coder to this issue.

[soma-enyi]

@soma-enyi has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hi team, I'd like to work on this issue. I'm a full-stack developer experienced in TypeScript, Rust, and smart contract development across EVM and Soroban/Stellar ecosystems. I've built and shipped production systems covering backend APIs, frontend interfaces (Next.js, React), CI/CD pipelines, and onchain protocols — so I'm comfortable working across whatever layer this issue touches. My approach I'll start by reproducing the issue locally and reading the surrounding code to understand context and constraints. I'll scope the fix tightly to avoid unnecessary churn, write or update tests to cover the change, and make sure linting, formatting, and existing CI checks all pass before opening a PR. If anything in the issue is ambiguous, I'll flag it early rather than guess. What you can expect A single clean PR with a clear description linking back to this issue. Minimal, well-tested changes that follow the project's existing conventions. Fast turnaround — I'm available to start immediately and responsive to review feedback. Happy to discuss the approach further if needed. Looking forward to contributing.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @soma-enyi to this issue.

[escaprt]

@escaprt has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

I’d like to work on Issue #659 because the single-stream creation path already verifies that the contract cannot be used as a stream recipient, but the equivalent batch path does not have regression coverage.

I will first review test_security.rs, especially test_recipient_is_contract_rejected, and inspect the create_streams_batch() implementation around the existing recipient validation.

I will then add a focused batch-create test with one entry whose recipient is the contract's own address. The test will assert that the entire batch is rejected with the same error behavior as the single create_stream() path.

I will keep the test structure closely aligned with the existing security test so it remains easy to understand and consistent with the project's testing conventions. No changes to the contract logic should be necessary unless the new test reveals that the batch guard behaves differently from the single-stream guard.

I will also make sure the test uses the existing contract test setup and remains deterministic, without introducing new fixtures or dependencies.

Finally, I will run the relevant contract security tests and build checks to confirm the new regression test passes and that the existing stream-creation behavior remains unchanged.

My goal is to ensure the security rule protecting the contract from being used as a recipient is enforced and tested consistently across both single and batch stream creation.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @escaprt to this issue.

[drips-wave]

Congratulations, @soma-enyi! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on August 31, 2026.

🧑‍💻 @soma-enyi: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊