[PROTOCOL] Delegated Minimum Deposit Adjustment Feature (DMDAF)

[ngmachado]

Overview

Introduce a Delegated Minimum Deposit Adjustment Feature (MDDAF) within our protocol. The purpose of this feature is to decentralize the process of setting minimum deposit requirements by delegating this authority to a whitelisted smart contract.

How?

1. Whitelisting Mechanism: A smart contract function will allow the whitelisting of addresses capable of proposing minimum deposit changes.
2. Proposal Delay: Each operation will incorporate a mandatory delay (default 24 hours) before it can be executed.
3. Execution Window: Post-delay, the execution function will be open to anyone, provided the proposal has not been revoked or overridden.
4. Community Proposal: Holders of project tokens will have the ability to propose their preferred minimum deposits, adhering to the delay process.
5. Delay Extension: Whitelisted accounts can request a delay extension to accommodate further discussion or alignment with other processes.
6. Proposal Revocation: Whitelisted accounts can revoke proposals during the delay period.
7. Governance Oversight: A multi-signature governance will retain the ability to override and remove proposals.

Operational Flow

The Solvency Committee will evaluate various factors, including solvency, profitability, risk, the TOGA health factor, and business considerations, to propose timely adjustments to the minimum deposit.

Monitoring and Communication

An off-chain monitoring system will track proposal status and send notifications via Slack to ensure team-wide visibility and discussion.

Execution Plan

Development and Testing
Peer Review and Revision
Deployment on Relevant networks
Monitoring System Integration
Documentation update
Formalize Operational Flow from Solvency Committee

Why?

The delegation system will streamline operations, reduce governance friction, and facilitate rapid, data-driven decision-making for non-critical governance parameters.

Deadline:

UI/UX Design:

Acceptance criteria

• Satisfies entire acceptance criteria
• Consider communication & visibility
• Code review is approved by at least 2 reviewers
• Tested by Elvijs/QA & discovered bugs resolved
• Documentation updated
• Assignee/opened by merges PR
• Automated E2E tests for happy path
• Code is merged
• Observability of critical user path
• Steps to access code change as a user

Links/Resources

• ...

Readiness criteria

• Descriptive title
• What?
• Why?
• How?
• Acceptance criteria complying with Definition of Done
• Estimate/Story points
• Deadline: If not a part of an epic
• Priority: Reflected as order on the bord, walking the board from the top and right
• Assignee
• Labels
• Link to epic: If belonging to an epic
• A task is always a separate ticket/issue
• UI/UX Design (optional)
• Blockers/Prerequisites (optional): Use Zenhub blocked by/blocking feature

[hellwolf]

Proposal Delay: Each operation will incorporate a mandatory delay (default 24 hours) before it can be executed.

It is important to note that, since this is a delay introduced by the delegated contract, the actual governance can always preempt and push through an expedient decision when needed without such delay.