Proposals
The governance process to make all decisions and updates to the protocol
The Proposal process is the way to make changes to the Fuckery Protocol, get backing to build on top of the protocol, leverage funds from the Treasury, update Governance Options, and decide on any other judgments by the collective.
Using our Discourse located at governance.oldmoney.io, any holder of $MFER with an MFER iD can log in to view, comment, upvote, and create Topics.
Topics belong to one of the following Categories:
Governance
Foundation
Growth
Building
Proposals
The "Proposals" Category is unique in that it's the process that you can follow to execute any changes to the protocol.
Proposals can be, but aren't limited to, any of the following:
Incentivized Building/Treasury deployments
Governance Option additions/changes/upgrades
Amendments to already executed Proposals/Votes
Changes to the DAO structure, parameter, or makeup
Organization and funding of Conferences or IRL events
Allocations for Sponsorships, Hackathons, Whitehat Hackers
Free merch for network participants or gain upfront capital for the sale of goods
Marketing budgets for Participants, Organizations, Advertising, etc
Seeding the creation of Organizations and electing/renewing their Leaders
Decisions to take on more recurring expenses as a DAO
You must hold a minimum amount of $MFER to create a Proposal, controlled by Governance Options, to limit an overload of submissions.
Proposals that gain enough traction in Discourse can be moved to the on-chain voting tool. Organization Leaders can conduct on-chain votes without this prerequisite.
Proposals are expected to follow a specific format that allows voters to make the most informed decision possible.
It is expected as a collective that the Proposals are reviewed and managed by all protocol members before their votes are cast using $MFER.
There are two types of voting that Proposals can go through using the on-chain voting tool.
The first type is a Governance Vote that helps determine the sentiment on Proposals, establishes an on-chain record, and sets the stage to attempt an Executive Vote.
An Executive Vote takes extra precautions to make sure only the most crucial and effective modifications are carried out in the protocol. As a result, Proposals in this vote receive a stricter evaluation.
If there are protocol-level changes or Treasury funds are to be allocated, then the Proposal must undergo an Executive Vote.
When a Proposal is going through any Vote, there are several Stages it can go through to signify process and action:
Draft
Pending
Canceled
Active
Failed
Succeeded
Expired
Queued
Executed
Organization Leaders, especially the Proposal's Backer, are responsible for efficiently moving the Proposals through the Stages.
Notifications for specific Proposals as they move through each stage can be opted into by participants.
Several voting systems control how participants can cast their votes and how the outcome is computed. See Snapshot.org for a reference on the description of each voting system.
Single Choice Voting
Weighted Voting
Approval Voting
Quadratic Voting
Ranked Choice Voting
Basic Voting
These are the guardrails in place to keep the decentralized balance in the voting process:
There is a Voting Delay which is a minimum amount of time that a Proposal must be finalized and published for review before a vote can occur.
To prevent Proposals from being created and voted on before they can be reviewed.
When you determine the start date for voting, you can set the number of hours to open the vote, another Governance Option called Voting Window, or establish a specific end date/time.
To prevent voting windows from being too small and subject to manipulation.
An Organization Leader must put their reputation on the line and back each Proposal that undergoes an Executive Vote.
To prevent anonymously conducting votes with reputational penalties.
For Executive Votes to pass, the result of the network participants using $MFER to display their influence in the protocol must match the result of a simple majority vote by Organization Leaders.
To prevent bad $MFER holders from overriding the Organization Leaders.
To prevent bad Organization Leaders from overriding the $MFER holders.
Proof of trust associated with the voters MFER iD
To prevent Sybil attacks.
You can keep the vote Quiet and not publish the results until the conclusion.
To prevent last-minute swing vote attacks.
Diminishing returns on $MFER influence for voting based on participation
To prevent bad actors with outsized $MFER from being able to exhibit outsized impact
A setting for a dynamic quorum threshold can be applied to voting and can change based on the set quorum plus a differential of votes for/against a Proposal. A threshold will stay the same if the opposition votes are minimal. In the event that there is a substantial number of votes against the Proposal, the threshold will increase, requiring a higher number of affirmative votes for it to be approved.
To prevent Proposals without overwhelming support from being implemented.
A Challenge Period occurs when calculating the voting results to solve the issue of fungible tokens and voting windows being abused. When the minimum voting duration/end date is reached, and a Proposal crosses the quorum, the Challenge Period starts. The Challenge Period can also be initiated manually by Organization Leaders if the quorum is met, but the duration hasn't ended. During the challenge, any votes that don't actively hold at least the amount of $MFER used to cast their vote will be canceled. If, after this challenging process, the quorum threshold isn't met, then the voting is reopened. The challenge will continue to be carried out for a specified number of cycles, as determined by each Proposal (allowing for quicker execution of more pressing proposals). If the Proposal's defined number of cycles is achieved, the outcome will be finalized regardless of the quorum.
To prevent issues with voting using fungible tokens ($MFER)
All historical data of Proposals, Status changes, commentary, and voting outcomes are available and summarized on the MFEF Dapp.
Last updated
