A well functioning governance and proposal process is key to the success of YAM. Here is a summary of what was discussed for an updated process in 2 recent governance calls.
For further information on the current governance process and some analysis, see my previous post on our Governance Process
Ideas for new products, procedures and initiatives for YAM can come from anyone. We want to have an open process where all are empowered to participate. This all starts in our governance forum and in our discord server. If you have an idea that you think should be implemented by the DAO then the first step is to present it to the community. The most informal way to do this is to come onto our discord server, find the relevant channel, and post your idea for discussion. If the idea is more elaborate, it may make more sense to post it in the forum (https://forum.yam.finance). The proposal brainstorming category is a great place to start this discussion.
In posting initially on the forums or in discord, you should be looking for feedback on the idea, whether it has been proposed before, whether there are other similar proposals being discussed, and whether there may be technical or other issues with it. This is the information gathering step. Early feedback on an idea is a great way to make sure you aren’t doing a bunch of unnecessary work.
Once you feel like you have received enough feedback on the idea and want to turn it into an official proposal, it is time to post it in the “proposals” category on the forum. A proposal on the forum is a requirement to get a governance proposal passed on-chain. Please follow the prescribed template for creating it. Using this template, it is important to make sure the idea and/or changes that are being proposed are clear, and the path to achieve them can be understood and discussed by the community.
Open item: We will be looking at improving the proposal template
When creating a proposal there are numerous ways that you can measure sentiment and move the conversation along.
The first option is with polls within your proposal post. This measures what other forum goers think about the idea and is an easy way, along with seeing what written replies you get, to “get the temperature of the forum.”
A second method is with a signalling snapshot vote. This is a non-binding snapshot vote that can be used similarly to the poll votes, but is more sybil resistant and will measure sentiment based on YAM voting power. All votes to determine parameters or percentages should be signalling snapshot votes. Signalling snapshot votes require a 2500 YAM balance to propose. If you do not have this many YAM, you can ask members of the community to propose it for you or to delegate their YAM to you. There is no quorum requirement for a signalling snapshot vote.
Final Snapshot Vote
Once a proposal has been discussed for at least 3 days, a final snapshot vote can be proposed. Final snapshot votes must be Yes/No votes, and must include a specification for how the proposal will be carried out. 25,000 YAM are needed in order to propose a final snapshot vote. Like with the signalling snapshot vote, if the original poster of the idea does not have this many YAM then they can request that someone else in the community post for them or ask for community members to delegate their YAM to them. Final snapshot votes have a quorum requirement of 500,000 YAM voting “Yes” and will pass with >50% of the votes.
Open item: 25,000 YAM is a lot of YAM to propose a final snapshot vote and we will need to improve the ease of vote delegation in order to make this possible for smaller holders. The other option would be to incorporate the Compund Autonomous Proposal module (Compound Autonomous Proposals. Compound Autonomous Proposals allow… | by Calvin Liu | Compound | Medium). Since we use the Compound governance module this should be possible.
All Final snapshot votes will start on the same day of the week (TBD) and last for at least 3 days, and a maximum of 14 days. Once a final snapshot is passed it can be considered to have social consensus. The proposer will then work with the dev team to determine the steps required to code the proposal and get it ready for an on-chain vote.
Open item: What day should votes start on?
Open item: Should we require that a final snapshot be discussed in our weekly governance meetings? If so, should that happen before the vote starts? That would change the time requirements for forum posts and final snapshot votes.
Once a proposal has been prepared to be submitted for an on-chain vote, it will be included with other passed proposals to be voted on together. This saves developer overhead and gas costs for voters. Like final snapshot votes, on-chain votes will also start on a consistent day of the week (same as snapshot or different?) On chain votes will typically be submitted by one of the core team, so the original proposer won’t need to worry about getting the 125,000 YAM to start the vote. Typical on-chain votes still need 500,000 “Yes” votes to meet quorum and will pass with >50% of the vote. This vote lasts for 48 hours with a 12 hour timelock.
Once an on-chain vote passes, the code is committed to Ethereum and cannot be changed without a new vote.
Open item: What day should votes start on?
There is currently a secondary governor contract that has lower quorum requirements (250,000 YAM) and a longer voting period (36 hours + 12 hour timelock). This is to be used for contributor payments.
If a malicious on chain vote is proposed it can be vetoed by the guardian multi-sig at any point during the voting period. This applies as well to any non-emergency vote that has not passed a final snapshot vote.
If there is an emergency that requires an on chain vote, the social consensus process described above (everything before the on-chain vote) can be skipped. In order for this to occur, whoever determines that an emergency vote is necessary must reach out to the core team and members of the guardian multi-sig on the discord channel. A forum post and discord post describing the issue and why it is an emergency will be posted and an on-chain proposal will be created ASAP. This proposal has the same requirements as a normal on-chain vote, lasting 60 hours and requiring a 500,000 YAM quorum and 50% of “Yes” votes.
Open item: Do we want a shorter vote with a higher passing threshold for use in emergencies?
Maintenance proposals that have been discussed previously can be expedited through the social consensus process if this has been voted upon previously. These votes can combine the forum proposal period with the final snapshot voting period and do not require signalling votes. Final Snapshots for these proposals can be reduced to 24 hours and started on non-standard days of the week if there is a clear need for them to occur quickly. Where possible, maintaining the standard schedule and length of snapshot votes should be maintained.
Open item: These expedited proposals needs to be developed and it should be clear what can and cannot be expedited.
I look forward to hearing the community’s thoughts on these changes and the process in general. Please comment below if you disagree with any of the items above or have thoughts on how to make them better. This is not a final document and we are looking for community input to improve it!