[FEAT] Implement Graceful Member Removal and Pro-Rata Refunds

[Queenode]

🔴 Priority: Critical
Difficulty: Hard
Estimated Effort: 3-4 days
Relevant Files: contracts/src/lib.rs, contracts/src/test.rs
Labels: enhancement, priority:critical, logic

Requirements

1. Remove Member Function

   • Implement pub fn remove_member(env: Env, member_to_remove: Address)
   • Only the Admin can call this function.
   • It must remove the member from the DataKey::Members vector.

2. Refund Logic

   • If the member is removed mid-cycle (i.e., they have HasContributedThisCycle == true but HasReceivedPayout == false), the contract must refund their current cycle contribution.
   • Check if the member has contributed this cycle.
   • If yes, read ContributionAmount and execute a token_client.transfer() sending the amount back to member_to_remove.
   • Clear HasContributedThisCycle(member) and HasReceivedPayout(member) from persistent storage to free up ledger space.

3. Cycle State Integrity

   • If a member is removed while a cycle is active (i.e., CycleMemberCount exists), the CycleMemberCount must be decremented by 1.
   • This ensures that the next payout() calculation (contribution_amount * cycle_member_count) remains mathematically correct for the reduced pool size.
   • If the removal drops the member count to 0, clear CycleMemberCount.

4. Constraints

   • A member cannot be removed if they have already received a payout in the current cycle (this would mean they take the money and leave others at a loss).
   • Panic with "Cannot remove member after payout" if HasReceivedPayout == true.

5. Testing

   • Unit test: Admin successfully removes a member who hasn't contributed yet.
   • Unit test: Admin removes a member who has contributed, verify the refund is processed.
   • Unit test: Admin attempts to remove a member who has received a payout (must panic).
   • Unit test: Verify CycleMemberCount adjusts correctly and subsequent payouts calculate the correct pool size.
   • Target: >90% coverage on removal logic.

---

[OpensrcLord]

Hello @maintainer, I understand the expected outcome and would love to work on this. I'll provide a solution that satisfies the acceptance criteria.

[OpensrcLord]

Hello @maintainer, I’ve gone through the requirements and I’m confident I can implement a proper solution that matches the acceptance criteria. Kindly assign this issue to me. And I will deliver at the shortest possible time.

[aristotle224]

I'd like to work on this issue because it implements a critical lifecycle operation that directly affects the fairness and financial integrity of the Ajo/Esusu contract. Member removal touches membership management, token transfers, and cycle accounting, so it's important that all state transitions remain consistent and that no participant is disadvantaged by a mid-cycle exit.

My approach would be to implement a dedicated remove_member function restricted to the contract administrator, ensuring the target member is removed only after passing all protocol invariants. Before modifying any state, I'd verify that the member has not already received a payout during the current cycle. If they have, the transaction would fail with the specified error, preventing a participant from exiting after benefiting from the current round.

For members removed before receiving a payout, I'd determine whether they have already contributed in the current cycle. If so, I'd execute the refund through the existing token client, return the current cycle contribution, and then clear the member's cycle-specific state (HasContributedThisCycle and HasReceivedPayout) to reclaim ledger space. The member would then be removed from the membership collection while ensuring the contract remains internally consistent.

I'd also update the active cycle accounting by decrementing CycleMemberCount whenever a member leaves during an active cycle, clearing it entirely if the final member is removed. This ensures future payout calculations continue to reflect the actual number of participating members and prevents overestimating the required pool size after membership changes.

Finally, I'd add comprehensive unit tests covering successful removal before contribution, removal with a contribution refund, rejection after payout, and verification that CycleMemberCount and subsequent payout calculations remain correct after membership changes. After implementation, I'd run the full contract test suite to ensure the new functionality integrates cleanly and achieves the requested coverage target without introducing regressions.

[shepherd-001]

Hello, I've reviewed the issue and am confident in resolving it. Please assign the task to me.