[GCP-009] - Upgrading Gitcoin’s Governance Contracts

📜 Proposals
, ,
1

Summary

Gitcoin has been working with ScopeLift for a number of months to develop, test and now implement new onchain governance contracts for the Gitcoin DAO. These new contracts are built on tested Open Zeppelin contracts that bring Governor Bravo functionality to our DAO’s governance. These new contracts also have the Flexible Voting extension which has been audited. Flexible Voting provides a permissionless interface for integration and experimentation via voting contracts, enabling a host of new use cases to eventually be built (layer 2 voting, shielded voting, new delegation schemes, etc…). It is our goal to have the DAO review and approve the upgrade to these new contracts, and then for us to migrate our governor contracts.

Abstract

The Gitcoin DAO was launched nearly two years ago, in May of 2021 using our iconic Quadratic Lands website. The initial governance contracts used were the only “battle tested” contracts available at the time (though Governor Bravo was just emerging as an option). As a result, when deploying the DAO, the selection of Governor Alpha contracts were used to ensure stability and safety.

Fast forward two years and we have seen an explosion of new governance mechanisms (Nouns, NFTs, token voting, Gnosis voting, etc.). Gitcoin has explored a number of options to encourage more voter participation (like our Quadratic Votes on Snapshot, Signaling on our governance forums, etc.), but remains deeply tied to our governance token and the onchain mechanisms that it affords. We would like to upgrade the existing contract (technically replace) with new contracts to expand our onchain governance capabilities.

ScopeLift is a team that has been building and developing smart contracts with Gitcoin for years. They built the first bulk checkout experience and our zkSync checkout flow on the cGrants Platform, contributed to the first version of the Trust Bonus which became Passport, were integral in a large revamp of cGrants at GR9, and also shared their wisdom on how to construct dGrants.

Motivation

The Alpha contracts we have work and are reliable, but we feel they are restrictive in our ability to explore, and upgrade components of our governance process. We would like to give the community the ability to decide the proposal threshold, voting delay, voting duration, and also introduce novel mechanisms via Flexible Voting strategies.

It has been flagged multiple times that we want more capabilities in governance voting. Even just giving voters an abstain option for on chain votes is not possible right now with the existing governor contracts.

Specification

The new Governor contract and associated tests, simulations, and scripts are available in a GitHub repository. The Governor was assembled from OpenZeppelin’s widely used, audited, and battle tested implementation of the Governor. It is compatible with Governo Bravo and with the existing GTC token contract and governance Timelock contract, which will remain in place.

The Governor contract also inherits ScopeLift’s Flexible Voting extension, which is backwards compatible with the existing Governor interface. It provides a new point for integrations. It is also fully audited.

The repository contains an extensive suite of tests. These tests simulate the upgrade to the new Governor, from deployment, proposal, Governance vote, and future votes by the DAO. The tests run on a “forked” state from mainnet to simulate the closest possible production state. They exercise all scenarios before and after the upgrade, and ensure Governance will still function properly after it is completed.

The repository contains scripts for deploying the new Governor and for submitting a proposal for the upgrade to the existing Governor. The scripts are exercised by the tests. The deployment script was used to deploy a candidate Governor contract. If the DAO chooses to move this to an onchain vote, the proposal script will be used by a delegate with sufficient weight to submit the proposal.

If an onchain vote on the proposal fails, the existing Governor will retain its Governance privileges and can continue to be used. This scenario has also been fully tested.

If an onchain vote on the proposal is successful, the old Governor will be left without a privileged role, while the new candidate Governor will be given control of the treasury and other Governance functions. Votes on future proposals will proceed through the new Governor. We are coordinating with Tally to ensure the change is reflected immediately in the Governance frontend should it succeed.

No proposals should be queued behind the upgrade proposal, as it will not be possible for them to execute if the upgrade succeeds. Any such proposal could still be resubmitted to the new Governor.

Benefits

Upgrading (aka replacing) the existing Governor Contracts will offer the following benefits:

  • Ongoing Customization of key voting criteria (proposal threshold, voting delays, voting period)
  • Introduction of Flexible Voting to enable new use cases, such as GTC locked in various locations (Uniswap, Maker, Compound) to still be used for voting, Layer 2 voting, shielded voting, etc…
  • Extensibility to explore additional customizations in delegation, such as expiring delegation, overridable delegation, chained delegation, quadratic delegation, and more

Drawbacks

The cost of this work has been funded by the Gitcoin Foundation and is not something DAO will incur. The largest drawback to this proposal is execution risk. If there were a serious bug, we could lock the treasury. Said differently, without an operational governor contract, the treasury would be inaccessible. This is why all contracts have been audited and why ScopeLift has spent extensive time testing and simulating the upgrade.

Vote

I propose three options:

1 - Vote Yes to upgrade the Governor Contract to the contracts ScopeLift has deployed here.

2 - Vote No and do not upgrade

3 - Abstain

19 Likes
2

I’m excited to have this upgrade before the community for consideration. If anyone has any questions on the engineering here, feel free to tag me or reach out privately. Thanks!

4 Likes
3

We’ve been looking for this for a while! I’m glad to see it is finally ready. Fully in support.

2 Likes
4

Absolutely in favor! 1 - Vote Yes to upgrade the Governor Contract. I like the fact that the DAO will be able to experiment with flexible voting and perform granular customisations in on-chain governance.

I suggest predefining protocols to mitigate any crisis In case a bug were ever detected and the treasury becomes inaccessible.

4 Likes
5

I am excited for the benefits this upgrade brings, but I do not think that we’ve done a full exploration to mitigate risk. I’m a no until this can be addressed.

+1 as @jengajojo suggests, we could underwrite a fall-back protocol method and I believe this is the industry standard.

While this is an audit of another ScopeLift product, and not the flexible voting product, I would echo concerns of the 3rd party dependency which was surfaced here: https://leastauthority.com/static/publications/LeastAuthority_ScopeLift_Umbra-js_Final_Audit_Report.pdf

I appreciate OpenZeppelin as an industry leader in testing, but would like to further know that we can depend on thorough auditing for not only the core solidity technology, but also all dependencies and subdependencies, so as to mitigate issues in the future. @bendi can you speak more to how we can avoid exploits that might implicate ScopeLift indirectly, and whether there are procedures in place to “roll-back” should a new version be found insufficient?

3 Likes
6

This is a big drawback. Can we be 100% sure this will not happen?

2 Likes
7

Pretty excited to see Gitcoin go through with this governance upgrade. I think it’ll enable a suite of new features that will really improve the governance experience. I think this is great for both the DAO and the Gitcoin ecosystem.

@bendi and the team are also one of the best in the space. So I believe the execution risk is very minimal as they have a strong track record.

3 Likes
8

Hey @ale.k, appreciate your thoughts. It’s 100% valid to be concerned because obviously locking the treasury would be a serious problem. I’m glad folks are considering this carefully!

Can you expand a bit on what you mean here? From a technical perspective, I don’t believe there’s any real opportunity to provide a “fall-back method”, outside of the extensive testing and simulation we’ve done, along with the conservative approach toward the upgrade we’ve taken (leaving the timelock in place, etc…).

The only dependency of Flexible Voting (which has been audited) is the OpenZeppelin Governor contracts, which—in addition to being audited themselves—are widely used in the ecosystem by many DAOs, including those like ENS and others that have quite a large amount at stake. The OZ contracts do not have any sub-dependencies.

ScopeLift doesn’t have any special control over the contracts being deployed. They’re autonomous and we don’t have any kind of permissions or admin rights. The contracts are open source and can be reviewed and verified by anyone technical. I’d strongly encourage technical folks in the DAO to take a look.

Unfortunately there is no way to enable a rollback method. For such a method to be possible, the existing Governance contracts would have to support it, which they don’t. This is part and parcel with living in the world of immutable smart contracts.

It should be noted that a number of large DAOs have successfully upgraded Governance in the past, including Compound, Uniswap, Nouns and others. We’ve reviewed the processes used by those DAOs and carefully incorporated learnings from them into the work we’ve done.

It’s also worth noting that the Gitcoin DAO will certainly have to upgrade at some point—there’s just no way the DAO could survive on the Alpha contracts forever without stagnating.

One of the big advantages of both the Bravo compatible Governors, and Flexible Voting is that both allow for certain future changes to occur without impacting the core Governance system. This should mean this upgrade can get the DAO pretty far into the future before having to worry about this again.

If I’ve misunderstood any of your questions, or would like me to expand on anything further, please don’t hesitate to follow up!

3 Likes
9

Hey @bendi - thanks for the thoughtful follow-ups and all the extra info!

Rereading @jengajojo’s note I think maybe what they had in mind was more of an incident process, now - but what I’m curious about would be if we could use some sort of fail-safe logic to keep the contract from locking. I.e. if no funds/votes/actions have been taken for x period of time (2 years, for example), all funds will be sent to a new multisig for which we have key Foundation members in place. An “escape” route if you’d like, in case of catastrophe.

I understand that the likelihood is low, and I agree that your team seems to have done all the necessary due diligence. Given some very high profile contract snaffus, though, just wondering if there is any way to encode further safety meaures here…

1 Like
10

Hey @kyle
I want to support this as I am a proponent of governance innovation. But I have reservations and perhaps I just need a bit more context on the priority of the work.

  1. How much did this cost the Gitcoin Foundation?
  2. How did the foundation decide this was the priority governance innovation to fund?
  3. What immediate Gitcoin problems / priorities / strategies will this change address?

Thanks,
Shawn

2 Likes
11

Thanks for clarifying @ale.k. Unfortunately, no, there is no way to add such an “escape” route as you’ve described it. To have such an escape route, it would have to have been added to the existing Governance contracts that were deployed when the DAO launched, and which we’re currently migrating away from. As it is, we’re limited by what the existing contracts permit us to do.

As for incident response, in the unlikely event that the funds were locked, the appropriate response would probably be a social migration to a freshly deployed token and governance system with a contract that allowed GTC holders to exchange one to one. Having this plan in mind is useful, but I don’t think it’s a good use of time to actually build such a system ahead of time because, again, the likelihood of it playing out is exceptionally low.

Obviously the ScopeLift team will be monitoring the upgrade closely as it rolls out, and would be immediately available to the community were anything to come up.

1 Like
12

This work was initially discussed and scoped (at CSDO) by the DAO over a year ago (and revived again here). It stalled among our process without a clear/motivated owner. I decided to take on the DRI role and pick this up and ensure it was completed.

Some of the immediate problems and priorities have been outlined in past posts (linked in my reply and in the initial thread). We are interested in adding customization to some configurations when the DAO is ready to make those changes and then also introduce flexible voting to ensure token holders have more ability to leverage their GTC that might not be in their wallet, but in other places on the Ethereum network.

3 Likes
13

As a new contributor to the DAO (PGF, as of nearly 3 months ago) I was actually very surprised to hear that flexible voting was not already implemented. It’s awesome to hear that this upgrade is moving forward. Kudos to everyone involved!

I’m very excited to explore new ways of letting GTC holders get utility out of their tokens while still being able to participate in governance (or delegating to a steward).

2 Likes
14

Thanks for the explanation @bendi

Is it possible to estimate the monetary cost of such an incident response? This ofcourse excludes any costs related to time or PR suffered by the DAO and its contributors. I would suggest keeping funds (+ some buffer) required to execute such an incident response in a separate multi-sig for additional redundancy.

15

Interesting question and idea @jengajojo. Very roughly you’d need:

  • New Governor contract (out of the box Open Zeppelin probably good enough)
  • New ERC20Votes contract with minting for GTC functionality (out of the box OZ with minor modifications probably good enough)
  • A few scripts to deploy and configure the new system
  • A frontend to allow for claiming

Putting the social coordination aside (no small thing), the engineering effort here isn’t enormous. At typical rates for web3 work I’d say on the order of low six figures. It’d probably take 3-6 weeks for a team to pull it together, maybe less if they’re completely focused on it, but you also wouldn’t want to rush and botch it, which would compound your problems.

2 Likes
16

Thank you @kyle for flagging that this upgrade is not without risk. Nonetheless, I believe it is time for this to proceed and will be voting YES.

2 Likes
17

@kyle This proposal has met the minimum requirements to move to snapshot for a vote.

  • 5 day posting period: met
  • Steward comments: met (5 of 5) (DisruptionJoe, jengajojo, ale.k, shawn16400, ccerv1)
3 Likes
18

Also fwiw voting YES - great conversation above btw.

1 Like
19

Definitely in favor of option 1 here.

2 Likes
20

Hey all - I want to share some of the testing plan and details that @bendi shared with me.

Testing & Simulation

The tests are where the majority of the engineering effort for this upgrade took place. There are approximately 1,500 lines of tests written in Solidity using Foundry’s testing framework.

The tests run on “local fork” of Mainnet, meaning the test environment pulls its state and contract code from Mainnet as the tests interact with it. Effectively, the tests run in a simulated environment that mimics the real environment where the contracts will execute as closely as possible.

The tests exercise the Deploy script and the Propose script in order to hew as closely as possible to the scenario that will occur in production. Additionally, the tests are architected to be executed in different scenarios. One such scenario deploys the Governor scripts on the local test network.

The second scenario was added after the candidate Governor was deployed. It uses the actual deployed contract code that now exists on mainnet directly. This, again, allows the test suite to be simulated as closely as possible to the production environment.

After the proposal is submitted to the Alpha Governor, a third scenario will be added which will simulate the relevant tests against the actual proposal data that will—at that point—be onchain. When the simulations complete successfully after this update, we can be further assured the upgrade will work exactly as expected, and that no bugs were somehow introduced in the proposal phase.

The test suite itself simulates dozens of different individual scenarios related to the Governor upgrade and to its usage by the DAO before and after the upgrade occurs. These include:

  • Successful deployment of the updated Governor with parameters that match the existing Governor
  • Successful submission of the upgrade proposal to the existing Governor
  • Rejection of the upgrade proposal if the vote fails
  • Continued successful operation of the existing Governor contracts if the upgrade proposal vote fails
  • Successful execution of the upgrade after a passing vote
  • Ability of the new Governor to queue and vote on new proposals after the upgrade, including:
    • Proposals that succeed and are executed
    • Proposals that fail and do not execute
  • Ability of the new Governor to move treasury funds after a successful upgrade, including individual tests for Ether, for each token held by Governance, and for combinations thereof
  • Ability of the new Governor to queue and execute proposals which modify its own Governance parameters, with individual tests for the voting delay, voting period, and proposal threshold
  • Ability of the new Governor to exercise Flexible Voting capabilities and pass various proposals wherein some or all voters leverage Flexible Voting
  • Validation that the old Governor no longer has the ability to execute proposals after the upgrade, including validation that it has no provenance over the treasury funds

Wherever possible within the test suite, parameters used by the tests are “fuzzed.” This means that instead of hardcoding values, random parameter values are injected each time the test suite runs. The suite has been run thousands of times, thereby exercising millions of individual permutations and validating that all test expectations hold regardless of the input.

You can read the full details here in the HackMD here.

5 Likes