PTBR-1: Governance Contracts Upgrade/ScopeLift

Project / Team Name

PoolTogether Onchain Governance Contracts Upgrade / ScopeLift

The budget being requested will be used to fund 125-200 engineering hours from the ScopeLift team. In that time, we will execute on an upgrade to the PoolTogether DAO’s onchain Governance contracts.

ScopeLift1 is a 7 person team of expert EVM devs. We’ve had the pleasure of working with many great projects in the space, including Uniswap, Optimism, Gitcoin, Endaoment, and others. We have our own project called Umbra2, which is a tool for privacy preserving payments. Contracts we’ve written have processed and custodied hundreds of millions of dollars.

ScopeLift has extensive experience relevant to the project being proposed. We have previously received grant funding for Governance related work from Uniswap, Aave, and the Ethereum Foundation. We created Flexible Voting3 and helped build and maintain Seatbelt4. We are currently working with Gitcoin5 to execute a similar Governor upgrade for that DAO.

Scope of Work


PoolTogether’s onchain governance is based on Compound’s “Governor Alpha” contracts. Compound itself moved on from these contracts years ago, as have most major DAOs. Today, the best practice is to use some variant of the OpenZeppelin implementation.

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

  • The DAO’s treasury is susceptible to a multi-block MEV attack6
  • The DAO treasury holds 30.41 ETH (~$59,000) that cannot be transferred
  • 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
  • The DAO cannot take advantage of the growing ecosystem of Governance integrations being built with Flexible voting (DeFi Voting, L2 Voting, etc…)

Upgrading the DAO’s Governor contract to an OpenZeppelin variant, with ScopeLift’s Flexible Voting extension, will solve all the aforementioned problems. It will also allow the DAO to sunset its custom Governance portal in favor of off-the-shelf options like Tally7, should it choose to. To learn even more about the advantages of Governor Bravo compatible contracts, check out this blog post8.


The goal of this project is to safely upgrade the DAO’s Governor contract. This upgrade will resolve the issues documented above. It also leaves the DAO well positioned to execute onchain Governance successfully for the forseeable future.

If executed, the upgrade will require no action from POOL tokenholders, delegates, or protocol users. The token contract and timelock contract will be unaffected.

Milestones & Deliverables

The Governor upgrade will have three main milestones:

  1. Development, Testing, and Simulation
  2. Deployment and Proposal
  3. DAO Vote and Upgrade Execution

Upgrading the Governor is a sensitive task that must be done carefully. If executed incorrectly, the upgrade could cause issues for the DAO. In the worst case, a botched Governor upgrade could result in locked treasury funds or the inability to update protocol parameters.

To ensure the upgrade will go smoothly, with no impact to the DAO or to PoolTogether users, ScopeLift will take extreme care in the development and testing of the upgrade. No corners can or will be cut in the upgrade process.

The first milestone is therefore where most of our time will be spent. Below is a summary of each milestone.

Milestone 1: Development, Testing and Simulation

We will assemble the new Governor from ScopeLift’s fully audited9 Flexible Voting10 extension, built on OpenZeppelin’s widely used, audited, and battle tested implementation of the Governor.

We will then write a large suite of tests and simulations to ensure the upgrade will be successful, and that all DAO operations will be able to proceed normally after it is completed. Based on our previous experience with Gitcoin DAO, we expect this test suite will include hundreds of tests and thousands of lines of code.

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.

We will also write scripts for deploying the new Governor and for submitting a proposal for the upgrade to the existing Governor. The scripts will be exercised by the tests.

All tests and simulations are specific to PoolTogether. They exercise the actual code that is live on mainnet in a simulated environment. They will ensure the upgraded Governor can manage the DAO treasury and execute its role within the PoolTogether protocol, including but not limited to modifying prize pool, setting reserve rates and drip rates, modifying protocol parameters, etc…

These tests will be written as fuzz tests and invariant tests, meaning they will take random arbitrary inputs rather than hardcoded parameters. We will execute millions of scenarios through these tests before proceeding.

Milestone 2: Deployment and Proposal

When the upgraded Governor contracts have been rigorously tested as described above, we will deploy a candidate Governor contract to the Ethereum mainnet. We will then update our tests to execute again against the candidate Governor to ensure there were no errors introduced in deployment.

Afterwards, we will submit a PTIP proposal on the PoolTogether Governance forum to begin the formal process for the DAO. If consensus is reached in the forum, a vote on the upgrade can occur on Snapshot.

Milestone 3: DAO Vote and Upgrade Execution

If the Snapshot vote is successful, ScopeLift will work with a DAO delegate who has sufficient voting weight to submit a proposal for the upgrade onchain. When the proposal is live, we will again run the test suite against the proposal data now onchain. This will ensure, once again, that no errors were introduced in the proposal process.

Once the proposal is live onchain, the DAO will be able to vote for or against its execution. We will monitor the proposal vote and coordinate with appropriate tooling providers, such as Tally, to ensure the upgrade is reflected immediately after it passes. After successful execution, the DAO will be able to proceed with its governance of the treasury and protocol as normal.


A large majority of our time will be spent on the upfront engineering work, i.e. the Development, Testing, and Simulation milestone. The other milestones are bound by the nature of governance process, rather than our time.

  • Week 1-4: Development, Testing, and Simulation — ScopeLift executes on the engineering work described above
  • Week 5-8: Deployment and Proposal — ScopeLift deploys and tests the candidate Governor contract, then submits a PTIP proposal on the PoolTogether Governance forum. After 5 days, if consensus is reached, the proposal can move to a Snapshot vote, which takes another 2 weeks by convention.
  • Week 9: DAO Vote and Upgrade — ScopeLift works with a DAO delegate to get the proposal onchain, then executes tests again with the live proposal data. The DAO votes on the proposal, which executes ~1 week later if successful.


We are requesting $USD 40,000 in total, with half paid up front and half paid out over 8 weeks via a streama. We are also requesting 25% of the funds paid out via POOL for incentive alignment of ScopeLift with the DAO.

This funding is in addition to the $10,000 already received in the form of a grant, which funded the initial technical discovery and a portion of the development work.

The funds for this proposal can be sent to scopelift.eth (0x5C04E7808455ee0e22c2773328C151d0DD79dC62).

Amount Token Start Date Duration
10000 USDC N/A N/A
13,333 POOL N/A N/A
20000 USDC June 20th, 8 weeks

1 Team — ScopeLift — High Caliber Crypto
3 Introducing Flexible Voting: A Powerful New Building Block for DAO Governance — ScopeLift
4 Seatbelt for Governance: Supporting OpenZeppelin Governors — ScopeLift
5 GitHub - gitcoinco/Alpha-Governor-Upgrade
6 Vulnerability Disclosure: MMEV-exposed Proposals
9 ScopeLift Flexible Voting Audit - OpenZeppelin blog
10 GitHub - ScopeLift/flexible-voting: 💪🗳️ Flexible Voting – A Powerful Building Block for DAO Governance

1 Like

It’s not a requirement but I think a little temperature check poll could make sense here (to see what people think that maybe don’t want to comment), so adding one:

Do you support this proposal?
  • YES
  • NO

0 voters

Like @bendi mentioned in the budget section of this proposal, ScopeLift received a Grant for the discovery phase that lead to this PTBR.

The Grant included:

  • confirming that an upgrade to our Governor is possible and in line with those they have done in the past
  • making sure all issues raised (MEV exploit, locked ETH, transactions per proposal, flexibility) can be addressed by the upgrade
  • where necessary, write prototype or simulation code
  • delivery of a research summary to the DAO Governance forum, along with a proposal for consideration by the DAO to fund the engineering work required for the upgrade.

They Community / DAO can now decide if we want to move forward with this Budget Proposal.

I personally think this upgrade does make sense. The POOL Token is a Governance Token and making sure that our Governance contracts are updated to the newest standards in the DeFi space is crucial.
It comes with some nice features like unlimited actions per proposal, YES/NO/Abstain Votes instead of just YES/NO, Option to add text comment to on chain vote and ofc accessing our stuck 30.41 ETH.
Here a nice pic showing some benefits of it compared to our current Gov Alpha Contract:

(The Pic is from:

I understand that the costs of it are not small with a total of ~$50k but I think it’s a good way to make sure that PoolTogether Governance is future proof.

1 Like

Thank you @bendi for pushing this forward! I have a couple of questions for you.

I looked at the linked GovernorCountingFractional contract and the associated audit. Looks like the audit was very clean- that’s good to hear.

I’m curious though; that contract is abstract. What exactly will be deployed?

My second question is around support from Tally, which we’ll be switching to. Will Tally recognize the new gov system right away? What happens after the upgrade successfully executes?

Thanks in advance!


Thanks for your support @Lonser, and for your help with the grant process!

Great questions @Brendan! So the OZ Governor contracts are structured as a series of abstract contract extensions which can be added to their base Governor contract to assemble the specific set of functionality desired for a given deployment. Our Flexible Voting extension follows this same pattern. What will ultimately be deployed is a Governor assembled by inheriting from the correct set of extensions to give PoolTogether the functionality and compatibility it needs to operate with its existing token & timelock. To get a concrete sense of what I mean, take a look at the Gitcoin Governor for their upcoming upgrade.

Tally’s has to be updated to reflect the new Governor. We are happy to coordinate with them to make sure this happens. Since the voting period is long and the change is simple, it will be easy make sure the change is reflected immediately!


If anyone wanna comment on this proposal, pls feel free to! :slight_smile:
There is also a simple poll above if you just wanna vote and not comment yet! :slight_smile:

I think it makes sense letting this proposal stay for another week, talk about it during the next Community Call again if people want and put it on chain after the call if there are no opposing votes :slight_smile:

1 Like

I just wanted to say we are gratified to see the funding request proposal was approved. We’re excited to get under way on the work and to see the new Governor in action soon! Thank you to the PT community for entrusting us with this work :slight_smile:


Hey all, I wanted to provide a quick update on our progress. We got a delayed start due to an illness on the ScopeLift team, but for the last week and half we have been chugging along, and giving the PoolTogether Governor upgrade top priority to make up time.

We anticipate the engineering work will be done in less than 2 weeks, and possibly as early as the end of next week. You can follow our progress on the engineering work at this repo, in particular you might want to take a look at our progress by following pull request review.

Once we complete the engineering work, we will deploy the candidate Governor and update our tests to run against it. We can then proceed with the proper steps to move the upgrade proposal itself through the PoolTogether Governance process. Note that the bottleneck at that point will no longer be anything on the ScopeLift side, but community and smart contract enforced steps to get the proposal passed.

We’re grateful again to the PoolTogether community for entrusting this work to us. We’re excited to continue engaging with DAO governance as token holders moving forward. Please let me know if there are any questions!


Hi all, another update from the ScopeLift team. We’ve completed the core engineering work associated with the Governor upgrade. This week, we will do an “internal review,” where a ScopeLift engineer, who was not a part of the effort to date, comes in and does a mini-audit of the code with fresh eyes. When that wraps up, we will deploy the candidate Governor and move forward to the social/community phase of the upgrade.


Big thx Bendi for the updates! :slight_smile:
I post the questions you asked here (and in the Discord), so people can comment if they have any strong opinions about it, although I think your suggestions of keeping most parameters the same make sense and I personally agree with it! :slight_smile:

  1. Does the PoolTogether DAO want to keep the quorum requirement the same, i.e. the number of FOR votes a proposal must receive to be considered valid. Currently it’s set to 100K. I’d advise keeping it the same unless there is a strong reason to change it.

  2. What does the PoolTogether DAO want to use for it’s proposal delay—i.e. the delay between when a proposal is put on chain and when it can be voted on. Right now it’s set to 1 block, but this opens the DAO to multiblock MEV. I’d suggest a minimum of 12 hours. This value can be changed by Governance in the future. Some other DAO data points:

Compound: 2 days
Aave: 1 day
Uniswap: 2 days
Nouns: 5 days

  1. Does PoolTogether DAO want to keep its current current Voting Period and Proposal Threshold the same for now? I would again recommend keeping them the same unless there is a strong reason to change it. These also can be changed by Governance in the future.
1 Like

We have completed the engineering work associated with the upgrade, and as such, we have created a PTIP to move forward with a vote. Thanks again to the PoolTogether community for entrusting us with this work!

1 Like

@bendi Can you publish the tests that were written to prove that the deployment works as intended?

I would like to see those, along with setup instructions, so that I can run them locally and verify the deployment.


Hey @Brendan, everything is open source and available in this repository, including the full test suite:

The READMe should have pretty good instructions and documentation, but let me know if you have any questions. And feedback welcome, of course!


Thanks @bendi! The readme was helpful, and the tests look comprehensive. I cloned and ran them locally and everything checks out.