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.
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!
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…
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.
Thanks,
Shawn
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.
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.
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).
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.
Interesting question and idea @jengajojo. Very roughly you’d need:
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.
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.
@kyle This proposal has met the minimum requirements to move to snapshot for a vote.
Also fwiw voting YES - great conversation above btw.
Definitely in favor of option 1 here.
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.
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)
Thanks for sharing. I understand that a new token contract can be deployed using these steps, but that will not recover non-native tokens from the treasury (stables/eth etc…). I’d suggest moving non-native tokens sufficient to cover these costs and some buffer into a separate multi-sig
Say more here? Why would we need to move these from the treasury?
The downside of this upgrade has been flagged as a bottleneck by me and a few others such as @ale.k @QuadraticLander
Since there is no way to install an ‘escape hatch’ incase of
and the suggested solution
Afaik, this cannot be done for nonGTC tokens. If this means that 35% of the treasury value will be inaccessible/permanently lost, then funds on a backup address will help reducing the damage.
I think your proposal is worth a discussion @jengajojo, but something to remember is that moving the tokens is not a risk free proposition either. Where do they get moved to? Who has the ability to send them back. And all of that has to be done without error as well.
I agree with your comments. Maybe a multi-sig with one member each from CSDO, Steward Council, foundation and yourself could be a starting point before diving deeper into governance around the backup address. As long as members on that multi-sig can be trusted, those backup funds are relatively safer in case the main treasury becomes inaccessible.