[Feature] Implement multi-sig admin approval for high-risk pool actions (emergency_withdraw, pause, remove_member)

[Sendi0011]

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/multisig-admin-controls

---

Overview

All three pool contracts (Rotational, Target, Flexible) currently require only a single admin signature to execute high-risk actions: emergency_withdraw, pause/unpause, and remove_member. If an admin key is compromised or an admin acts maliciously, there is no check against draining or disrupting a pool holding real funds. The emergency pause infrastructure was added in #168, but it still relies on single-signer trust.

This issue adds a threshold-based multi-sig approval mechanism to these critical actions across all pool contracts, and builds the corresponding frontend UI for managing multi-sig admins and approving pending actions.

Requirements

Smart Contract Changes (all three pool contracts)

• Add a new storage key admin_quorum storing the set of designated multi-sig admins as a Vec<Address>
• Add a new storage key pending_approvals mapping a proposed action hash (Bytes) to the list of admins who have approved it
• Add new functions:
  • set_admin_quorum(admin, new_admins: Vec<Address>) — only callable by the current admin; sets the list of N admins
  • approve_action(admin, action_hash: Bytes) — records an admin's approval for a specific pending action
  • revoke_approval(admin, action_hash: Bytes) — removes an admin's approval before execution
  • execute_approved(action_hash: Bytes, action_data: Vec<u8>) — only succeeds if approvals count >= ceil(N/2) (simple majority), executes the action, then clears the pending record
• Modify emergency_withdraw, pause/unpause, and remove_member to be callable only via execute_approved when a quorum is configured (i.e., when admin_quorum length > 0); keep single-signer fallback when no quorum is set (for backward compatibility with existing single-admin pools)
• Add view functions: get_admin_quorum(), get_pending_action(action_hash), get_approval_count(action_hash)

Frontend Changes

• New component: AdminQuorumManager on the group detail page (admin-only section)
  • Display current quorum members with their Stellar addresses
  • Form to add/remove quorum members (subject to the contract's set_admin_quorum)
  • Show pending actions awaiting approval with an "Approve" button
  • Display approval progress (e.g., "2 of 3 approvals received")
• New component: PendingActionCard showing each pending multi-sig action with:
  • Action type and parameters (decoded from action_data)
  • List of admins who have approved/revoked
  • Expiry mechanism (pending actions older than 48 hours are automatically expired)
• Update existing admin action buttons (emergency_withdraw, pause, remove_member) to submit through the multi-sig flow when quorum is configured

Testing

• Unit tests for the new contract functions (approval counting, quorum threshold, backward compatibility)
• Integration test: create a pool with 3 admins, set quorum to 2, verify that single admin cannot execute; verify that 2-of-3 approval succeeds
• Frontend tests for AdminQuorumManager component rendering and interaction

Acceptance Criteria

• Setting a quorum disables single-signer execution for emergency_withdraw, pause/unpause, and remove_member
• Without a quorum configured, all actions work exactly as before (backward compatible)
• execute_approved only succeeds when the threshold is met
• Pending actions expire after 48 hours and cannot be executed
• Frontend AdminQuorumManager renders correctly for pools with and without a quorum
• Frontend correctly shows approval progress and prevents execution below threshold
• No existing functionality breaks — test the full deposit/withdraw/pause flow after applying changes

[mxrtins04]

Hi maintainer, can i be assigned this issue pleasee?

[mxrtins04]

Hi maintainer, can i be assigned this issue pleasee?

[sebas11042]

Hi, I’d like to work on this issue.

I’m interested in implementing the multi-signature workflow as a reusable and backward-compatible security layer across the Rotational, Target, and Flexible pool contracts. I would add quorum configuration, deterministic action hashing, approval and revocation tracking, threshold validation, expiry handling, and safe cleanup after execution.

I would also update the protected actions so existing single-admin pools continue working unchanged while quorum-enabled pools require the configured majority before execution. The tests would cover duplicate approvals, revocation, expired actions, unauthorized signers, threshold boundaries, replay prevention, and the complete 2-of-3 execution flow.

On the frontend, I would add the quorum management and pending-action interfaces, decode and display action intent clearly, show approval progress, and adapt the current emergency action controls to the multisig flow when enabled.

I’ll keep the implementation consistent across all three contracts, preserve the existing deposit and withdrawal behavior, and verify both contract and frontend regression suites.

Thanks!

[samjay8]

Hello Maintainer, good day, I have gone through the scope of this issue and I am sure of resolving the issue. Kindly assign to give the opportunity to be able to contibute to this project.

[Clement-coder]

Hi,

I’m a full-stack software and blockchain engineer with experience building scalable web apps, backend systems, and blockchain integrations.

I’d love to work on this issue. I’ve reviewed the requirements and have a clear implementation plan to deliver a clean, well-tested solution that meets all acceptance criteria and aligns with the project’s standards.

I can start immediately and provide timely updates throughout the implementation.

[Cyber-Mitch]

Hi, I'd like to apply for this issue.

This is a strong fit — I'm a smart contract security researcher, and threshold-based admin controls for high-risk actions on fund-holding contracts is exactly the kind of defense-in-depth I audit for. Getting the approval-counting and expiry logic exactly right is the real substance here.

A few things I'd treat as load-bearing:

action_hash binding — the hash needs to commit to the actual action_data, not just an action type label, so an approval for one withdrawal can't be replayed against different parameters (e.g. a different recipient or amount) once quorum is reached.
Backward-compat boundary — admin_quorum.len() > 0 gating single-signer fallback needs to be checked consistently across all three contracts and all three actions; I'd write a test matrix (3 actions × quorum-set/unset) rather than trust one code path covers all six.
Approval revocation and expiry interplay — an approval that's revoked, and a pending action that's expired, both need to leave pending_approvals in a clean state so a stale partial-approval set can't be resurrected later.
Quorum reconfiguration mid-flight — worth confirming what happens to pending approvals if set_admin_quorum changes N while an action is awaiting approval (should in-flight approvals from now-removed admins still count?). I'd flag this as a design decision in the PR rather than assume.

Sequencing: contract-side quorum storage, approve_action/revoke_approval/execute_approved, and the backward-compat matrix first, verified with the 3-admin/2-of-3 integration test — then the frontend AdminQuorumManager/PendingActionCard components and expiry UI on top of a working contract layer.

I'll complete the task within a day of assignment, and I'll open a draft PR early — once the contract-side approval/threshold logic and backward-compat tests are green — so the core mechanism gets review before the frontend lands.

Happy to adjust based on your priorities.

[Wetshakat]

Hi maintainer
I will like to work on this issue
ETA 3hrs

[grantfox-oss]

🦊 GrantFox — @Wetshakat 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 #181)
2. Your PR will be reviewed by the JointSave-org maintainers

Good luck! Track your progress on GrantFox.