[FEAT] Implement Flexible Cycle Configurations (Goal-Based Savings)

[Queenode]

🟡 Priority: High
Difficulty: Hard
Estimated Effort: 4-5 days
Relevant Files: contracts/src/lib.rs
Labels: enhancement, priority:high, feature

Requirements

1. Multiple Group Types

   • The current contract assumes strict Ajo/Esusu (rotational payout). Kolo backend PRD mentions goal-based savings.
   • Add an enum GroupType with variants Rotational and GoalBased.
   • Pass group_type to initialize() and store it in instance data.

2. Goal-Based Logic

   • If GoalBased:
     • There is no single payout to one member per cycle.
     • Members contribute towards a personal or group goal.
     • Add a TargetAmount parameter during initialization.
     • Members can withdraw their own accumulated contributions at any time, OR only when the target date/amount is reached (configurable).

3. Refactoring State

   • Rotational specific state (HasReceivedPayout, CycleMemberCount) should only be checked and updated if GroupType == Rotational.
   • GoalBased groups need a new withdrawal function: pub fn withdraw_savings(env: Env, member: Address, amount: i128).
   • Ensure withdraw_savings checks that the member actually has amount available in their Contributions balance.

4. Hybrid Validation

   • contribute() behavior remains mostly the same, but GoalBased groups might not enforce a strict identical ContributionAmount (allow flexible deposits).
   • If GoalBased, skip the amount != expected_amount check.

5. Testing

   • Unit test: Initialize as GoalBased, member deposits varying amounts, member withdraws partial amount.
   • Unit test: Initialize as Rotational, ensure strict exact-amount deposits and rotational payouts still function as before.
   • Unit test: GoalBased member tries to withdraw more than they deposited (panics).
   • Target: >85% coverage across both group types.

---

[OluRemiFour]

Hi Maintainer,
Interested in working on this issue. I'll implement the requested changes and ensure everything is properly tested before submission.

[OluRemiFour]

Hi Maintainer,
Interested in working on this issue. I'll implement the requested changes and ensure everything is properly tested before submission.

[Ultra-Tech-code]

hello, I'd like to work on this issue.

I'll extend the contract to support both Rotational and GoalBased savings groups by introducing a GroupType enum and persisting the selected group type during initialization. I'll refactor the contract so rotational-specific logic is executed only for rotational groups while implementing the goal-based savings flow, including configurable target amounts, flexible contribution amounts, and a withdraw_savings function with proper balance validation.

I'll ensure the existing rotational behavior remains unchanged, add comprehensive tests covering both group types (including partial withdrawals, flexible deposits, and over-withdrawal failures), and verify the implementation maintains backward compatibility while achieving the requested test coverage.

[JesseJohn7]

Hello, 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.

[grantfox-oss]

🦊 GrantFox — @Ultra-Tech-code has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

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

Good luck! Track your progress on GrantFox.