[Feature] Add self-service "leave pool" function for non-admin members

[grantfox-oss]

Getting Started

1. Fork the repository: https://github.com/JointSave-org/Joint_Save
2. Clone your fork:

   git clone https://github.com/<your-username>/Joint_Save.git
   cd Joint_Save

3. Create a new branch:

   git checkout -b feat/self-service-leave-pool

---

Overview

Checked all three pool contracts and confirmed remove_member exists everywhere, but always requires admin.require_auth() — there's no equivalent function a regular member can call themselves to leave a pool. Right now, the only way to exit a pool is to ask the admin to remove you, which is awkward and puts unnecessary friction (and unnecessary trust) on a basic, expected action.

Requirements

Smart Contract Changes (all three pool types)

• Add a leave_pool(env: Env, member: Address) function, requiring member.require_auth() (the member authorizes themselves, no admin involved)
• For Rotational: should follow the same round-shifting logic already used by remove_member (don't duplicate the math — consider extracting a shared internal helper both functions call)
• For Target: should only be allowed before the pool is unlocked, consistent with the existing remove_member restriction
• For Flexible: should refund the member's balance, same as remove_member
• Consider whether the current beneficiary in a Rotational pool should be allowed to leave mid-round, or whether that needs a restriction (discuss in the PR if you think a guard is needed)

Frontend Changes

• Add a "Leave Pool" button in group-actions.tsx, visible only to non-admin members (i.e. hidden for the pool's own creator/admin, who should use a different flow if they want to step back)
• Confirmation dialog before leaving, warning about any consequences (e.g. losing your spot in a rotational pool's order)

Acceptance Criteria

• A non-admin member can call leave_pool and successfully exit without any admin involvement
• Rotational round-shifting logic stays correct after a self-initiated leave (reuse/extract shared logic with remove_member rather than re-implementing it)
• Flexible pool members are correctly refunded on leave
• Frontend button only shows for non-admins
• Unit tests covering the leave flow for all three pool types

[Ayodaviduiux]

hey assign to me?
I'd like to work on the self-service leave pool feature.
I can implement the leave_pool function in the contracts and add the frontend button with confirmation. Can submit a PR in hours once approved.

[JuliobaCR]

Hello! I would like to work on this issue.

Estimated Time: 1-2 days

Problem

Currently, only the pool administrator can remove members from a pool. This creates unnecessary friction because members cannot voluntarily leave on their own and must rely on the admin for a basic action. It also introduces unnecessary trust requirements and reduces the overall usability of the application.

Proposed Solution

I will implement a self-service leave_pool function for all three pool contract types while keeping the existing behavior and business rules consistent.

My implementation will include:

• Adding a leave_pool(env: Env, member: Address) function that requires member.require_auth() so members can authorize their own departure.
• Refactoring the Rotational pool logic to reuse the existing member removal and round-shifting behavior through a shared internal helper instead of duplicating code.
• Preserving the existing restriction for Target pools by allowing members to leave only before the pool is unlocked.
• Refunding member balances in Flexible pools using the same logic currently used by remove_member.
• Evaluating whether the current beneficiary in a Rotational pool should be allowed to leave mid-round and documenting the reasoning in the PR if an additional safeguard is appropriate.
• Updating the frontend by adding a Leave Pool button that is only visible to non-admin members, along with a confirmation dialog explaining the consequences of leaving.
• Writing comprehensive unit tests covering the leave flow for all three pool types.

Experience

I have experience working with Rust, smart contract development, frontend integration, and open-source contributions. I prioritize clean, maintainable code, avoid logic duplication through refactoring where appropriate, and ensure new features are well tested before submission.

I would be happy to take ownership of this issue and deliver a complete implementation that satisfies all acceptance criteria.

[davieslennox0]

Not here to motivate, need a solution, assign to me.

[grantfox-oss]

🦊 GrantFox — @davieslennox0 has been assigned to this issue as part of the Official Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #140)
2. Your PR will be reviewed by the JointSave-org maintainers

Good luck! Track your progress on GrantFox.

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox as part of the Official Campaign campaign!

@davieslennox0's PR #162 was approved and merged by @Sendi0011.

🏆 @davieslennox0: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (48 total points). Track your full progress on GrantFox.

👏 Great work, @davieslennox0! Keep contributing to JointSave-org.