Add Multi-Signature Approval for Configuration Changes

[Jagadeeshftw]

Description:

Require M-of-N multi-signature approval for critical configuration changes (e.g. fee rate, treasury address, pause) in addition to or instead of single admin, reducing single point of failure.

Requirements and context:

• Config changes can have large impact
• Multisig aligns with security best practices for high-value deployments
• Should integrate with existing proposal/approval patterns where present
• Component locations:
  • Config and admin modules
  • Proposal storage and execution

Suggested execution:

1. Fork the repo and create a branch

   git checkout -b feat/multisig-config-changes

2. Implement changes

   • Add propose_config_change(change_payload) and approve_config_change(proposal_id)
   • Store proposals and approvals; execute when threshold reached
   • Support configurable signer set and threshold
   • Emit events for propose, approve, execute, and cancel

3. Test and commit

   • Add tests for threshold, rejection, and expiry
   • Document multisig config flow in PR

Example commit message:

feat: add multi-signature approval for configuration changes

Guidelines:

• Assignment required before starting
• PR description must include: Closes #[issue_id]

[midenotch]

@midenotch has applied to work on this issue as part of the Stellar Wave Program's 2nd wave.

Please, kindly assign this to me - i can work on it

ℹ️ Repo Maintainers: To accept this application, review their application or assign @midenotch to this issue.

[DokaIzk]

@DokaIzk has applied to work on this issue as part of the Stellar Wave Program's 2nd wave.

Gm gm can I be assigned this?

ℹ️ Repo Maintainers: To accept this application, review their application or assign @DokaIzk to this issue.

[drips-wave]

This issue has been added to the Stellar Wave Program and is worth 200 Points.

🧑‍💻 Interested in contributing? Apply to work on this issue on Drips Wave, earn points, and receive rewards.

Warning

Only applications submitted via the apply link above will be considered. Please do not apply by commenting on the issue or opening a PR directly.

🤠 Repo maintainers: You can manage this issue's Points and Complexity on your Maintainer Dashboard here. Please keep an eye on applications and respond quickly 💙

ℹ️ Learn more about Drips Wave

[Josetic224]

@Josetic224 has applied to work on this issue as part of the Stellar Wave Program's 3rd wave.

This is a critical security upgrade. Moving from a single-point-of-failure admin to an M-of-N multisig for config changes is exactly how high-value protocols should be governed. I’m comfortable with the state management required to track these proposals without bloating the contract.

My implementation plan:

Proposal Lifecycle: I’ll implement a ConfigProposal struct in storage to track the payload, proposer, and a bitset or vector of approvals. I'll make sure proposals have an expiry (TTL) so stale changes can't be executed months later.

Threshold Logic: I’ll build the approve_config_change function to trigger execution automatically once the M threshold is met. This avoids a separate "execute" transaction and saves on gas/compute.

Signer Management: I'll ensure the signer_set itself can only be modified via the multisig process, preventing a rogue admin from swapping out the other N-1 signers.

Atomic Updates: For critical changes like fee_rate or treasury_address, I’ll ensure the state update is atomic and emits a ConfigExecution event with both the old and new values for easy indexing.

Testing: I’ll write a test suite covering:

Reaching the exact threshold (M/N).

Unauthorized accounts trying to "approve."

Attempting to execute an expired proposal.

Handling a "threshold change" mid-proposal.

I can get the core modules and the state transition logic drafted and tested within a few days. Can you assign this to me?

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Josetic224 to this issue.

[Jayrodri088]

@Jayrodri088 has applied to work on this issue as part of the Stellar Wave Program's 3rd wave.

I’ll implement an M‑of‑N multisig flow for critical configuration changes by introducing proposal and approval logic that wraps existing admin operations instead of relying on a single key. I’ll add propose_config_change(change_payload) to register a config proposal (fee rate, treasury address, pause state, etc.) and approve_config_change(proposal_id) to record individual signer approvals, tracking a configurable signer set and threshold so you can support common setups like 2‑of‑3 or 3‑of‑5, as recommended in multisig best practices. Once a proposal reaches the required number of unique approvals, the contract will execute the underlying config change atomically and emit an Executed event; proposals can also be canceled or expire, with Proposed, Approved, Executed, and Canceled/Expired events emitted for full on‑chain auditability.

I’ll integrate this into the existing config/admin modules and proposal storage so current governance patterns still work, but critical mutations now route through the multisig gate—either by replacing single‑admin calls or by requiring multisig approval in addition. The signer set and threshold will be configurable (but themselves changeable only via multisig), and I’ll add tests that cover happy paths, insufficient approvals, duplicate approvals, already‑executed proposals, and expiry/rejection to ensure there are no privilege escalation holes. Finally, I’ll document the multisig config flow in the PR (including example M‑of‑N setups and operational guidance) so reviewers and operators can adopt it confidently. ETA: 10–12 hours for implementation, tests, and documentation.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Jayrodri088 to this issue.

[drips-wave]

Congratulations, @Josetic224! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on March 30, 2026.

🧑‍💻 @Josetic224: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊