Governance and Proposals

If you are reading this, you are aware that Money on Chain launched its governance token, MoC, a new step towards decentralization.

This is a very important milestone for the stablecoin project that’s creating a new open and uncensored financial system built on Bitcoin, as it means the community will begin to take part in the decision-making process.

You may be interested in: You may be interested in: MoC tokens explained

From now on, the community can make proposals and vote on them to make these decisions regarding parameter changes and new features. All the system parameters were chosen at platform inception under certain assumptions which were valid at that moment and for the near future. For example, the coverage parameter, the interest rate for leveraged positions, or percentages in fee distribution to stakeholders could be subject to modifications proposed by the community.

Also, the system will require upgrades to react to the growth of the ecosystem around it, and it must adapt to changes in the technical environment in which the MOC system is embedded.

To be able to deal with these situations the system must evolve, and governance is the tool to achieve this. On blockchains such as RSK or Ethereum, the governance rules can be written in smart contracts, which themselves can become subject to a governance decision.

The decision-making process of governance is provided by a framework that allows stakeholders, i.e. MoC stakers, to vote on mature and well-documented proposals, and to enforce the implementation of the approved proposals.

Every proposal will have to go through several stages to be finally implemented. Here you can see the full cycle of a proposal:

Proposal Development stages will happen off-chain. The forum provides a platform to present and discuss change proposals. Before voting, proposals are expected to pass through critical reviews of the MOC community.

The other stages from the Voting Process will happen on-chain. Submitted proposals are asked for support in a pre-voting phase before they might become approved for the actual voting.

Proposal Development

Before any submission, proposal ideas about system upgrades and parameter adjustments have to mature conceptually, “politically”, and meet the highest standards of code quality. The platform forum serves as a transparent place for information about discussions and current voting proposals. 

Critical discussions about the implications of proposals will increase the quality of the proposal content, and may include security audit certificates and discussions from smart contract developer experts resulting in well-described documentation, leaving no room, or at least minimized chances, for malicious proposals and unexpected upgrade behavior. At the same time, this pool of information serves as a trusted source. It is essential to have such a source so that all stakeholders have the same set of information during the voting process. 

The 3 stages involved in the Proposal Development includes:

• Proposal Preparation: conceptual idea and any documentation needed to support the proposal must be gathered here so it can be presented for discussion.
• Discussion in Platform Forum: discussions on the proposal happen in the forum giving the stakeholders the information to make a decision.
• Testing and Security Audit: the proposal has to be tested and audited to avoid undesired behavior or malicious proposals.

Proposal Submission. To submit a new proposal the governance contract must be in the pre-voting state and a minimum stake is necessary. When a proposal is submitted, a clock for this proposal starts to run. At the end of that period, it must satisfy the requirements to be chosen to go to the voting state, otherwise, it becomes obsolete.

Voting Process

Stakeholders who have the right to vote are MoC holders who are staking their MOC tokens. The voting procedure of a proposal passes through a pre-voting, and voting phase. Here we present the motivation for each of these steps:

• Pre-voting (PV): MoC holders can support a submitted proposal. In this phase, a lot of concurrent proposals can compete. This phase is needed to order proposals and keep the voting phase clean from unwanted proposals while not being too prohibitive. MoC holders can “promote” the submitted proposal for voting. This requires at least 5% of “yes” votes. Furthermore, when the voting period for this proposal finishes, there must not be any other proposal with a higher promotion, otherwise, the proposal is rejected, and the voting state proceeds with the higher promoted proposal. If a proposal passes to the voting state, concurrent proposals need to be submitted again when the contract state comes back to the initial state PV.
• Voting(V): Only one proposal from the pre-voting phase enters the voting phase. The actual voting takes place for a period to carefully review and examine the proposal for a positive vote or veto. MoC holders can vote with “yes” or “no” for the submitted proposal. Approval of a proposal requires a majority of “yes” votes from the total votes in favor and against. Secondly, there must be a quorum of 20% of all MoCs in circulation, and no successful veto which would require more than 30% of “no” votes of all MoCs in circulation. If these conditions are not satisfied, the system goes back to state PV, otherwise, the system jumps to the Activation state (Implementation).
• Activation (A): If the proposal results positive in the Voting stage then it is ready to be executed, this means that anyone can call the change contract to upgrade the system.