Governance

OpenMoney protocol is controlled by OpenMoney DAO which is governed by holders of OMGT — governance token of the OpenMoney DAO. DAO itself is based on Tally.

Initial distribution of OMGT token will be made via private sale. On a later stages it will be distributed publicly.

OMGT token holders control the following aspects of protocol:

• Smart contracts upgrades
• OUSG yield distribution
• Minimum issuance and redemption request amounts
• Other protocol parameters

Parameters

Parameter	Description	Initial Value
Proposal threshold	Minimum amount of OMGT required to submit a proposal	1000 OMGT
Quorum needed	Percentage OMGT total voting power required for proposal to be accepted and executed	30%
Proposal delay	Delay period between proposal submission and voting start	1 hour
Voting period	Legth of a timeframe dedicated for OMGT holders to cast their vote	24 hours
Execution delay	Delay period between proposal queued for execition and execution itself	1 hour

Proposal Process

The governance process of the protocol is designed to ensure that all changes and decisions are made transparently and democratically. The process involves several key steps, from holding governance tokens to the execution or rejection of proposals. Below is a detailed breakdown of each step in the governance process.

Step 1: Holding Governance Tokens

• 1.1 Obtain Tokens: To participate in the governance process, individuals must first hold OMGT.

Step 2: Delegating Tokens

• 2.1 Delegation: OMGT holders have the right to delegate their voting power. Delegation does not transfer token ownership it grants another address the right to vote on the holder's behalf.
• 2.2 Choosing a Delegate: Delegates can be anyone - a trusted community member, smart contract or a token holder himself.

Step 3: Submitting a Proposal

• 3.1 Proposal Requirements: To submit a proposal, a delegate must meet the minimum token threshold required for proposal submission. This threshold minimizes spam and ensures that proposals are submitted by stakeholders with a significant interest in the protocol.
• 3.2 Drafting the Proposal: Proposals should clearly outline the changes or actions to be voted on. Thisƒ includes modifications to the FinanceHub smart contract or other protocol parameters.
• 3.3 Proposal Submission: Once a proposal meets the requirements, it is submitted to the governance portal for community review.

Step 4: Voting on Proposals

• 4.1 Delay: After a proposal is submitted, a proposal delay period begins. During this period, community members can discuss the proposal and raise any concerns.
• 4.2 Opening the Vote After the delay period ends, a voting period begins. During this period, token holders can cast their vote for or against the proposal.
• 4.3 Casting a Vote: Voters can cast their vote directly or through their delegate, depending on their delegation choice: For, Against or Abstain.

Step 5: Proposal Threshold

• 5.1 Quorum: For a vote to be valid, a minimum percentage of total voting power must participate in the vote, known as the quorum. Voting power equals the total number of delegated OMGT tokens.
• 5.2 Majority: A proposal is approved if it receives a majority of the votes cast, excluding abstentions.

Step 6: Queue and Timelock Controller

• 6.1 Role of Timelock Controller: The Timelock Controller is a smart contract that enforces a delay between the block at which proposals have been queued for execution and their execution. This delay provides a window for the community to consider implications of the proposal, prepare for any changes or even put another proposal to cancel this one if Execution Delay period is long enough.

Step 7: Execution of Proposals

• 7.1 Successful Proposals: If a proposal is approved and survives the timelock delay without challenge, it is executed.
• 7.2 Execution Process: The execution is handled through the Timelock Controller, which interacts with the FinanceHub smart contract to implement the approved changes.

Step 8: Rejection or Failure

• 8.1 Rejection: Proposals can be rejected by a majority vote or if the quorum is not met.
• 8.2 Failure to Execute: If a proposal is approved but fails to execute (e.g., due to technical issues), it may be reconsidered or abandoned based on the governance framework.