Governance
MELD is integrating a Decentralized Autonomous Organization (DAO) into its protocol functionality.
DAO’s enable community members to contribute to future protocols as MELD Improvement Proposals (MIPs) to other governance participants. Our decentralization model aims to ensure that no parties are powerful enough to convince a majority of participants to change protocol parameters such as minting assets. DAO’s explicitly maintain the rules that every participant must follow to join, and utilize the protocol equally. Our final stage implements voting that ensures that MELD’s protocol maintains improvements from a consensus of its participants. Stakeholders are able to participate in voting, and governance activities provided they maintain at least 0.01% of the total token supply. The MELD governance will have three distinct stages for implementing the DAO:
During this period, the team is in complete control of the project, and no voting is done. This is because there will be bugs and events which may require immediate hotfixes. This cannot be done democratically.
During this period, the team is still in complete control of the project and can deploy hotfixes same as above, but for the non-urgent decision, it can take community input via a forum or even via off-chain voting like a snapshot - https://snapshot.org/
During this stage, the project is fully decentralized, and all decisions are made via a strict procedure, and all voting is done on-chain. The process is detailed below:
Once MELD transitions fully to Stage 3, the following governance structure will be implemented:
Anybody with 0.01% of $MELD delegated to their address can propose a governance action; these are simple sets of activities, such as changing parameters of the protocol that no one else can modify. Proposals are executable code, not suggestions for a team or foundation to implement.
All proposals are subject to a three-day voting period in the MELDapp, and any address with voting power can vote for or against the proposal. If a majority and the minimum votes (i.e., quorum) are cast for the proposal, it is queued in the Timelock and can be implemented after two days. The quorum is currently set to 50% of all governance votes.
Anyone can also cancel a proposal if the original proposer loses the required vote power to create proposals (0.01% of total governance votes) after it was added. This helps prevent someone from making a malicious proposal and immediately withdrawing the governance contract’s votes.
Governance will be exercised by users via voting power (VP). VP is determined by the number of MELD tokens staked in the governance contract and the duration for which they are staked.
Governance will be done via voting power (VP). VP is determined by the number of MELD tokens staked in the governance contract and the duration for which they are staked. More formally:
Where:
- is the number of tokens staked
- is a multiplier based on the stake durationin weeks.
We further define as:
We can then plot for as follows:
During Stage 3, MELD will implement the following:
Anybody with 0.01% of $MELD delegated to their address can propose a governance action; these are simple sets of activities, such as changing parameters of the platform that no one else can modify. Proposals are executable code, not suggestions for a team or foundation to implement.
All proposals are subject to a three-day voting period, and any address with voting power can vote for or against the proposal. If a majority and the minimum votes (i.e., quorum) are cast for the proposal, it is queued in the Timelock and can be implemented after two days. The quorum is currently set to 50% of all governance votes.
Anyone can also cancel a proposal if the original proposer loses the required vote power to create proposals (0.01% of total governance votes) after it was added. This helps prevent someone from making a malicious proposal and immediately withdrawing the governance contract’s votes.
Last modified 1yr ago