Abstract/Executive Summary :
Herein we propose a set of binding rules/requirements all proposals published for voting must meet to be considered valid.
Proposals are essentially the legislative documents of YFL. Their contents, if voted in, create binding impositions on the YFL ecosystem that can have significant effects on its function. We believe that proposals should be held to a standardized set of rules to ensure consistency, prevent abuse, and maximize legibility to voters.
Proposals must do the following, or will be rendered VOID
- Proposals that link to other domains will be considered void unless the governance forum moves to a different location.
Be published on the governance forums for a minimum of 3 days before being published on-chain to allow for a reasonable period of notice and comment.
Be minimally actionable – That is, they must outline some sort of action, requirement, guideline, etc. that is intended to guide, alter, or compel behavior of the YFL ecosystem and/or its participants.
- For example, a proposal that simply says “Craig Wright is Satoshi.” in all fields, while undeniably true, is an invalid proposal.
Have individuals designated as holders of keys for multisig wallets explicitly agree to do so by posting their assent in the forum discussion.
VOID proposals are, for the purpose of governance, considered to be nonexistent.
- Nothing contained within a voided proposal can take any effect.
- Other proposals may not reference or make actionable the content of any voided proposal.
- Voided proposals, their creators, and those voting on them are not eligible for rewards concerning the proposal at issue (This is not a permanent exclusion of these individuals from rewards)
Per Proposal 6, all votes are subject to a quorum requirement of 20% of YFL locked in the governance contract(s) at time of vote resolution, and a simple majority agreement threshold (>50%).
- Proposal writers, however, are free to increase the stringency of either threshold, so long as they do so clearly within the text of the proposal itself.
Proposal text shall be locked once submitted for on-chain voting – no further changes are permitted to the text at that time.
Proposals that affect other proposals must designate whether or not they are retroactive and/or affect proposals that are put on-chain during the said proposal’s voting period
- This proposal does not retroactively void previous proposals that did not abide by the above guidelines (including itself), nor shall it void proposals submitted for on-chain voting during this proposal’s on-chain voting period.
Enact the proposal standardization as above
Remain with our current system of guidelines only, without firm requirements.