[FEAT] Implement Auto-Advancing Automated Payouts via Soroban Events

[Queenode]

🟡 Priority: High
Difficulty: Hard
Estimated Effort: 2-3 days
Relevant Files: contracts/src/lib.rs
Labels: enhancement, priority:high, integration

Requirements

1. Event-Driven Automation

   • The backend currently polls or relies on cron jobs to trigger payouts. The smart contract can emit highly specific events to tell off-chain indexers exactly when an automated action is required.

2. Rich Event Payloads

   • Enhance the contribute event to emit the current pool fullness status.
   • env.events().publish((symbol_short!("contrib"), member), (amount, current_cycle_contributions, is_pool_full));
   • If is_pool_full is true, this serves as a deterministic trigger for the backend to immediately construct and submit the payout() transaction, eliminating polling delays.

3. Cycle Reset Events

   • When payout() executes, if it was the last person in the cycle (based on Issue initialize does not require admin authorization — front-running attack possible #5), automatically emit a cycle_complete event.
   • env.events().publish((symbol_short!("cycle_done"), cycle_id), ());

4. Data Minimization

   • Ensure sensitive data (like the total group size or exact total balance) is only emitted if strictly necessary, to maintain some privacy on the public ledger. Use short symbols (Symbol::short("P_FULL")) to save byte space.

5. Testing

   • Unit test: Verify is_pool_full boolean is correctly calculated and emitted in the contribution event payload.
   • Unit test: Verify cycle_done event is emitted precisely on the final payout.
   • Target: >90% coverage on event emissions.

---

[OluRemiFour]

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

[Digitalasu]

Hi, I'd like to work on this issue. I've gone through the description and acceptance criteria and I'm confident I can deliver it. I'll make sure every acceptance criterion is met and submit a clean, tested PR. Please assign it to me.

[Cyber-Mitch]

Hi, I'd like to apply for this issue.
This is a good fit — I'm a Rust/Soroban engineer and security researcher, and event design on Soroban is a nicely bounded piece of work with real correctness stakes, since the backend is going to treat these events as authoritative triggers.
How I'd approach it:

Rich contribute payload — emit (amount, current_cycle_contributions, is_pool_full) so the backend has a deterministic signal instead of polling. The important detail is that is_pool_full is computed from the same state the payout path reads, so the trigger can never disagree with what payout() will actually accept.
cycle_done emission — fired precisely on the final payout of a cycle, not on every payout. I'd assert the exact boundary in tests, since an off-by-one here either drops a cycle reset or triggers one early.
Data minimization — keep group size and total balance off the ledger unless a consumer strictly needs them, and use short symbols (P_FULL) to stay compact on-chain.
Idempotency — worth confirming the backend can tolerate seeing the same trigger event twice (reorg or retry), since a duplicated payout() submission is the expensive failure mode. Happy to align on that in the PR.
Tests — unit coverage on the is_pool_full calculation and its emitted value, and on cycle_done firing exactly once at the cycle boundary, targeting >90% coverage on event emissions.

I'll complete the task within a day of assignment and open a PR early so you can review the event shapes before I finalize, since the backend contract depends on them.
Happy to adjust based on your priorities.

[Muhamadmust]

Hi maintainer
I have reviewed this issue and would love to work on it, PR 2days