Governor Contract Upgrade

Meeting Notes:

Outcome: Passed ✅

Outcome Summary

This proposal passed, and the governor contract will upgrade to Governor Bravo.

Proposal

Governor Contract Context

2022.09.16

Thank you to Kyle for laying out an awesome summary to provide context of our current governance process as it relates to the contracts facilitating it. Below are the key details around the current governor contract related to our governance process summarized in the v3 Governance Post.

GTC governance is a fork of the COMP/UNI governance systems. It uses Governor Alpha and Timelock. A helpful Dune Analytics dashboard can be found here 11.

Gitcoin: Governor Alpha contract address 6 | Gitcoin: GTC Timelock contract address 4

Governor Alpha is the governance module/smart contract of the protocol; it allows addresses with more than 1,000,000 GTC ( proposal threshold ) to propose changes to the protocol. Addresses that held voting weight, at the start of the proposal invoked through the getpriorvotes function, can submit their votes during a 40320 Ethereum blocks voting period . If a majority, and at least 2,500,000 votes ( quorum votes ) are cast for the proposal, it is queued in the Timelock, and can be implemented after 2 days.

Timelock: extensions add a delay for governance decisions to be executed. The workflow is extended to require a queue step before execution. With these modules, proposals are executed by the external timelock contract, thus it is the timelock that has to hold the assets that are being governed.

Queue: After a proposal has succeeded, any Ethereum address can call the queue method to move the proposal into the Timelock queue. A proposal can only be queued if it has succeeded. The waiting period begins when this function is called => 172800 seconds (2 days).

Execute: After the Timelock delay period, any Ethereum address may invoke the execute method to apply the changes from the proposal to the target contracts. This will invoke each of the actions described in the proposal. The function is payable so the Timelock contract can invoke payable functions that were selected in the proposal.

The minimum time to vote, pass, and execute a proposal is 10 days and 8 hours approx.

Upgrade to Governor Bravo

GitcoinDAO would like to work with Scopelift to upgrade from our current Governor Alpha to the new Governor Bravo. Below are key problems upgrading to Governor Bravo allows us to solve for:

• Governor contract parameter configurability without a new deployment

• Flexibility in governing the protocol once we reach a point and understand the needs of governance within our core protocols

• Allows proposers to post multiple proposals rather then a single at a time

• Allows proposers to cancel a proposal if a mistake is made

• Potential problem to be solved for: Flexible voting, allowing for different options to be presented and voted on
Note: This is very up in the air as it has just been a recent extension developed on Governor Bravo, but isnt fully audited yet. It was built by scopelift and are in the process of working with OpenZeppelin to get the changes audited.
Gov Post laying out Flexible Voting

Proposed Governor Parameter Changes

Governor Bravo introduced configurable Governance parameters. There are parameters that were previously hardcoded. In Bravo, the values are set at deployment, but the DAO itself can update them via a proposal and vote in the future.

OpenZeppelin’s Bravo compatible implementation follows suit and allows proposals to update the following parameters. This is actually something we helped get included into OZ’s implementation :)

For those interested, here is documentation laying out the current configuration of parameters in Governor Alpha. Below are the 3 parameters to vote on, their current configuration, and what were proposing to change the configuration to.

• Voting Delay - Delay, in number of blocks, between the proposal is created and the vote starts.
Proposing to change from 48 hours → 4 Hours

• Voting Period - Delay, in number of blocks, between the vote start and vote ends.
Proposing no change

• Proposal Threshold - The number of votes required in order for a voter to become a proposer.
Proposing to change from 1 mm → 500k delegated votes

The above is the proposal that I would like CSDO to vote for, Tigress has raised a good point that we could utilize option voting here. I would like to understand from CSDO a for or against or abstain on the above parameter changes.

Notes:

• The 3 above parameters can be configured/reconfigured at any time without a new contract deployment

• No changes will be made to the timelock

• The cooldown period at the end of a proposal will not be changed as that lives in the Timelock contract

Key Differences in Governor Alpha (current version used by GitcoinDAO) and Governor Bravo

Migration Plan to Governor Bravo

Note: This work will be outlineddone with Scopelift to ensure we are partnering with someone who has experience in these upgrades. Confidence is a key when doing these kinds of upgrades.

• create a repo that implements the Governor contracts by importing and inheriting the appropriate OZ contracts and selecting the (configurable) parameters chosen by GitcoinDAO

• Write a series of “smoke tests” for the new Governor confirming proper functionality and configuration after deployment

• If GitcoinDAO chooses to use upgradeable contracts for the Governor: write a series of tests exercising the upgrade-by-vote mechanism adding or modifying Governor logic

• Analyze current Governor and document state that must be carried over to the new one, including but not limited to token balances, allowances, timelock compatibility etc…

• Create a deployment script for the new Governor contract

• Deploy the new Governor (or work with a GitcoinDAO representative to get it deployed)

• Create a script that crafts the appropriate proposal transaction and submits it to the existing GitcoinDAO Governor

• Create tests that simulate the process of proposing, voting, and execution of the upgrade to the new Governor, ensuring that everything functions as expected and state has been carried over appropriately

• Create tests that exercise the new Governor after a simulated deploy, demonstrating it can accept a proposal, allow voting, process a proposal, control treasury funds, etc…

• Work with appropriate DAO tooling (Sybil, Snapshot, Tally, others as requested by Gitcoin DAO) to ensure the upgraded Governor will be properly reflected after

• Write an explanation to the community about the technical aspects of the Governor upgrade, the risks, etc… for posting on the Governance forum or other medium

• Respond to questions from the community on the forums or other venues, including participating in community calls or other live meetings as needed or requested

• Work with a delegate to execute the proposal script to have it actually submitted to the existing Governor

• Upgrade Seatbelt to add the Gitcoin Governor so the live proposal can be simulated and validated by the tool

• Continue community engagement during the proposal voting period as needed

How will this be funded?

Kyle has been looped in and has agreed that the cost of this work with Scopelift will be covered via the Foundation