[Discussion][RGP-17] Upgrade Governance Contracts from Compound Alpha to Open Zeppelin Governor

[abbey]

Author(s):	@abbey & @shelb_ee
Type:	social
Created:	2023-09-06
Status:	active

This is a draft proposal that we are seeing feedback and looking to iterate upon. It will be voted on in the October proposal cycle.

Overview

This social proposal aims to gain consensus on upgrading Radworks’ current governance contracts (Compound Governor Alpha) to Open Zeppelin Governor with the assistance of the Scopelift team. If the community approves moving forward with this upgrade, the contracts will be developed by the Scopelift team via a grant from the Grants Org. Final approval and execution of the new contracts will happen via an Executable Proposal in a future proposal cycle.

Why upgrade?

Governor Alpha was the battle-tested industry standard at the time of the launch of the $RAD token in February 2021. It was the most appropriate choice for governance of the Radworks treasury. While Governor Alpha has all of the basic capabilities we need as a community-governed network, it is now deprecated, leading to a list of limitations. Other major DAOs have already moved on from Compound Alpha, including Compound itself.

Outdated governance contracts come with a number of specific risks and downsides:

• Alpha was designed as an immutable contract, meaning any changes to governance parameters (e.g. voting period, quorum, etc.) would require deploying a new contract and transfer ownership of the timelock instead of just being able to upgrade the existing one
• The DAO’s treasury is susceptible to a multi-block MEV attack due to a 1 block voting delay
• The DAO treasury cannot hold ETH directly in the timelock, and any ETH sent directly to the timelock would be stuck
• The DAO is limited to proposals that execute 10 onchain actions at a time
• The DAO’s governance parameters cannot be updated by the DAO
• The contracts are incompatible with tooling providers, who increasingly eschew support for Governor Alpha
• EDIT/ADDITION: Less granularity when voting (only yes/no voting options, no option to add note to onchain votes)

The newer versions of this governor contract (Compound Governor Bravo and Open Zeppelin (OZ) Governor) have more capabilities and allow for upgrades and changes to governance parameters without requiring migration. We believe that many of the features and capabilities available in the Open Zeppelin Governor contracts will enhance Radworks’ governance system, enabling a more detailed expression of input into proposals and providing easier management tools for governance facilitators.

Upgrading to Open Zeppelin Governor

The Governance Committee proposes we upgrade to Open Zeppelin Governor. Open Zeppelin Governor is the successor to Compound Governor Bravo and is fully compatible with Governor Bravo (i.e same benefits and features). The OZ Governor does, however, enable further features and integrations leading to more modularity than Bravo. Some key differences between Bravo & OZ Governor that we found interesting include:

• OZ lets you describe quorum as a fraction of the total supply instead of a fixed number of tokens
• OZ supports the flexible voting extension, which allows voting from an L2 or a shielded pool, new delegation schemes, etc.)
• OZ supports NFT voting in addition to ERC20 voting
• OZ makes the timelock delay optional

The Flexible Voting extension - which was created by the Scopelift team & is only compatible with OZ Governor - would also enable even more cool features including:

• Voting with tokens while earning yield in DeFi
• Voting with tokens bridged to L2
• Shielded voting (i.e. secret/private voting)
• Cheaper subsidized signature based voting
• Better voting options with tokens held by custodians
• Possibly enable vestees to delegate & vote with their share of the unvested tokens currently held in the multisig vesting contracts. It would require some extra smart contract development though.

The Flexible Voting contracts are less adopted or “battle tested” as the governor contract systems, but Gitcoin and PoolTogether have recently adopted the Flexible Voting extension into their OZ Governor. If we choose OZ Governor, we would advise to omit the Flexible Voting extension for now until it’s been tested more “in the wild”. The Governance Committee is still interested in exploring Flexible Voting due to its modularity and moving ahead with OZ Governor would make it a lot easier to integrate the extension in the future.

Ecosystem Adoption

The OZ Governor has seemingly become the industry standard, and is used by many DAOs both small and large. As it seems to have become the default choice for many small DAOs, there are a number of large DAOs using it. For example, ENS launched their DAO on OZ Governor. HOP Exchange, Unlock, Optimism and others are other examples who use OZ-based Governors (i.e. some have built a customization on top of the OZ Governor but use the core codebase).

Security

The OZ Governor contracts were released in August 2021 and have been consistently audited since. According to Scopelift, OZ Governor is more actively maintained than Compound Governor Bravo.

Why not Bravo?

Compound Governor Bravo is the successor to Governor Alpha. Some other major differences between Alpha and Bravo are listed here:

Compound Bravo has also been adopted by major protocols over the years. Uniswap upgraded to Bravo in August 2021. Wintermute Research also provides a useful description and analysis of the Bravo contracts and who is using them. Open Zeppelin conducted an audit of the Bravo contracts when they were released in early 2021. As the proposal process to change or request funds from the contracts are the same as Alpha (pass a governance vote and timelock delay), there are no additional security or governance risks compared with using the Alpha version.

The general consensus from Tally and Scopelift, however, is that Governor Bravo is on its way to becoming deprecated. There is no indication that anybody from the Compound is or is planning on working on the contracts moving forward. OZ Governor seems to be the modern implementation of Compound Bravo that most are being recommended to upgrade to.

Why Scopelift?

Scopelift is a small team of expert, full stack EVM devs that was recommended to us by the Tally team. The Governance Committee has been in conversations with their team for the past few months and is very impressed with their knowledge, credentials and willingness to dive into exploring new capability possibilities. Scopelift has worked with many great projects in the space, including Uniswap, Optimism, Gitcoin, Endaoment, Llama, PoolTogether, Yield, Cozy, Obol, Railgun and others. They are also working with tooling providers like Tally, which will be supporting it in their frontend.

Logistics

Upgrading our governance contracts will require both general consensus from the community to signal approval for an upgrade (social proposal) and subsequent on-chain vote (executable proposal). Gaining consensus on this Social Proposal is the first step.

In order to preserve USDC in the treasury, the Scopelift team is applying for a grant to fund the majority of their work with the condition that funds will only be received if this proposal passes. The Scopelift team has submitted an application for a Grant to fund their first milestone work. If the community signals support for the upgrade via this Social proposal and the Grants Committee approves the Grant, their team will start developing and testing the new contracts. Once their work is complete, they will submit an executable proposal to Radworks for the final approval and execution of the governance upgrade. This proposal will include a RAD payment for completion of the final milestone.

Timeline

If this proposal passes the September cycle and the Grants Committee approves the application by the end of September, the Scopelift team will need around 1 month (100-200 hours of testing before implementing) of development and auditing. If all goes well, the final proposal to approve the contracts could be published during the November proposal cycle. If more time is needed, we can push it back to the January cycle (we will not have a December cycle given holidays).

CALL TO ACTION & NEXT STEPS:

• Discuss and indicate support for upgrading to OZ Governor. The Scopelift team will be monitoring this post and answering questions as they come.

• Vote in the Snapshot poll. If the upgrade is approved, the Scopelift team will receive Grant funding and begin developing the new contracts.

• Submit an Executable proposal. Once the contracts are complete, there will be an Executable Proposal to review, approve and execute the new contracts.

[cloudhead]

I think this makes sense. The only thing I’m wondering is the urgency of this upgrade.

Alpha was designed as an immutable contract, meaning any changes to governance parameters (e.g. voting period, quorum, etc.) would require deploying a new contract and transfer ownership of the timelock instead of just being able to upgrade the existing one
The DAO’s treasury is susceptible to a multi-block MEV attack due to a 1 block voting delay
The DAO treasury cannot hold ETH directly in the timelock, and any ETH sent directly to the timelock would be stuck
The DAO is limited to proposals that execute 10 onchain actions at a time
The DAO’s governance parameters cannot be updated by the DAO
The contracts are incompatible with tooling providers, who increasingly eschew support for Governor Alpha

None of the above have been actual issues we faced. So is the real reason to upgrade to use the Flexible Voting extension in the future? If so, we could wait until that’s more mature.

[abbey]

No, I think the general urgency comes from wanting to upgrade to a well-maintained governance system — Compound Alpha is completely deprecated. Upgrading now will also provide us with more flexibility moving forward.

Flexible Voting is an extension of OZ Governor and - as we mention above - we propose to omit it until it has been tested “in the wild” more.

[bendi]

I agree with Abbey that there should be some urgency around upgrading. In particular, the risk of a multi-block MEV attack is not one that should not be ignored. While it’s unlikely to be executed right now, the environment could change and make that a bigger risk. One example of how it could change: if Flashbots or another provider started offering a service providing multi-block bundles, the cost and expertise needed to execute the attack would decrease dramatically.

With regards to Flexible Voting: obviously, we (ScopeLift) think that the extension is safe. It’s been audited and adopted by 3 large DAOs. But we are, of course, hopelessly biased since it’s our initiative. I can certainly respect a conservative, security-first posture. So I think it’s a reasonable decision for Radworks to opt-out of Flexible Voting for the moment, even if I’d personally recommend that you did.

To get Flexible Voting in the future, you will have to upgrade the Governor again, but it will be an easier process than this upgrade. That’s because you’ll already be on an OpenZeppelin Governor after the upgrade, and because all the testing and simulation collateral we would build to execute this upgrade could be (relatively) easily re-used and extended to facilitate a future upgrade.

I hope this helps clarify things. Please let me know if you have any other questions!

[shelb_ee]

I

@abbey

I think the general urgency comes from wanting to upgrade to a well-maintained governance system

@bendi

I agree with Abbey that there should be some urgency around upgrading. In particular, the risk of a multi-block MEV attack is not one that should not be ignored.

Agree with Abbey and Ben above. This aligns with a number of security improvements Abbey and I have been working on over the past months to make sure our governance system is as durable and sustainable as possible.

I would also argue that now is a great time to do the upgrade as we will most likely have less governance activity during December & January (holiday season). It would be a pain to do an upgrade with a busy governance schedule.

[igor]

From the steps that are needed for the migration I assume that the Timelock contract will be abandoned too in favor of the new governance, right? If this is the case, then we must update the ownership of all the contracts that are managed by Radworks. From the top of my head all Drips contracts will need to have their admin role transferred. Are there any other migrations needed?

An alternative approach would be to change the admin of the Timelock contract to the new governor contract. That could be tricky because Timelock requires receiving at least 2 calls over a 2-day period to actually perform an action, this behavior would need to be simplified.

[bendi]

Hi Igor, great question! No, we intend to leave the Timelock contract in place, for exactly the reason you specified: migrating all the contracts managed by Radworks is a difficult and error prone process. The Governor contract is complex and contains all the core logic that defines how Radworks governance works onchain. The Timelock, on the other hand, is simple and just does one thing: enforce the delay in proposal execution. For this reason, it’s reasonable and straightforward enough to focus on upgrading the Governor while leaving the existing Timelock in place. This is the same approach we took for Gitcoin and PoolTogether for their upgrades, and it has worked well for them. Let me know if you have any more questions or would like me to go into further detail. Thanks!

[yorgos]

I have hardly any experience with governance contracts, but I understand there is quite some risk here. The Grant proposal mentions:

In the worst case, a botched Governor upgrade could result in locked treasury funds or the inability to update protocol parameters.

That’s a pretty major risk to be taking, isn’t it ? Can we somehow mitigate that risk ? (perhaps by having the upgrade and testing process audited - whether by radworks’ own EVM devs or external auditors - etc. etc.)

The new voting features do sound enticing and I do understand there are other risks by not upgrading also, so I am generally in favour of this, but having to vote on something that can bring about this much risk (basically killing Radworks, if I understand it correctly), I do have to think that over quite a few times…

@bendi would we be following the exact same process as some other org who has gone through this already? Anything you can share (that I might have missed) that can help us understand how this risk is mitigated?

[bendi]

Hi @yorgos, really good questions! You’re right that there is risk and we want to be upfront about it, that’s why we call it out clearly in the proposal. It’s also why we spend a bunch of time carefully testing and simulating every single step of the process to ensure it is safe.

We’ve successfully executed this twice now, and the process for Radworks will be extremely similar. There are differences, and those stem mostly from:

1. Minor differences in the governance contract deployment themselves—we carefully investigate the exact version and configuration of your existing contracts to ensure the upgrade is carefully tailored to the DAO’s specific needs.
2. Differences in the way Radworks uses governance—we test and simulate all existing governance applications to ensure they will function afterwards. This is DAO-specific.

Please note that all the code that will actually be deployed and used on chain is audited. The additional step of auditing the testing itself feels excessive to me, for not much value. It would also be extremely expensive and take quite a long time. My recommendation would against attempting to audit the testing.

We would, however, welcome any review from Radworks devs or community members with relevant technical experience. All the work we do for the upgrade will be open source and publicly available. You can take a look at the repos we used for PoolTogether and Gitcoin.

It’s very much a good idea to consider the risks carefully and to be clear eyed about them. I am very confident that ScopeLift can execute on the upgrade safely and successfully for Radworks.

[shelb_ee]

Hey folks! This proposal has moved on to the Formal Review stage of governance. You can find the link to the most recent version of the proposal and the link to vote in the Snapshot poll below!

Voting will be live until Monday, October 23rd at 5pm CET / 11am ET.

Formal Review Proposal: [Formal Review][RGP-17] Upgrade Governance Contracts from Compound Alpha to Open Zeppelin Governor

Snapshot poll