Foundation Mission Request: Governor v2 Contract #64
Comments
bdresser
added
Intent: Governance Accessibility
Foundation Mission Request
|
If anyone with an Eagle tier is interested in collaborating on this, I'd love to help! Resume:
matt(at)masurka(dot)com |
Foundation Mission (RFP) Application
What makes your Alliance best-suited to execute this Mission?We’ve been working with the OP Foundation and the Optimism community over the last quarter to take governance onchain and are intimately familiar with the technical requirement and community needs.
Please describe your proposed solution based on the above Solution Criteria (if applicable):Partial delegation
Accurate quorum calculation
Support for different proposal types
Support for different voting systems
Seamless governor and client integration
Make the governor easily and safely upgradeable
Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each peice of work:Design and write the governor upgrade Our plan will be to focus on designing and building the contact logic first, allowing for sufficient time for reviews, feedback, and finally audit, before beginning the Agora client integration work. As this is the part with the most complexity, we provide here an estimate of the scope of each line item of work:
Integrate the client with the new governor Once we are confident in our contracts, we will ensure that the Agora client is correctly setup to consume these new proposal types, contracts and voting systems. This will bring https://vote.optimism.io/ to be the most compliant client to work with these new governor changes. Agora is currently upgrading its data pipeline to ensure the fastest and most reliable OP Collective voting experience. This will allow us to implement these changes on top of the new back-end so that OP can reap the performance and flexibility benefits first. ETA for the front-end, back-end and end to end testing → 36 days Estimate to ship to production: 145 days or ~5 months Please define the critical milestone(s) that should be used to determine whether you’ve executed on this proposal:Assuming that the proposal passes on July 1, 2023
Please list any additional support your team would require to execute this mission (financial, technical, etc.):Close collaboration with the Optimism Foundation, who hold the admin permissions needed to upgrade the governor. Grants are awarded in OP, locked for one year. Please let us know if access to upfront capital is a barrier to completing your Mission and you would like to be considered for a small upfront cash grant:As a small team with no institutional investors reliant mostly on public goods funding, the grant being locked for a year significantly impedes our operations, requiring us to source funding from elsewhere to make payroll on a month to month basis – as well as cover upfront costs like audit costs and tax. We can scrape by without upfront cash by seeking grants elsewhere, and look into financing, but early liquidity would significantly help our operations.
|
Hey Matt! sending you a DM on twitter. would love to explore some ways to collab :D |
BootNode IntroPablo here, co-founder and CTO of BootNode. BootNode is a leading long-term web3 builders partner. We accelerate the development and growth of protocols, dApps, and networks. From ideation to scaling, we help teams build and ship faster with superior quality by leveraging our extensive business and technical expertise in multiple protocols, industries, and software development best practices. In the early days, BootNode contributed engineering work to early-stage Optimism-native protocols such as Lyra Finance and Aelin. Presently, we are determined to continue our efforts towards augmenting the network's expansion and encouraging more users to adopt it. About this RFPWe got interested in this RFP. Although we don’t have enough contributions to apply because of the Eagle Tier, we are open to contributing and collaborating to achieve the best solution. Here are some comments from our initial analysis performed by our team (particularly @patitonar) on the change request: Partial delegationOP is a governance token that implements ERC-5805: Voting with delegation. It allows delegating the total voting power to an address. The ideal solution is to introduce the partial delegation feature into the token contract by updating the voting snapshot and delegate logic to set the voting power based on proportional specifications of the user balance. The OP token doesn’t seem to be an upgradable proxy. Unless there is a way for the Optimism team to upgrade the bytecode (via a network upgrade or any other mechanism, as it is a pre-deployed contract), introducing changes to the voting token won’t be a viable option. Currently, the only way to simulate partial delegation is to transfer a portion of the balance to other accounts or smart contracts, each delegating to a different address. This has some UX issues as the balance will end up in multiple addresses and could require multiple transactions for a user to reach the desired delegations. Following this path, a smart contract solution could be implemented to reduce friction to achieve the desired behavior as much as possible. Accurate votable supply quorum calculationTo calculate the quorum for each vote as a portion of the “total votable supply”, the governor contract will need access to that information. According to the OP token implementation, token balance does not account for voting power. Users need to delegate to themselves or another account to activate checkpoints and have their voting power tracked. This means that the total votable supply changes in the following user interactions in the OP token:
However, the total votable supply over time is not tracked in any variables. So other smart contracts can't get this information. The only way to make this information available would be to update the token implementation to introduce such functionality. If the token upgrade is not possible, some mechanism could be designed to allow an external oracle to keep track of the total votable supply off-chain and post this information to a smart contract. However, this introduces a few trust assumptions and will require some analysis of potential manipulation risks. Support for different proposal typesOne important detail in this change request is ensuring that the correct type and parameters are picked up when a new proposal is submitted. We need to ensure that if a protocol upgrade proposal is submitted, intentionally or unintentionally, the proper quorum, threshold, and duration are set, and it is not processed as another type, for example, with lower requirements. There should be some smart contract level validations to ensure the correct behavior. Support for different vote typesCurrently, the Governor contract uses the OpenZeppelin GovernorCountingSimple logic for simple vote counting. This logic will need to be reimplemented generically, along with other changes, to allow adding custom vote types and be flexible enough to allow us to integrate different voting strategies in the future. Final thoughtsAs BootNode, we’d like to restate and remark on our interest in this RFP. From our perspective, this is an excellent opportunity to evolve the network and its governance. However, these changes have a high impact, and looking after user experience seems critical. We are open to discussion and collaboration, do not hesitate to reach out. |
|
Hi @yitongzhang! After our analysis (CC @patitonar), we (@BootNodeDev) looked into the Agora application, and here are a few questions that came up:
Can you share your approach for calculating the “total votable supply”? From our understanding, unless it is tracked inside the token contract, any other solution will rely on and trust external components. Hence, open to risks. Feel free to reach out to me: pablo(at)bootnode(dot)dev |
|
hey @pablofullana, thanks for checking out our proposal! You're definitely correct that both of these items are significantly more difficult due to the OP token not being upgradable. We've got some ideas for both, and are still working through the exact implementation details. There are some UX tradeoffs with our current ideas, but we think we can pave over most of them at the client level. I've sent an email to grab a time to share some of our WIP thinking. |
Foundation Mission (RFP) Application // ScopeLift + Tally
Members of the alliance: ScopeLift + Tally ScopeLiftScopeLift is a 6 person team of expert EVM devs. We've had the pleasure of working with many great projects in the space, including Uniswap, Gitcoin, Endaoment, and others. We have our own project called Umbra, which is a tool for privacy preserving payments. Contracts we've written have processed and custodied hundreds of millions of dollars. We've worked with Optimism in the past, received RetroPGF for 2 of our projects (Umbra, Flexible Voting), and have done a large amount of relevant work in the DAO Governance space. Some examples include: Uni V3 on the OVM — Custom work for Optimism which required a fork of Uniswap V3 and changes to make it deployable with passing tests on the OVM. Original Gnosis Safe on the OVM — Custom work for Optimism. First multisig available ont he Optimism chain. This was before L2Safe.sol, and we couldn't use the regular Safe.sol since it relied heavily on OpenEthereum indexers which wasn't yet supported on the OVM. Flexible Voting — Our extension to the OpenZeppelin Governor that enables fractional voting, and therefore allows arbitrary delegate contracts to be developed. This unlocks all kinds of new use cases, such as voting with tokens while earning yield in DeFi, voting on L2 with bridged tokens, shielded voting (i.e. secret/private voting), and more.
Cross Chain Voting — Our under-construction, MVP implementation of cross chain voting built on top of Flexible Voting with a grant from the Ethereum Foundation. Gitcoin Governor Upgrade — Our testing harness to upgrade Gitcoin's Governor to a Flexible Voting Governor.
Seatbelt — DAO proposal safety tool built with a grant from Uniswap and used by many large DAOs in the ecosystem. TallyTally is the most popular governance front end for onchain DAOs in the Ethereum ecosystem. Our team of 15 has contributed to many of the establised onchain governance UX patterns, including no-code proposal creation, delegation, and voting. Tally is the only self-serve onchain governance application. Any Governor DAO can easily add itself to Tally and use our full suite of free tools to make onchain governance accessible. Tally has experience operating at L2 scale. We've invested significant resources in our API to handle the demands of rollup transaction volumes. We have worked closely with layer 2 communities to customize their Tally implementations based on unique needs. OpenZeppelin Governor Standard - Tally worked with OpenZeppelin and Compound to standardize the Compound Governor smart contracts into the OpenZeppelin Governor contracts. L2 to L1 Cross Chain Voting Tally Zero Tier requirement: Met through the receipt of more than 50k OP via RetroPGF What makes your Alliance best-suited to execute this Mission?Together, Scopelift and Tally have provided the infrastructure, tooling, and expertise that powers some of the largest, most valuable DAOs in the Ethereum ecosystem. We have deep technical and practical experience operating across leading DAOs including Optimism, Uniswap, Arbitrum, ENS, AAVE and many more. Together they have been trusted for the execution of Governor upgrades, protocol research, multi-billion dollar decentralization events, and more. ScopeLift has been a key driver in the development and innovation of governance using the Governor Framework. We pioneered a new feature included in the OpenZeppelin Contracts repo: This addition allowed ScopeLift to extend governor to create Flexible Voting, a novel, backward compatible approach that enables new possibilities such as cross-chain voting, voting via locked LP tokens, and more. This was made possible via grant from the Uniswap Foundation and has received additional grants to integrate it into leading Defi Protocols: AAVE, Compound. ScopeLift additionally has been a pioneer ensuring the safety and integrity of onchain governance systems. A core piece of their ecosystem work has been their contributions to Seatbelt, a real-time proposal monitoring and simulation system that outputs security reports built for Uniswap. Seatbelt is the standard in Governor proposal safety. Tally helped the Arbitrum team launch their DAO, providing key tooling for Delegate discovery and participation, as well as custom engineering to support the indexing, UI and interface for a multi-proposal based governor system that shares many similarities to this Foundation Mission Proposal. Tally has worked since the inception of the Governor framework with key community partners to build and standardize the Governor framework. Tally helped grow the onchain DAO ecosystem to hundreds of Governor DAOs and many billions of dollars of assets managed by decentralized communities. Tally and ScopeLift are both extensively qualified to complete this RFP on its technical merits. They are also both widely-known, collaborative and open, participating in the wider DAO ecosystem. Tally produces the leading DAO Podcast, DAO Newsletter, and DAO Conference series. Tally also led Delegation Week, an industry wide event. Tally and ScopeLift believe that multi-client governance tooling is critical for a safe and extensible ecosystem. If awarded this grant, the teams would be sure to work closely and openly with existing Optimism governance tooling providers to be sure they have equal access to all development information. Please describe your proposed solution based on the above Solution Criteria (if applicable)Our collective experience enables us to identify one of the biggest weaknesses with the Governor contracts as they stand today: a lack of modularity. To address the requirements of the Optimism Governor v2, we will start with the principle of modularity. The core functions of the Governor will be extracted into an external modules. Governance itself will have the right to modify these modules. We will write the modules needed to fulfill the requirements of this RFP, but also leave the Optimism Collective with a flexible, upgradeable architecture which will serve it for years into the future. This process makes for a more iterative approach to fulfilling the RFP. Rather than a "big bang" upgrade which adds all the functionality requested in one go, we can now build, test, deploy, in a modular step by step process. This flow is inherently more secure, with ample opportunity for feedback and agile iteration. Architecture SchematicBelow is a diagram of the smart contract architecture for the modular Governor and RFP modules. Each component of the system shown here is subsequently described below.
Partial DelegationTo support Partial Delegation, we will make the new Governor compatible with Flexible Voting. Flexible Voting is ScopeLift's extension to the Governor which allows client delegate contracts to split voting weight for any given proposal. This would enable Partial Delegation to be implemented as an opt-in client contract with the desired rules. As a side effect of adopting Flexible Voting, the Optimism Governor will gain a permissionless interface for arbitrary integrations and delegation schemes to be built by anyone moving forward. The Partial Delegation scheme will be one of any number of options that could be implemented. Several DAOs are already planning to adopt Flexible Voting, including Frax, Gitcoin, and PoolTogether. It has been audited twice, by OpenZeppelin and Trail of Bits. ScopeLift has already implemented several client voting contracts, including integrations that allow token holders to participate in governance even when their tokens are deposited in Aave and Compound. ScopeLift is also building a cross-chain voting MVP using Flexible Voting thanks to a grant from the Ethereum Foundation. Accurate votable supply quorum calculationTo enable a dynamic and configurable quorum, we'll move quorum from a parameter on the Governor to an external contract called a QuorumCalculator. The calculator will implement an interface which takes a proposal type and returns the quorum required for its approval. The address used for the quorum calculator will be configurable by Governance. We'll implement a concrete quorum calculator to achieve the requirements of this RFP. The calculator will look at the total supply of the OP token, then subtract the balances held by addresses in an exclude list. It will then apply and return a percentage fraction of the remaining tokens. The percentage can vary by proposal type. The exclude list and the fractions on our calculator implementation will also be managed by Governance. Governance can add addresses known to hold tokens that are out of circulation to exclude them from the quorum calculation. Support for different proposal typesIt is relatively straightforward to add a proposal type parameter, and to to subsequently manage threshold configurations on a per-proposal-type basis. Such a naive approach, however, does not properly account for onchain enforcement of specific thresholds for certain types of actions. As an example, changing the inflation rate of OP is said to require a 76% approval threshold. How do we ensure that only a proposal that meets this threshold is, in fact, able to change the inflation rate? If the MintManager contract only checks the sender address to verify the change has been initiated by governance, a proposal type with a lower threshold could be used to modify this important parameter. On the other hand, a less sensitive onchain parameter might require only a simple majority to modify. To address this issue, we'll add a ProposalConfigurator contract. This module will allow governance to configure specific target contracts which certain proposal types are able execute against. The default proposal type will use standard For/Against/Abstain style voting with high quorum and approval thresholds. Subsequently, other proposal types can be added with lower thresholds, and/or alternative voting schemes, with a list of targets they are permitted to call. The Governor will enforce that alternative proposal types only call explicitly permitted target contracts. Governance itself will have the authority to add, remove, and configure proposal types, along with their permitted target lists. Support for different vote typesTo enable alternative vote counting methods, we will leverage the flexibility enabled by the When a proposal is created, a voting strategy must be defined. Each voting strategy is a separate, modular contract that conforms to the appropriate interface. The Governor enforces that the strategy selected is explicitly approved for the proposal's type. When a user casts their vote, the Governor will look up the appropriate voting strategy contract tied to the proposal and forward all voting data to it. The voting strategy contract manages the proper decoding of the voting strategy and counting of votes as appropriate. The voting strategy also exposes a getter method to report the vote results to the Governor and to the outside world. Governance itself will have the right to add, remove, and configure voting strategies. Voting UI Integration: Tally is the most comprehensive and most widely used governance front end tool in the ecosystem, with a complete suite of end-to-end tools for proposal creation, voting, delegation, and DAO management. To ensure broad accessibility for governance participants with varying degrees of technical expertise, we will build a beautiful and intuitive UI that allows delegates to easily discover, understand, and interact with the new features of the Optimism Governor v2 contract. The Optimism ecosystem will benefit from rich data insights, proposal simulations for security, and powerful no-code proposal creation tools. Proposals and voting types will be presented in clear and easy to understand UI/UX patterns. Tally will leverage its years of deep experience building and pioneering tools for DAOs to ensure a fantastic user experience for the Optimism Collective. Tally will take ample time to engage with the community and key delegates on design and implementation of the UI, to ensure that the resulting technology meets the needs and expectations of the Collective. The new features will be integrated into the Tally.xyz indexing and API service, used ecosystem-wide by teams such as Compound, Bankless, DefiLlama, OpenZeppelin and many others. This wide integration surface greatly enhances the impact of this RFP by bringing Optimism Governance to 3rd party tools that offer voters a variety of additional services such as rich data, delegation and voter information, gasless relays, automations and notifications. Multi-client support Tally and ScopeLift feel strongly that a multi-client governance ecosystem is critical to the success of public infrastructure such as Optimism and is aligned with the ethos of robust decentralization. This RFP represents a significant increase in the complexity of the governance framework to power Optimism which potentially represents a hardship for 3rd party front ends to integrate without assistance. As such, we would like to suggest an additional grant to support the Agora team (not party to this alliance, but has a competing proposal for the RFP) so that they may also have the funding necessary to implement the changes on their UI which is currently used by the Optimism Foundation. The Agora team has contributed greatly to the accessibility of Optimism governance and in our opinion should be included in the distribution of resources to continue their work. Tally has worked previously in collaboration with the Agora team on the creation of Delegate Metadata Standards, and our intention would be to work openly and collaboratively. Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each piece of workThe total time needed for the project implementation is estimated to be 6 months, as detailed below. Note that the smart contract work will be executed in parallel with api indexer and frontend development and will track with smart contract development timings. Smart Contract Estimation
Front end Estimation
Indexing Implementation
Please define the critical milestone(s) that should be used to determine whether you’ve executed on this proposalAssuming a start date of July 20th, 2023 1 week after the selection deadline.
We have included a number of public comment periods into the timing of the work. This will allow the community to follow along with progress and share feedback/comments on design and work progress. ScopeLift and Tally are both experienced in building in a public format. Please list any additional support your team would require to execute this mission (financial, technical, etc.)Collaboration with the Optimism Foundation for Design review, feedback and implementation of output. Grants are awarded in OP, locked for one year. Please let us know if access to upfront capital is a barrier to completing your Mission and you would like to be considered for a small upfront cash grantThis project will have significant upfront costs for which we would like to be considered for an upfront cash grant. Because ScopeLift is not a venture backed firm, this grant would go towards funding ScopeLift’s operations. Tally would not receive any portion of the upfront cash grant. Additionally, auditing costs are an unpredictable 3rd party expense. We would like to be consider how auditing costs for this project will be handled. Please check the following to make sure you understand the terms of the Optimism Foundation RFP program:
|
Foundation Mission (RFP) ApplicationQualifications for submitting at the Eagle Tier: Both of these projects received a part of the (amazing) RetroPGF 2: Gov, ERC-5560. They were developed by the WH3C, the Web3 Hackers Collective, a DAO which mission is to build integrations through mentoring and learning.
For us, an implementation of Governor v2 would fit the needs of the Optimism Token House, but its potential impact goes way beyond: many different communities will be able to take advantage of it in the safest way. This is specifically motivating us. What makes your Alliance best-suited to execute this Mission?
Please describe your proposed solution based on the above Solution Criteria (if applicable): Partial delegation
Accurate votable supply quorum calculation
Support for different proposal types
Support for different vote types
Integrate new contract functionality into a voting UI
Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each piece of work: For each new feature, we would deliver the Solidity code and tests, then a new deployment to Optimism Testnet followed by a UI integration and a call to beta testers. The plan is to:
Please define the critical milestone(s) that should be used to determine whether you’ve executed on this proposal:
Please list any additional support your team would require to execute this mission (financial, technical, etc.): We would almost entirely cover the development of the Solidity contracts and UI, but we already know that we will need:
Grants are awarded in OP, locked for one year. Please let us know if access to upfront capital is a barrier to completing your Mission and you would like to be considered for a small upfront cash grant: (Note: there is no guarantee that approved Missions will receive up-front cash grants.) We’re a small hackers collective without any business model whatsoever for now, so a $72k USD eq. up-front cash grant covering 6 months of work would allow us work in the best conditions. Please check the following to make sure you understand the terms of the Optimism Foundation RFP program:
|
|
Submissions for this RFP are now closed. Thanks to everyone who submitted a proposal! Someone from the Optimism Foundation will reach out on or shortly after July 13 to communicate which proposal(s) have been accepted and schedule a kickoff. We may also reach out individually using the contact info you've provided if we want to discuss your proposal in more detail. In the meantime, feel free to tag me here or DM (bobby@optimism.io) with any questions. |
|
We looked into the @apbendi ScopeLift + Tally application and think it is a good approach. Here are some thoughts.
From our understanding, the total votable supply over time is not tracked in any token variables, and as the token contract is not upgradeable, the only solution is to build some logic to approximate its value considering different trade-offs. Here are some potential risks/issues we noted from the proposed solution:
One possible simplification for that approach could be that this total votable supply value could be set directly by governance in the Quorum Calculator contract, only maintaining one value (that today is hard-coded in the contract) instead of a list of addresses and the percentage param applied as stated in the description. Using existing indexing solutions, such as subgraphs, the total votable supply can be tracked off-chain, and a proposal can be submitted to update it once the value in the contract deviates from a certain threshold. Of course, this idea also has its trade-offs, but it can help iterate and get the best solution. As BootNode, we are open to discussion and collaboration. |
|
Hey @patitonar, thanks for the feedback! In the RFP "Total votable supply" is defined as "the total number of OP currently delegated to vote". The OP token self-delegates by default, so anyone holding tokens that has not explicitly delegated to someone else has delegated to themsevles. Therefore by that definition, our understanding is that the total votable supply is equivalent to the circulating supply. But because the RFP mentions that currently "the quorum for each vote is set manually on the contract by computing the correct quorum ahead of each vote" we assume the definition is actually more complicated. It's possible that there's some contracts, such as the Foundation's safe at The total OP supply and user votes are both checkpointed by the OP token already. Therefore we don't need any changes to the token contract, nor do we need to settle for any approximations. At proposal creation time, the If required, we can enforce that addresses in the It's also worth noting that although the OP token is not upgradeable in the sense that it's not behind a proxy, it is a predeploy that was placed at its address, so the token's code can be changed if required and if supported by the Optimism team and community. |
|
Hey, @mds1 thanks for the reply! I understand the rationale for your proposed solution now, and from your understanding and assumptions, I think it makes sense. However, from our understanding, there are some of the assumptions you mentioned that seem to be not correct.
By default, the token balance does not account for voting power. if an account does not explicitly self-delegate or delegate to someone else (in both cases by calling the method We mentioned this earlier in another comment
You can verify this by looking at the OP token code and using the foundation wallet you mentioned as an example. This wallet has a big amount of OP tokens, you can verify it hasn't delegated to anyone nor self-delegated by calling
So that's why on our feedback we mentioned that the total votable supply is not related to the total and circulating supply |
|
Hey @patitonar, You are correct. We misread the
Regardless of which approach we were to take, we would want to keep the core part in place, that is, the modularity of the quorum calculation. Moving the calculation into a governance-upgradeable standalone contract will be a win for the future either way. |
|
Hi all – thanks for the excellent submissions and discussion. The Optimism Foundation has selected Agora's proposal to move forward with the work described in this RFP. That said, we're really excited about the amount of interest and expertise from other folks here. We're in early innings for Optimism's governance system and have a lot to build as it matures – we plan to post another RFP in the coming weeks for additional improvements to Optimism's onchain governance system, and will continue to have a conversation internally about how to get more teams in the community involved here. |
|
Incredibly excited! Will DM those we've been chatting with to collaborate, looking forward to getting everyone's feedback as we work on this. |
|
Hey there, Yitong from the Agora team with our first milestone. Apologies that we are technically past our proposed first milestone date, those dates were based on a July 1 approval timeline, and given that we were chosen for this RFP on the 18th, we have slightly updated our delivery schedule to reflect the new timeline here.
Quick table of contents for this post:Section 1: OP Governor V2 Architecture: This first section will walk through the high level architecture that we are planning to build out to enable the five key features as requested by the OP Collective:
Section 2: Token Upgrade Discussion: In this section we explore the pros and cons of shipping these features via a token upgrade vs. upgrades to the governor and a proxy contract we call alligator. It’s important to emphasize that the current timeline, and architecture discussed below doesn’t assume a token upgrade (as that would drastically change the deliverables and timeline), but given that it’s on the table it’s worthwhile talking through the pros and cons. Section 3: Call for comments and discussion: Finally, we conclude with 3 areas that we would love the Collective’s feedback on so that we can best shepherd this project to the right outcome. Section 1: OP Governor V2 ArchitectureBelow is a high level architecture map of how we plan on shipping the five features listed above. 
Let’s look at each of the components in more detail: Liquid delegation protocol - Alligator V3Alligator is the liquid delegation protocol that Agora designed to allow granular sub-delegation permissions to delegates currently being used by the Nouns DAO. Versioning V1: Original version, designed for ERC721 voting tokens only V2: Adds support for voting pools + ERC20 voting tokens V3: Adds support for partial voting, redesigned specifically for OP governor Alligator V3 Core logic
On partial delegation
OP GovernorThe governor will be extended with new features based on the RFP. It will:
Voting modulesThey are external modules which extend the functionality of the core governor with custom logic to be executed when votes are cast and upon execution.
Votable supply oracleExternal contract, managed by OP governance / admin, that allows to manually update OP votable supply.
Proposal configuratorContract containing list of proposal types and relative
We will be publishing our first push to the OP Governor V2 repo this week, so stay tuned for that, but hopefully this give you a good idea of the high level architecture and changes we are making to the Governor, to our Proxy Contract alligator and the additional contracts and service to manage and configure quorum and proposals respectively. Section 2: Token Upgrade DiscussionAs we are building out the [OP Governor V2](#64) there are a few areas where having the ability to preform a token upgrade would be advantageous given the flexibility it would allow us and the OP Collective in the long term. In speaking with the OP team, we are currently evaluating the feasibility and governance implications of such a change. Please note: All timelines, and architecture outlines above assume that we will not be using a token upgrade to achieve these objectives. If we were able to use a Token Upgrade, it would impact both the timeline of delivery and implementation as a token upgrade would need to be passed via governance to the OP collective, likely in 2024. That being said, given how advantageous some of the solutions are, we decided to get the conversation started around what the features would look like if we were to explore a token upgrade. Accurate votable supply quorum calculationThe problem: Right now there is no easy way to separate out the total voteable supply from the total supply of OP tokens. This is due to how the original OP token contract was setup. Governor upgrade solution: We will implement an oracle service that will keep track of the total voteable supply from outside of the primary contract that anyone can call to get the current voteable supply. We will need to initialize this value from the current state, and then keep track of changes based on emitted Token Upgrade solution: If we were able to perform a token upgrade, we would be able to modify the When delegations would occur, we would keep track of the voteable supply counter and provider easy ways to read it for quorum calculations. Pros of the token upgrade:
Pitfalls if we do it without token upgrade:
Partial delegationThe problem: By far the biggest challenge with implementing a clean, partial delegation + partial voting scheme for OP is is allowing voters to hold their tokens without transferring them to the liquid delegation protocol, and instead only delegating them. 
Similarly to a flexible voting-like architecture, the flow with a liquid delegation protocol (from now on “alligator”) is the following:
However, since tokens would need to be delegated, we cannot use the Governor upgrade solution: The architecture we designed to overcome the limitation relies on allowing holders to delegate to proxy contracts (not directly on Alligator) which can then be used to keep track of voting allowances by relying on the state stored on the OP token contract. This builds on an existing architecture of Alligator V2. Proxy owners can then delegate a part of the voting power of their proxies to delegates, in the form of absolute or relative allowances. Token Upgrade solution: Adding partial delegation to the OP token would allow all other contracts to inherit the capability and rely on the standard This would require careful consideration as it would deviate from
UX pitfalls if we do it via Governor:
UX niceties if we do it via token:
Support for different proposal typesNot applicable to the token upgrade path, all changes will happen in the new governor upgrade. Support for different vote typesNot applicable to the token upgrade path, all changes will happen in the new governor upgrade. Integrate new contract functionality into a voting UINot applicable to the token upgrade path, all changes will happen in the new governor upgrade. Section 3: Call for comments and discussionWe have been pleasantly surprised by the number of DMs we have received asking how different contributors, auditors, groups and collectives can help us in delivering an amazing Governor V2 for OP. There are three things we would love comments and discussion around (but more if fine too): Do we think a Token Upgrade is worth it? Token upgrades shouldn’t be done lightly, but as you can see from the points above there are some real advantages to consider doing one here if the Collective agrees. What do we think of the architecture, specifically around the proxy contract alligator Should we not go the token upgrade route, we will need to implement the more complicated proxy delegation contract, so as not transfer custody of the token to alligator but delegate it instead via another proxy. Are there other solutions that we should consider? Are there things we aren’t thinking about? What are your thoughts on the oracle service? Is it worth using a decentralized oracle service, or should we maintain a more centralized service for simplicity’s sake? Anything else on your mind / where to find us. Feel free to join the Agora discord, or jump in and talk to us in the OP channel (here). I am @yitongzhang and am running point for this project at Agora If you are interested in seeing how Agora can help you connect with @charliecf @kent is our engineering lead and will be building out the oracle system as well as working with @jjranalli on contract design and implementation |
|
Hey everyone, as promised in the milestones timeline – we're sharing a Github repo with the gov v2 code with the community for feedback here. If you've been following our critical milestones timetable, this update constitutes our 2nd milestone. The next update will be in slightly longer, when we'll check back in with the deployed contract. https://github.com/voteagora/optimism-gov/tree/partial-voting
For those interested in diving into the repo, a few notes:
|
|
Hey folks, just wanted to chime in here with a quick progress update: General Progress
Given point 1, here's the amended milestones table
Partial delegation deep diveObjective Alice has 200 OP. She should be able to delegate 100 to Bob, and 100 to Charlie Constraints
Current design We use proxy contracts to which token holders will delegate. These contracts remember who is allowed to vote with how much. When voters vote, they batch call all the proxies where they have eligible votes. Pros: Does not require transfer ✅ So what’s the plan? We will only allow holders with more than 100 OP use partial delegation, this covers 95% of the token supply (but only 16% of the token holder base), and will mean that at worst, the cost per vote will be around $32 by our estimates. At below 100 OP, the utility of partial delegation is relatively low too. Further Mitigations We plan on deploying these mitigations from simple to complex. We think only 1. is necessary, but have a long
Conclusion and CTAWe'll continue to update this thread with updates on our design. If you have ideas on how to improve our partial delegation design, please reach out! We're happy to share part of our grant with you if this is something you'd like to tackle. |
|
Hey everyone – wanted to share a big milestone for us today: we just deployed a draft v2 contract for testing! We're sharing this version with the community so that we can get folks to poke around, and provide feedback as early as possible. Disclaimer: this is NOT the final version, has not been audited, and should not be considered safe. One area in particular that's worth highlighting is our implementation of partial delegation as this was a particularly tricky challenge given we couldn't upgrade the token. In short, it was important to us that users were able to use this feature without escrowing their tokens into a contract. To achieve this, our implementation accepts some significant tradeoffs when it comes to gas efficiency. We've collaborated with many folks in this thread and in our network to arrive at this solution (thank you @apbendi and @gigamesh), have made many optimizations, and feel confident that we have strategies to manage around the gas cost such that the end user experience can be as seamless as possible. But of course, if you have more ideas here, we'd welcome any input! Otherwise, please ping me or @jjranalli if you have questions.
Links: governor: 0x1f9937F1505543916c790d3934d140Cc4B51C03c |
|
Hey folks – circling back to this thread to say that gov v2 has been fully launched and live in production. Some features are still getting rolled out gradually, and we'll continue to monitor and improve the experience – but the specific deliverables in this thread are now out for folks to use. Check it out here: https://vote.optimism.io/
|
|
Hello @yitongzhang ! Tally here, we're looking into whats the best way to support these features. Are these the live contracts in production? Thanks! governor: 0x1f9937F1505543916c790d3934d140Cc4B51C03c |
|
Hey @crazyrabbitLTC confirming these are the deployed contracts. Docs can be found here: https://github.com/voteagora/optimism-gov 0xcDF27F107725988f2261Ce2256bDfCdE8B382B10 - Optimism Governor Proxy Please hit us up on tg if you wanna chat about integrating! |
oplavande
changed the title
Foundation Mission Request – Governor v2 Contract
To take on this project, submit a proposal to this thread by June 28. Read more about Missions here.
How will this Foundation Mission (RFP) help accomplish the above Intent?:
This RFP will help the Token House governance system continue to evolve in pursuit of usability and participation, which will also further increase the social decentralization of the Collective.
The v1 Governor Contract moved the Token House to an MVP version of onchain voting. Based on delegate feedback, this RFP details a set of improvements aimed at improving delegation UX, solving existing painpoints with voting operations, and experimenting with new forms of delegation. All of these improvements should make it easier for delegates to participate in Optimism governance.
What is required to execute this Foundation Mission (RFP)?
An upgrade to the existing Governor Contract that includes the following functionality:
This RFP will consider proposals that include modifications to this scope. Additional upgrades or adjustments are fair game to propose and may warrant a re-evaluation of total RFP grant amount.
What milestones will help the Collective track progress towards completion of this Foundation Mission (RFP)?
How should badgeholders measure impact upon completion of this Foundation Mission (RFP)?
Application instructions
To apply for this RFP, please complete the form in the expandable section below and leave your response as a comment on this issue thread below. Submissions will be open until June 28, at which time the Foundation will review all submissions and select up to three individuals/teams to complete the work defined here.
Submission form
Copy the entire application below and leave a comment on this issue with your answers completed. A representative from the Optimism Foundation may reach out using the contact info provided to request more information as necessary.
Foundation Mission (RFP) Application
Please verify that you meet the qualifications for submitting at the above Tier
Read more about Alliances here
What makes your Alliance best-suited to execute this Mission?
Please describe your proposed solution based on the above Solution Criteria (if applicable):
Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each peice of work:
Please define the critical milestone(s) that should be used to determine whether you’ve executed on this proposal:
Please list any additional support your team would require to execute this mission (financial, technical, etc.):
Grants are awarded in OP, locked for one year. Please let us know if access to upfront capital is a barrier to completing your Mission and you would like to be considered for a small upfront cash grant: (Note: there is no guarantee that approved Missions will receive up-front cash grants.)
Please check the following to make sure you understand the terms of the Optimism Foundation RFP program:
-- end of application --
The text was updated successfully, but these errors were encountered: