Introducing the Community Proposal Factory

1

Introducing the Community Proposal Factory

GFX Labs and its team have participated in protocol governance for over two years. In fact, Getty’s first governance proposal was a Compound Crowd Proposal, also known as a Compound Autonomous Proposal (CAP), in September 2020. At the time, to make a Compound Proposal a contributor needed 100k COMP (~$14m) votes. While that was unobtainable for most contributors, CAPs allowed anyone with 100 COMP ($14k) to make an Autonomous Proposal.

At its core, a CAP is a defined voter with a single purpose: to make a proposal through the protocol’s primary governance contract. Once the CAP was created, the creator needed to lobby community members to delegate their voting power to the CAP, and once that voting weight reached 100k, it was eligible to become a proposal for the DAO.

In concept, CAPs were a great solution to get small, intelligent, and valuable participants engaged in protocol governance. Most delegates, however, could not delegate their COMP tokens to a CAP. Unfortunately, because delegations cannot be re-delegated except by the token holder, CAPs only democratized proposal power at the margins. We’ve also seen this at Uniswap for those who remember fish.vote.

To solve this problem, we are introducing the Community Proposal Factory (CPF), the next iteration of the CAP. The CPF is effectively a sub-DAO of a larger protocol with a significantly lower proposal threshold and the same proposal functionality. Anyone who meets the proposal threshold can create a Community Proposal. Governance token holders can vote on proposals like any other proposal. If the CPF receives a sufficient number of votes to initiate a standard proposal, the Community Proposal can be passed up to the primary governance contract. This structure removes the need for new delegations to be made for each CAP, and instead, governance token holders may leave their delegation on the CPF.

Community Proposal Factories effectively lower the proposal threshold without the increase in security risks to the DAO. In doing so, we feel CPFs will represent a big step in democratizing proposal power. Anyone can deploy a CPF for a DAO. Once deployed, it can be used. Anyone can craft a proposal with executable code without needing a large amount of capital (or commanding the delegated votes of a large amount of capital), and the broader governance tokenholder community can judge whether the proposal should advance to a full vote.

The Community Proposal Factory is compatible with Governor Bravo-based DAOs and can be easily deployed by anyone. Each deployer can configure the factory to their DAO and only requires minor configurations. In addition, this concept could be applied to other common governance frameworks such as OpenZeppelin’s Governor. Deployed CPFs can spin up an interface easily using Tally.

1868×914 68 KB

The above diagram is an example of how a Community Proposal Factory could be applied to Uniswap. In this example, the factory is deployed with the Uniswap Governor Bravo contract as the parent DAO contract, the UNI token as the governance token for the factory, a proposal threshold of 10k UNI votes, and a quorum of 10m UNI. Anyone with 10k UNI can create a proposal on the CPF. Similar to a regular vote, if the proposal reaches the necessary quorum (10m UNI), then the proposal is deemed successful. If the proposal is successful and if the Uniswap CPF has the required 2.5m votes, the execute function will create the proposal on the Uniswap Governor Bravo contract.

At this point, the governance process is identical to any other vote. The proposal will go through the standard review, voting – and, if successful – timelock before execution.

Deployment and proposal process

  1. Configure CPF and deploy. Anyone can do this, and you only need to do it once. Parameters such as the proposal threshold and quorum can be changed by the CPF’s voters.
  2. Announce the deployment to your community and rally the necessary delegations to reach quorum on the parent contract. Ideally, you only have to do this once. A few ideas to acquire the necessary voting power are to ask existing large token holders to delegate to the CPF, the DAO could allocate some tokens from the DAO’s treasury to be delegated to the CPF, or you could build a collective of small token holders who all delegate to the CPF.
  3. Anyone who possesses the required number of votes to make a proposal on the CPF may do so. (10k in the example above)
  4. Voters can vote on CPF proposals similar to their DAO’s primary governance system. If the For votes cast exceed the set quorum and outnumber the Against votes, then the proposal can be proposed by the CPF to the parent governance contract. At this point, the CPF must have the sufficient votes delegated to it to make the proposal on the parent contract and must maintain the voting power for the duration of the standard proposal.
  5. After the standard proposal is made, it is up to the DAO’s standard process to determine if the proposal is executed.

Uniswap CPF

The first Community Proposal Factory we want to launch is for Uniswap. Presently, Uniswap proposals require 2.5m (~$15m) in voting power. That limits the possible proposers to 35 addresses. Of the 19 successful Uniswap governance proposals to date, there have only been 12 unique proposers. Establishing a Uniswap CPF will lower the proposal threshold without adding additional risks to the DAO.

We’ve come up with suggestions for the CPF parameters and welcome all feedback from the community. Please note there will not be a vote, and CPF parameters are up to the discretion of the CPF contract creator, which anyone can create.

Updateable:

  • quorum votes: 10,000,000
  • proposal threshold: 1,000
  • voting period: 5 days
  • voting delay: 1 day

Constant:

  • delay/timelock: none
  • min proposal threshold: 100
  • max proposal threshold: 2,500,000
  • min voting period: 1 day
  • max voting period: 14 days
  • min voting delay: 1 second
  • max voting delay: 7 days
  • grace period: 21 days
  • proposalMaxOperations: 20

The two most important parameters to decide on are the proposal threshold and quorum. We have purposely suggested a very proposal threshold to make governance more accessible but retained the temperature check requirement of 10m votes to reach quorum and a five-day voting period.

We’ll take input for the next week and then make the CPF. Once the CPF is created, UNI token holders will need to delegate 2.5m tokens to the contract collectively, so it has proposal power.

8 Likes
2

Kydo from Stanford Blockchain Club here.

Thank you, @GFXlabs for this great post. I think this is a great tool for Uniswap and a great improvement from fish.vote .

I think for this to be implemented, we need to do some logistical changes to our governance structure around the social coordination side. I am for this change as well, and if you could provide an updated version of the current one (with CPF in it), that would be great. Specifically, where do these CPF proposal discussions reside? I do not believe the current governance forum can handle this.

With regard to constant selections, I think for V1 of this design, we can follow the existing temperature check format. I believe these constants are great starting points but would challenge voting delay = 1 day a bit. I think this should be longer for the beginning, maybe 3 day is a good starting point. The main reason for this is social coordination. If the CPF proposal was discussed outside the main forum, maybe we need a 3-day period for this proposal to be published here on the main forum and discussed by the participants.

All in all, great proposal. Can’t wait to see it live onchain!

2 Likes