Hi everyone! This thread serves as a discussion forum for Optimism’s Operating Manual v0.2
v0.2 has been drafted to address feedback we’ve heard from the community over the course of Season 1, as outlined in Governance Update #2. The full diff of the manual can be found on GitHub here. A brief summary of those changes can be found below:
Changelog
Changes two-week voting cycles to a three-week voting cadence:
Week 1: Community feedback
Week 2: Delegate review
Week 3: Snapshot vote
Summary for proposal authors
Optimism has a three-week proposal review cycle.
Before getting started: gut-check your idea in the #gov-temp-check channel in Discord.
When you’re ready, draft a proposal and post it on the Forum with [Draft] in the title for feedback from the community.
When you’re ready for formal review from Token House delegates, update [Draft] to [Review]. You are expected to have made an effort to get community feedback before submitting for formal review.
During the next Review Week (every three weeks), delegates will provide feedback on your proposal. Use your judgment to incorporate feedback.
Once your proposal has been approved for a vote by two delegates with >0.5% of voting supply, you may add a link to your proposal to the Voting Cycle Roundup thread. The proposal will be automatically added to Snapshot during the next one-week voting window.
If your proposal is passed, the Optimism Foundation will distribute the approved funding. Note the Foundation may be in touch to collect additional information from your project in order to execute the grant.
If your proposal fails, you can make a new proposal in the next cycle specifying how you have incorporated significant changes from your first proposal.
Increases number of delegate approvals for a proposal to move to a vote from one to two delegates
Defines “votable OP supply” as “the total amount of OP that has been delegated, and therefore can participate in voting”
Adds that transparency into OP votable supply will be included in each Voting Roundup Thread
Adds “without explicit delegate approval, proposals will not move to a Snapshot vote” - Adds “delegates cannot approve their own proposal”
Clarifies rules for proposal re-submission
Removes old proposal guidelines for Phase 0 GovFund proposals
Adds “Committee Creation” proposal type
Adds links to Phase 1 GovFund template
Changes quorum from 10% to 30% of votable supply for all proposal types
Changes the approval threshold for Protocol Upgrades from 51% to 76%
Adds mention of future Delegate Code of Conduct
Adds administration rights to remove duplicate proposals
Changes OPerating Manual to Operating Manual
Changes table headers for formatting clarify
Adds new TLDR for voting process
Discussion
This thread will remain open until the end of the Reflection Period. While these changes do not need approval by the Token House via a formal Snapshot vote, the Optimism Foundation welcomes your feedback to help craft a voting process that works for delegates, proposal authors, and involved community members.
The Operating Manual v0.2 will go into effect at the beginning of Season 2 on September 8 with the kickoff of Voting Cycle #6.
Reading through the changes now, left a few tiny nits on the PR. More substantive comments below
Small request about this, potentially for a future season:
For a proposal to proceed to Week 3 (voting), two delegates with >0.5% of the current votable token supply must give explicit approval on the discussion thread. Delegates may signal this approval by pasting the comment on the proposal discussion thread: ”I am an Optimism delegate [link to your delegate commitment] with sufficient voting power and I believe this proposal is ready to move to a vote."
It would be nice to have easy to link cards showing delegates’ voting power rather than the thread. The Optimism website already has this info here. I think all that’s missing would be to make individual delegate cards linkable.
Re: “The total votable OP supply will be determined based on a reasonable estimate provided by the Optimism Foundation prior to each Voting Cycle.”
It would be nice if there was somewhere (even if just a .md file or thread here) keeping track of the votable OP supply per Voting Cycle
Re: the Approval Thresholds, it’s a bit odd to me that “Protocol Upgrade” doesn’t have the highest threshold, similar to “Inflation Adjustment” (which can be thought of as a protocol upgrade in a way) or “Director Removal”.
Re: this
If it is not, the Foundation may remove the proposal for resubmission or cause the proposal to be implemented with certain guardrails, in its discretion, and coupled with an explanation to the Collective as to why the proposal was rejected or limited.
It would be nice if the OF could commit to when possible/on a best-effort basis/assuming no legal risks/etc. proactively giving this feedback to proposal authors and the community more broadly so that potential solutions/tweaks may be considered during the Voting Cycle.
I would add to the manual to clean up the topics or add one more topic for [READY] proposals, currently the Phase1 topic is a mess.
And I would also extend the snapshot voting at least 2 weeks, this gives time for delegates/members and participating communities to get organized to vote. I also think it should be approved by 3 delegates.
Thank you for the thoughtfulness in updates and incorporating feedback from delegates/community members. I’m supportive of these changes and agree with @timbeiko it would be nice to have an easy way to see delegates’ voting power to know if it is over 0.5%.
Thank you for the valuable feedback on the updated operating manual! We’ve made some updates to reflect it:
Adds that transparency into OP votable supply will be included in each Voting Roundup Thread
Adds “without explicit delegate approval, proposals will not move to a Snapshot vote” - Adds “delegates cannot approve their own proposal”
Changes quorum from 10% to 30% of votable supply for all proposal types
Changes the approval threshold for Protocol Upgrades from 51% to 76%
While not specified in the operating manual, we also plan to implement features which will increase transparency into delegate voting power, particularly on Discourse.
