maintenance-pool::sweep's recipient parameter is never validated against the contract's own address

[abayomicornelius]

Overview

sweep (contracts/maintenance-pool/src/lib.rs:332-367) transfers any surplus balance to an admin-supplied recipient: Address with no check that recipient != env.current_contract_address(). This is the same category of gap already-open issue #44 flags for withdraw's recipient parameter, but #44's title and body are scoped specifically to withdraw — sweep is a distinct function (added later, for #39) that has the identical unvalidated-recipient shape and isn't covered by #44's scope.

If an admin (accidentally, or via a compromised/buggy off-chain tool) passes the contract's own address as recipient, the resulting transfer is a self-transfer: surplus is computed correctly, but no funds actually leave the contract, silently masking what should have been a successful sweep. Low severity (admin-gated, no fund loss), but a real, concrete correctness gap distinct from #44.

Requirements

Add a check in sweep rejecting recipient == env.current_contract_address(), following whatever pattern is chosen to fix #44 for withdraw, for consistency.

Acceptance Criteria

• sweep rejects a self-referential recipient
• A regression test added
• cargo test --workspace passes

Additional Notes

Verified via direct inspection of contracts/maintenance-pool/src/lib.rs:332-367 (no recipient validation against the contract's own address). Cross-reference: #44 (open, same category, scoped to withdraw only).

[shadrach68]

Hi Maintainer,
I'd like to take on this issue. I've reviewed the requirements, understand the scope, and can deliver a tested solution that aligns with the project's standards.

Thanks.

[rupesh-kumar-sah]

Hello team,

I would like to resolve this issue. Here is my proposed execution plan:

• Implementation: Implement maintenance-pool::sweep's recipient parameter is never validated against the contract's own address with explicit require_auth checks, secure state storage, and gas optimization.
• Testing: Ensure contract compiles cleanly and passes all cargo tests without warnings.

Happy to pick this up today—please assign to me!

[Stephan-Thomas]

@Stephan-Thomas has applied to work on this issue as part of the Stellar Wave Program's 9th wave.

hi, i would like to work on this.

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

[Ghost1290-star]

@Ghost1290-star has applied to work on this issue as part of the Stellar Wave Program's 9th wave.

Hi Maintainer, I’ve gone through the issue and understand the validation gap in "sweep". I’d like to add the recipient check using the same approach as the related "withdraw" fix, add a regression test for the self-referential case, and make sure the workspace tests continue to pass.

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

[damilare0813]

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

Hello maintainer, I would like to work on #730 via Stellar Drips Wave.

I will add tests for backend startup behavior as described and ensure tests pass.

This is my first Wave contribution, I can start now and open PR within 2 days.

Please assign me. Thanks!

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

[toroabduljalalyakubu]

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

Hello, I would like to work on this Issue. I believe I should be able to deliver on time. Thank you.

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

[DooseWayo]

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

Can I work on this task?

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

[Agbasimere]

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

Could you please assign?

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

[drips-wave]

Congratulations, @DooseWayo! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on September 30, 2026.

🧑‍💻 @DooseWayo: 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 🌊

[drips-wave]

This issue has been completed by @DooseWayo as part of the Stellar Wave Program's 9th Wave 🥳

😎 @DooseWayo: You earned 200 Points for completing this issue! After the current Wave ends, you'll be eligible for a percentage of the Wave's reward pool based on the percentage of total points you've earned. Learn more here. You can also Leave a review to share your experience working on this issue.

🧑‍💻 Repo maintainers: How'd the contributor do? Leave a review to share your experience working with them.

[rushikeshgarad2024-dev]

Resolved in PR #435 (#435).

Added guard in maintenance-pool::sweep returning Error::InvalidTreasury when recipient matches the contract's own address, and added unit regression test test_sweep_rejects_self_referential_recipient.

Stellar Payout Address: GC5U46IS25KYFKNHDXEHR3KTQB3DVIBM4NW5BH4MVUE2G77STCJP4IHF